前言¶
DeepSeek Harness(DSH)采用「一切皆插件」的架构,Profile 里往往同时挂着多个社区前端插件。只要某个 bundle 在构建或运行阶段出现语法错误、Lazy-CJS 契约不符,或依赖未就绪导致条目长期未激活,官方启动审计就可能抛出 N entries did not activate 一类错误,Electron 窗口直接白屏或弹出崩溃对话框。常见应对方式是用外部 watchdog 包装启动脚本,或在出事后手改 package.json、state.json 与 cordis.patch.yml 逐个禁用插件——前者增加启动链路复杂度,后者容易误伤正常配置。
下面介绍维护者 zxzc114514 发布的 dsh-crash-guard(目录分类 admin-security)。它以纯插件形态接入 DSH 0.2.0-rc.2 起引入的 ClientModuleRegistry 与浏览器端 IZ() 审计流程,在 Node 与 Web 两层主动拦截故障条目,并用文件指纹(rev)做静默隔离,尽量在不改动用户正式配置文件的前提下恢复 GUI 启动。
这是什么¶
DSH Crash Guard(防崩卫士) 是面向 DSH 的启动容错插件:隔离损坏或未成功激活的前端插件产物,避免整窗白屏,并在插件代码或市场版本变更后自动解除隔离、重新尝试加载。设计思路参考 Minecraft 社区 Not Enough Crashes 的容错思路,但实现完全落在 DSH 插件体系内,不依赖外部守护进程。
- 维护者:zxzc114514
- 社区目录:https://www.skillhub.cn/plugins/zxzc114514/dsh-crash-guard
- 源码与文档:https://github.com/zxzc114514/dsh-crash-guard
- 当前 package 版本:
1.0.2(MIT 许可证)
核心功能¶
双层崩溃防护¶
Node 宿主预检:服务端启动时对前端插件 bundle 做基于文件指纹(rev)的 V8 经典脚本语法与 Lazy-CJS 契约预检。预检失败的条目会从 ClientModuleRegistry 剥离,并调用 compose() 重建干净的启动图谱,避免向后端/前端分发损坏 bundle。
Web 引导拦截:在浏览器端官方 IZ() 严格审计之前,通过包装 __ModuleLoader__.create 动态介入;对未成功激活的前端条目执行 loader.remove(),并清理残留样式,降低因未激活条目触发的白屏崩溃弹窗概率。
指纹绑定静默隔离(Revision-bound Quarantine)¶
启动阶段发现故障时写入独立隔离文件 .dsh-market/crash-guard-quarantine.json,不修改用户的 package.json、state.json 与 cordis.patch.yml。同一插件代码指纹不变时,下次启动会静默跳过且不再弹窗;本地改码或市场更新导致指纹变化后,自动解除隔离并重新加载。
手动持久化禁用¶
若确认需要彻底停用某个插件,可在顶栏救援面板中选择永久禁用。此时会同步写入 .dsh-market/state.json、从 package.json 的 dsh.profile.bundles 移除对应项,并在 cordis.patch.yml 中将条目标记为 disabled: true。
顶栏救援面板¶
面板使用 DSH 系统语义色彩变量(--dsw-alias-*),明暗主题自适应。胶囊嵌在 Windows 40px 标题栏右侧、最小化按钮左侧拖拽带内(right: 150px),展开后可查看故障分类、上游阻断源(blockedBy)与报错堆栈。
安装与启用¶
插件声明的 DSH 版本范围为 >=0.2.0-rc.2 <0.3.0-0,Node.js 需 >=20;不向下兼容 0.1.x。
方式一:DSH 命令行¶
官方 npm 源:
dsh plugin add dsh-crash-guard
GitHub 源码仓库:
dsh plugin add github:zxzc114514/dsh-crash-guard
方式二:Profile 手动引入¶
在 Profile 的 package.json(常见路径如 ~/.dsh/profiles/desktop/package.json)中声明依赖并加入 bundle:
{
"dependencies": {
"dsh-crash-guard": "^1.0.0"
},
"dsh": {
"profile": {
"bundles": [
"dsh-crash-guard"
]
}
}
}
引用 GitHub 固定标签示例:
{
"dependencies": {
"dsh-crash-guard": "github:zxzc114514/dsh-crash-guard#v1.0.0"
}
}
安装完成后按常规定义将其列入 Profile 的 bundles 并重启 DSH 进程即可参与启动链路。
典型行为与验证记录¶
README 在 DSH 0.2.0-rc.2 与 0.2.0-rc.3 下记录了两种场景的实测:
- 客户端脚本语法损坏:向测试插件注入非法顶层
return。Node 预检在约 11ms 内捕获语法异常,移入隔离记录并重构启动图,避免分发损坏 bundle。 - 缺失上游依赖导致未激活:测试插件声明未安装的依赖,条目停滞在初始化。Web 引导拦截在
IZ()审计前剪除未激活节点,窗口进入主界面;救援胶囊标注故障插件并高亮blockedBy依赖包名。
日常使用中,多数故障会在首次启动时被静默隔离;需要排查时点击标题栏胶囊查看堆栈与阻断链,确认无误后再选择永久禁用或修复上游插件后等待指纹变更自动重试。
与外部 watchdog 方案的差异(摘要)¶
| 维度 | 外部守护进程包装启动 | dsh-crash-guard |
|---|---|---|
| 形态 | 需改写 bin/dsh.cmd 等启动链 |
纯插件,零外部依赖 |
| 拦截时机 | 进程挂起或崩溃后被动介入 | Node 预检 + 渲染层 __ModuleLoader__ 主动拦截 |
| 前端白屏 | 难以阻断 IZ() 审计抛错 |
审计前拓扑剪枝(pruneInactiveEntries) |
| 隔离 | 常依赖改配置文件 | rev 绑定隔离文件,正式配置不动 |
| 排查 | 日志或命令行 | 标题栏救援胶囊 |
适用场景与注意¶
适合:Profile 中前端插件较多、频繁试装社区 bundle,且希望在单插件损坏时仍能打开 DSH 主界面的开发者或运维。
注意:
- 插件以当前 DSH 进程的权限运行,会读取并挂钩模块注册表、注入 Web 引导逻辑;安装前应阅读仓库源码与 MIT 许可证,确认符合你的安全策略。
- 版本约束严格绑定 0.2.x RC 段;升级 DSH 主版本前需核对
engines.dsh是否仍匹配。 - 社区目录 skillhub.cn 为独立生态站点,与 DeepSeek / 幻方无官方从属关系;星标与分类信息以目录页为准(当前简介侧写为 admin-security)。
结尾¶
dsh-crash-guard 把启动稳定性收拢到 DSH 插件层:预检 + Web 剪枝 + 指纹隔离,必要时再通过救援面板做正式禁用。若你正在维护多插件 Profile,可先通过命令行或 Profile 依赖安装,再在故意损坏的测试 bundle 上对照 README 的验证步骤确认行为。