前言¶
在 Windows 上维护 DeepSeek Harness（DSH）时，重启宿主是常见操作：更新插件、排查卡死、让 bundle 重新组合。若从任务管理器强杀 Electron 进程，退出路径上的会话写回、插件组合可能被跳过，日志也可能受损。市场里一些「一键重启」类插件在进程内部发 SIGTERM；在 Windows 上这往往等价于 TerminateProcess，同样是强杀。
dsh-safe-restart 由 Daphne999 维护，归类为客户端插件。它不承诺 Windows 上能实现从外部发起的「优雅退出」——实测给主窗口发 WM_CLOSE 常只会最小化到托盘；它做的是：按固定流程结束宿主、重新拉起、用端口自检确认服务是否回来，并把成功或失败写进本地结果文件（README 还提到 QQ 通知）。当前 GitHub 星标为 0，许可证 MIT，版本 0.2.1，package.json 中 os 仅含 win32。
这是什么¶
一句话：面向 Windows 桌面的 DSH 重启辅助插件，把「有没有真的起来」变成可核对的结果，而不是静默失败。
维护者与仓库：
- 维护者：Daphne999
- 目录页：https://www.skillhub.cn/plugins/Daphne999/dsh-safe-restart
- 源码：https://github.com/Daphne999/dsh-safe-restart
核心流程¶
README 描述的执行顺序如下：
- 等待 3 秒后强制结束宿主进程。
- 重新拉起同一个 exe，失败时最多重试 3 次。
- 轮询宿主端口，确认新进程在提供 HTTP 服务。
- 将结果通知用户（README 写明 QQ 消息；同时写入本地 JSON）。
结果写入 %TEMP%\dsh-safe-restart.result.json，outcome 字段取下列三者之一：
| outcome | 含义 |
|---|---|
restarted-verified |
进程已回来，端口也开始服务 |
failed-to-come-up |
进程拉起，但端口一直无响应 |
failed-to-kill / failed-to-relaunch |
结束或拉起步骤未成功 |
自检判据是访问本地 HTTP 时返回 2xx–4xx（作者实测用 http://127.0.0.1:53820/ 返回 404 视为通过）。这能说明 HTTP 服务活着，不能证明所有插件均已正常加载。
设计上的三个决定¶
README 中归纳的实现取舍，便于理解为何是「强杀 + 外置 helper」而不是子进程内重启：
- helper 通过 WMI（
Win32_Process.Create）拉起，不能作为宿主子进程。若 helper 由宿主spawn，强杀主进程时 Job 会连带结束 helper，会出现「应用关了、没再打开」。 - 端口探测需覆盖全部 DSH 相关进程。HTTP 服务常在子进程上监听，只盯被结束的 pid 会得到「无候选端口」，自检会退化为「进程活着即算起来」。
- 通知放在 helper 里，不依赖新宿主。「没起来」时新宿主往往没有机会上报，helper 仍需把失败告诉用户。
安装与启用¶
在桌面 profile 下安装（命令来自 README，勿自行拼接 github:owner/repo 形式）：
dsh plugin --profile desktop add dsh-safe-restart
插件以当前 dsh 进程权限运行；安装前建议自行查看仓库源码与 MIT 许可证。package.json 声明 peer 依赖 @deepseek-ai/schemastery（>=3.18.1，可选）。
典型用法与可核对输出¶
触发方式以你在 DSH 中启用该 bundle 后的实际入口为准（README 未单独列出 UI 菜单名）。执行完成后，可在临时目录查看机器可读结果：
%TEMP%\dsh-safe-restart.result.json
作者 2026-11-08 本机实测日志摘要（来自 README）：
12:15:57 Stop-Process 已发出（-Force）
12:15:57 进程已退出（0s）
12:15:59 第 1 次拉起成功（子进程 pid=73100）
12:16:10 自检通过：http://127.0.0.1:53820/ 返回 404（用时 10.5s）
12:16:12 已推送重启通知
12:16:12 done outcome=restarted-verified
适用场景与注意¶
适合谁： 主要在 Windows 上使用 DSH 桌面宿主、需要可控重启并要确认「服务是否真的在监听」的开发者。
不适合： Linux、macOS。README 写明依赖 WMI 与 exe 路径，均为 Windows 专属。
已知限制（README 原文要点）：
- 强杀会跳过宿主退出时的一部分收尾（会话写回、bundle 组合）。能重启不等于数据一定安全；重要操作前请自行确认保存。
- 自检仅能证明 HTTP 服务存活，不能替代对业务插件的全量验收。
- 插件不替你决定「该不该重启」。
DSH 生态理念是「一切皆插件」；SkillHub 等社区目录为独立站点，与 DeepSeek、幻方无官方从属关系。
结尾¶
若你关心的是「重启后 DSH 是否在服务」而不是营销意义上的「优雅关机」，dsh-safe-restart 把 outcome 和日志路径写清楚，比静默失败更易排查。进一步细节见目录页与 GitHub README：
- https://www.skillhub.cn/plugins/Daphne999/dsh-safe-restart
- https://github.com/Daphne999/dsh-safe-restart
