出事之后最贵的不是「不知道有撤销这回事」，而是「知道要撤销，却站在了错误的入口前面」。lire1131/dsh-undo-savepoint（README 标题：DSH 安全管家（撤销 / 回退 / 崩溃自愈））在 README 里留了一张「崩溃急救速查」表；本文把它拆成六条能直接照敲的最短路径，全部面向已经起不来的人。想先横向看一眼同类插件的中文清单与安装形态，见 完整插件清单与汉化避坑指南。
先记两组可核对的数字：详情页分类 dsh 原生插件 · tool，星标 171、综合分 61.7、周下载 663（npm 全网窗口，含 CI / 镜像与爬虫，不代表本站安装数）；本站已在 dsh 0.2.0-rc.2 下真实安装成功（L4 · 真实安装）。边界也要先记住：它保护的是 DSH 的启动关键配置与插件代码树，不是工作文件的全量版本控制。
处置顺序：先让它能启动，再谈排查
README 的处置顺序是固定的：安全模式 → 再逐个排查。慌乱中逐个禁用插件、手改 profile，容易改出新的启动错误，把一次能回退的事故变成不可归因的事故。安全模式会禁用除本插件（撤销系统）外的全部插件，保证 DSH 能启动；同时自动快照 + 备份配置（profile / home 双级 patch 一并备份恢复，并中和 dsh.profile.bundles 里会导致启动器硬校验失败的条目）。记住这条顺序，下面六条的入口选择就不会互相打架。
坑一 · DSH 彻底起不来，插件界面也打不开
现象：DSH 完全无法启动，你想点「撤销」，却发现那个界面本身就开在 DSH 里面。
原因：插件以 host 模式运行，需要 profile 提供 tools / systemPrompt / webServer 服务；DSH 起不来时这些服务一个都不在。
最短路径：只能走局外通道——这条没有别的选项。在仓库或安装目录下执行 node tools/undo-server.mjs，或双击 launch-undo.bat / .command / .sh / .desktop；它拉起纯本地 127.0.0.1 服务加内置网页，不依赖 DSH 运行。
坑二 · 直接按「安全模式」以外的方式抢救，越救越乱
现象：一慌就逐个禁用插件、手改 cordis.patch.yml，结果改出新的启动错误。
原因：README 的处置顺序是固定的（安全模式 → 再逐个排查）；跳过第一步，等于在没有快照兜底的情况下徒手去动启动配置。
最短路径：桌面「DSH撤销管理器」→「安全模式」按钮；或 CLI safe-mode -Label on。先让 DSH 能启动，再排查——这一步不需要你判断到底哪个插件坏了。
坑三 · 崩溃横幅提示会话损坏，但不知道该动哪里
现象：日志签名归类为 session-corrupt，重装也没用。
原因：<home>/sessions/**/session.jsonl.zstd 存在两类可修损伤：**单帧布局违规（README 记为 8/18 崩溃根因）**与 synthetic-closer seq 重叠；DSH 起不来时没法在插件内处理。
最短路径：DSH 还活着时走对话 / CLI undo_scan quarantine=true；起不来时用离线 dsh-undo.ps1 scan --fix——这条需要 Node ≥22.15，Node 20 下降级为提示。修复会留原件 .bak + 隔离区副本，无法解码的只隔离、不动原件。
坑四 · 恢复后 node_modules 和 lockfile 对不上
现象：回退了 package.json / pnpm-lock.yaml，但依赖目录没跟着变。
原因：默认只报告 node_modules 可能不同步，不会自动重建依赖。
最短路径：显式加同步开关——离线 CLI -SyncDeps、对话工具 sync_deps: true、REST syncDeps: true。它会执行 pnpm install --frozen-lockfile（无 lockfile 时普通 pnpm install）；安装失败不影响已还原的配置文件。
坑五 · 在离线 CLI 上操作，却发现快照「不见了」
现象：离线 CLI / GUI 里看到的是空的，或者不是当前 profile 的快照。
原因：离线 CLI / GUI 看不到启动参数，默认按 web 处理；真实快照是按 profile 隔离存放在 <快照根>/<profile>/{auto,manual} 的。
最短路径：用环境变量 DSH_UNDO_PROFILE（或 settings 里的 profileName）指定目标 profile。局外工具拿不到命令行，只能靠这两处。
坑六 · 启动预检报了一堆错，手工改不干净
现象：undo_doctor 报 BOM、bundles 解析失败、重复 loader id、junction 悬空等一串问题。
原因：这些是会让 DSH 在挂载任何插件之前就崩掉的硬失败，手改容易漏——README 举的例子正是 duplicate loader entry id。
最短路径：用能修的通道。对话里 undo_doctor fix=true、离线 dsh-undo.ps1 doctor -Fix、局外 WebUI 诊断面板的「修复可修项」按钮都行；改前先落手动快照，修完自动复查，修不了的会被标记而非静默放过。
总结
这六条的共同逻辑是「先分清 DSH 还活着没有」：活着就用对话或 CLI，死了就切局外通道，且永远先让 DSH 能启动；想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。
适合与不适合
适合：把 DSH 当主力工作台、配置改坏就影响当天产出的人；经常试装插件、需要随时退回上一个可用状态的开发者；已遇到 session-corrupt 或 duplicate loader entry id 这类硬失败、需要离线路径救回的人；维护多个 profile、要在局外工具里指定 profile 的人。
不适合：想拿它当工作文件全量版本控制的人——它保护的是启动关键配置与插件代码树，消息级撤销只覆盖「跟踪工作区目录」里配的目录；不能接受安全模式会禁用除本插件外全部插件的人；只想装完即忘、不愿在事前看过一遍入口的人。
标签：dsh-undo-savepoint、DeepSeek Harness、排错速查、崩溃救援、安全模式
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
