升级 DSH 插件平时感觉很安全，直到它不安全。一个新版本可能改掉某个配置键、丢掉一个依赖，或者一夜之间把评分从 B 掉到 D。本指南带你走一遍升级前检查、快照、逐个升级和明确回滚，让升级永远不成事故。
第一步 — 升级前检查（5 分钟）
在动任何东西之前，先确认这个插件值得升、且新版本安全：
- 读 changelog。找破坏性变更、被移除的 flag、被改名的配置键。
- 对比评分差值。掉超过 5 分（比如 B 82 变 C 76）是警告，不是表面变化。
- 看最后提交日期。24 小时内刚推的版本，真实测试比一周前的少。
- 记下了当前版本和配置。回滚时两者都要。
第二步 — 动之前先快照
快照能把一次糟糕的升级从火灾变成脚注。哪怕只升一行版本号也做：
- 导出插件配置：dsh config export > backup-$(date +%F).json
- 如果注册表支持，给插件本身做快照（deepseek-harness/backup-tool 一条命令搞定）。
- 记确切安装版本：dsh plugin list | grep <name>。
第三步 — 一次只升一个
批量升级会掩盖事故的真正原因。先升一个，验证过了再升下一个。在 Codex 相邻的 setup 里，deepseek-harness/hot-reload 让你改完配置立刻看到效果、不用整体重启，把验证循环从几分钟压到几秒。
升完立刻跑你真正在用的那个功能。一个自己测试全过的插件，照样可能搞崩你的特定工作流。
第四步 — 升级后验证
- 重载配置（或重启），确认服务干净启动。
- 跑你每天用的命令；盯住输出变化或新报错。
- 再查一次评分。掉了就现在决定留还是回滚。
第五步 — 出事就回滚
如果插件开始耍脾气，按这个顺序退：
- 恢复配置快照：dsh config import backup-<date>.json
- 装回旧版本：dsh plugin install <name>@<prev-version>
- 如果注册表不支持版本钉，从 deepseek-harness/backup-tool 恢复。
- 确认功能正常，再把事故上报上游，让下一个人有预警。
| 现象 | 先做什么 |
|---|---|
| 服务起不来 | 先恢复配置快照，再降级 |
| 配置键被改名 | 旧键映射到新键，重新导入 |
| 评分骤降 | 暂缓升级，保留旧版本 |
为什么升级后评分会变
评分不是固定等级。它从维护、文档、npm 健康和安全信号重新算。一个丢掉 README、加了无人维护的依赖、或触发新安全标记的版本，可能整档下滑。这就是为什么第一步要比对差值、第四步要复查——同一款插件的新版本，在评分意义上是一款不同的插件。
什么时候可以不升
不是每个新版本都需要你。如果 changelog 只有文档更新且评分没动，可以等到下一个安静的下午。如果新版本改了你依赖的配置键、而你没空重映射，就钉住旧版本、把改动排期。周五下午 5 点赶着的升级，就是晚上 9 点搞崩的那次。
值得顺手看的插件
有两款插件让安全升级更容易。deepseek-harness/hot-reload 不改整体重启就能应用配置变更，让你在提交前确认新版本表现。deepseek-harness/backup-tool 给配置做快照，坏升级一次恢复就好。devflow 在你同时维护多个插件时理顺编辑-验证循环。
- deepseek-harness/hot-reload — 不重启也能重载配置
- deepseek-harness/backup-tool — 一条命令快照与恢复
- devflow — 跨插件更快的编辑-验证循环
关于 DSH Quality
DSH Quality 从维护、文档、npm 健康和安全四个维度给每款插件评分，让你的升级决策建立在证据上，而不是猜。升级前到 dshquality.com 查一下插件评分，读供应链指南，或到 / 浏览完整插件索引。