三次误删 .dsh 目录之后：插件验收 profile 隔离提案，兼一份事故复盘

[kangtsang]

背景

我在为 dsh-worktree-space 插件跑 DSH 兼容性矩阵验收。这类验收需要在一套一次性的 DSH_HOME 上完成「装得上 → 起得来 → 卸得干净 → 回滚得干净」全流程，但 DSH 目前没有提供任何对应的隔离命令，只能由插件作者自己写脚本实现。

经过

我写了一个临时 PowerShell 脚本，用一个名为 $home 的局部变量保存隔离目录。$HOME 在 PowerShell 中是只读自动变量，且变量名不区分大小写——这行赋值静默失败，$home 仍然指向真实的 C:\Users<user>。脚本下一行是对这个变量的 Remove-Item -Recurse -Force，于是整个用户目录被递归强删，.ssh、.dsh、.gitconfig、.npmrc 等点号开头的文件与目录全部丢失。所幸有事故前约 50 分钟的备份，已逐项恢复。

更值得警惕的是：同一环境下已发生三次同类误删，前两次都没有定位到根因。一个大多数时候诊断不出来的失效模式，靠文档提醒和代码规范是压不住的。

诉求

我据此写了一份提案，核心主张是：当隔离的创建与销毁都由 CLI 内部完成时，「忘记校验路径」这一整类事故就不再可表达。 具体建议：

P1：新增 dsh --profile --ephemeral，由 DSH 在系统 temp 下自建目录、打印路径、跑完自动清理；

P2：新增一等公民的验收命令 dsh plugin verify ，一站式完成安装 → 组合校验 → 可见性探测 → 卸载 → 回滚；

P3：DSH 自建的临时目录带标记文件，清理时校验标记，缺失即拒绝。

完整事故分析、根因复现（安全版脚本，不删任何文件）和提案全文见下方文档。[
DSH插件兼容性验收隔离提案-2026-10-01.md
](url)

[kangtsang]

背景：为什么会走到写脚本做兼容性测试这一步

dsh-worktree-space 要上架插件市场，而上架流程要求提交一份兼容性矩阵报告——不是单版本单步骤的"能跑通"，而是多个 DSH 版本 × 完整生命周期（安装 → 组合校验 → 页面/工具可见 → 卸载 → 回滚）的交叉验证结果。这套矩阵手工跑一遍不现实：版本数乘以步骤数，每次都要重建隔离环境、重装、重启宿主、探测可见性，手工操作既慢又不可重复，所以只能写成自动化脚本。

而 DSH 目前没有提供任何隔离机制，脚本必须自己创建和销毁一次性 DSH_HOME。路径的生与灭都落在作者手里——这一步就是后面所有问题的入口。

事故脚本伪代码

param([string]$v)

$root = "C:\Users\<user>\AppData\Local\Temp\wts-evidence-1.1.0"
$bin  = Join-Path $root ("dsh-" + $v + "\node_modules\@deepseek-ai\dsh\lib\bin.js")
$tar  = Join-Path $root "dsh-worktree-space-1.1.0.tgz"

$home = Join-Path $root ("home-" + $v)        # ← 危险行：$HOME 是只读自动变量，赋值静默失败

if (-not (Test-Path $bin)) { throw "missing DSH at $bin" }
Remove-Item $home -Recurse -Force -ErrorAction SilentlyContinue   # ← 危险行：删的是真实用户目录
New-Item -ItemType Directory -Path $home | Out-Null
$env:DSH_HOME = $home

# 后续步骤全部落到真实用户目录上
& node $bin --profile evidence --from-default-profile web --dump-config
& node $bin plugin --profile evidence add $tar
& node $bin --profile evidence --dump-config

根因（可安全复现）

事故脚本第 6 行是这样的：

$home = Join-Path $root ("home-" + $v)

$HOME 是 PowerShell 的只读自动变量，且变量名不区分大小写，所以这行赋值静默失败，$home 仍然指向真实的 C:\Users\<user>。紧接着第 8 行：

Remove-Item $home -Recurse -Force -ErrorAction SilentlyContinue

于是整个用户目录被递归强删。PowerShell 其实报了错：

无法覆盖变量 HOME，因为该变量为只读变量或常量。

但脚本里没有 $ErrorActionPreference = 'Stop'，错误只出现在 stderr，执行流照常走进了下一行的删除。

影响

.ssh、.dsh、.cc-switch、.gitconfig、.npmrc、.claude.json、.bash_history 等点号开头的文件与目录全部丢失。常规目录（Desktop、Documents 等）因文件被占用，Remove-Item 报错后被 -ErrorAction SilentlyContinue 吞掉，得以幸存——这也是损坏看起来"有选择性"的原因，反而增加了误判风险。

为什么这不是个别失误

同一环境下已发生三次同类误删，前两次都没有定位到根因，被当作环境问题或手滑处理。现场不留痕迹，后果又静默延迟，这种失效模式靠文档提醒和代码规范是压不住的。事故脚本本身还是 AI 写的，且作者读过"不要给 $HOME 这类自动变量赋值"的约束，仍然踩了进去——说明问题在范式，不在某次疏忽。

具体建议

优先级	建议	能根除什么
P1	dsh --profile <name> --ephemeral	作者不再持有隔离路径，也就无从写错删除语句
P2	dsh plugin verify <tarball>	统一验收格式，补上"起得来 / 卸得干净 / 回滚得干净"这半边
P3	DSH 自建临时目录带标记文件，清理时校验	廉价的第二道防线，防止误删非自建目录

可安全运行的最小复现

下面这段脚本不删除任何文件，只证明那个变量解析到了哪里，任何人都能在自己机器上运行核对：

$root = "C:\Users\<user>\AppData\Local\Temp\wts-demo"
$v = "0.1.7-rc.2"

# 事故脚本第 6 行，原样复制：
$home = Join-Path $root ("home-" + $v)

# 事故脚本第 8 行，把删除换成了打印：
Write-Host "Remove-Item would have operated on:"
Write-Host "    $home"
Write-Host "Does that equal the user profile? -> " + ($home -eq [Environment]::GetFolderPath('UserProfile'))
Write-Host "This script deleted nothing."

本机实测输出 C:\Users\<user>，与用户目录完全相同。第 6 行本该算出 ...\wts-demo\home-0.1.7-rc.2，实际拿到的却是用户目录本身——根因到此可以独立验证，不必相信任何叙述。

[f-infinite-z]

两件事想分享，都和你这份提案直接相关：

1. 你们的误删事故我们原样踩过。 我们也在 PowerShell 里用 $home（只读自动变量、赋值静默失败）+ Remove-Item -Recurse -Force，误删了整个用户目录（.dsh/.ssh/.config 全丢），靠卷影副本恢复。后来固化成四条硬规则，建议直接抄进任何验收脚本模板：

• 禁用 PowerShell 保留变量名（$home/$profile/$host/$pwd 等），临时路径用 $sandboxRoot 这类名字；
• 任何递归删除前先 Resolve-Path/Get-Item 打印实际目标并确认；
• 只删白名单目录（明确的一次性目录），禁止对变量拼接路径/用户目录/盘根删除；
• 禁止通配符递归删除（$dir\*），改为明确列出条目。

你们 P3（临时目录标记文件 + 清理前校验）等于把第 2、3 条做进 CLI，方向完全支持。

2. 隔离配方我们已经在用，可以先跑起来。 在官方 P1 落地之前：

• web/CLI 侧：DSH_HOME=<一次性目录>，装/启都在隔离目录内完成（我们发布前的 verify --runtime 就是这么跑的）；
• desktop 侧（0.2.0-rc.2 实测可行）：DSH_HOME=<沙箱> + Electron --user-data-dir=<沙箱> 双隔离，再给沙箱 profile 打 webserver.config.port 补丁换端口——沙箱实例可与真实实例同时运行不冲突（注意 patch 的 config 是整体替换，键要写全）；
• "装得上 → 起得来 → 卸得干净"我们做进了 dsh-ops verify（静态九项 + --runtime 在隔离 home 里经官方命令安装启动、报告存活），和你们的 P2 方向一致；官方将来若出一等公民命令，我们乐意对齐。需要的话我可以把 desktop 沙箱脚本贴出来。

以上基于我们本机实测，环境不同可能有差异。

[kangtsang]

两条回复都很有用，谢谢。第 1 条我们原样踩过，而且收场比你们更糟；第 2 条的隔离配方我们这周刚跑通一轮，方向一致，也确实有几处可以互相补。

同款事故，以及我们更糟的收场

$home（只读自动变量、赋值静默失败）+ Remove-Item -Recurse -Force，整个用户目录没了——和你们完全一样。

差别在收场：你们靠卷影副本恢复了，我们第一次完全没有恢复，数据全丢。

丢的是整个 C:\Users\<user>，.dsh、.ssh、.config 以及散在用户目录下的工作文件全部没了。之所以说损失可控，是因为这台是个人用的非工作电脑——没有工作仓库、没有企业凭据、没有要重新申请的服务器访问。如果是工作机，这就不叫"踩坑"了：.ssh 没了意味着所有服务器访问要重做，.config 里的 token 要全部轮换，那是一次安全事故。

这次之后我们才把"删除路径"当成需要机器校验的事，而不是靠人小心。

四条规则的对照：你们是人审，我们是机审

我们的守卫写在脚本里，删之前执行：

你们的规则	我们的实现	差别
禁用保留变量名	全部改成 $dshHome / $runRoot / $safeHome	一致
递归删除前打印实际目标并确认	Assert-Under → Assert-DirectChild → Assert-Deletable 三层，任一层不通过就 throw	你们是人眼看，我们是不通过就不删
只删白名单目录	只允许 <RunRoot>\homes\home-<版本> 和 <RunRoot>\logs\log-<版本>，必须是直接子目录、名字精确匹配	比"白名单目录"更严
禁通配符递归删除	全脚本无通配符删除	一致

我觉得这个差别值得强调：人审的规则会随时间失效，机器校验的不会。 我们这三层守卫有 20 个用例的回归测试（跑完打印 GUARD-OK / GUARD-FAIL，无论哪种都不删任何东西），每次改脚本都跑一遍。

要补充的一条：reparse point

你们的四条里少了一个我觉得相当危险的：Windows PowerShell 的 Remove-Item -Recurse 会跟随 junction / symlink。

即使路径限制得很死，只要"安全目录"内部有一个 junction 指向别处，删除时会被跟着删穿，路径检查完全不起作用。我们的做法是沿路径逐级检查 ReparsePoint 属性：

function Assert-NoReparsePoint {
  param([string]$Path, [string]$StopAt)
  $cur = [System.IO.Path]::GetFullPath($Path)
  while ($cur) {
    if (Test-Path -LiteralPath $cur) {
      $item = Get-Item -LiteralPath $cur -Force
      if ($item.Attributes -band [IO.FileAttributes]::ReparsePoint) {
        throw ("REFUSED: {0} is a reparse point" -f $cur)
      }
    }
    if ($cur -eq [System.IO.Path]::GetFullPath($StopAt)) { break }
    $parent = Split-Path $cur -Parent
    if ($parent -eq $cur) { break }
    $cur = $parent
  }
}

建议加进模板。

还有四条不在清单里、但同样致命的坑

这四条都不是"删除路径"，但都让安全网静默失效：

1. $ErrorActionPreference = 'Stop' + 原生命令 stderr + 2>&1
   PowerShell 把原生命令写到 stderr 的内容当错误记录，Stop 下直接抛终止性错误。我们装 DSH 的脚本一开始就栽在这：npm 只写一行 warning，整轮安装就在第一个版本中断了，后面的版本根本没轮到——失败被当成"没输出"而不是"出错了"。

2. Start-Process -PassThru 的 ExitCode 是空的
   必须先 $null = $p.Handle 缓存句柄再等待，否则 ExitCode 永远读不到。退出码这一项证据等于没有，而且不报错。

3. $p.Kill($true) 在 PS 5.1 上不存在
   .NET Framework 4.0 只有 Kill()，没有整树重载。更糟的是 try{}catch{} 会把 MethodNotFoundException 吞掉，于是超时后进程根本没被杀，端口一直被占，下一个用例连启动都失败。我们改用 taskkill /T /F，而且验证它真的杀掉了（WaitForExit(15000) + 失败标记）。

4. Get-Content -Raw 对空文件返回 $null
   后续 [regex]::Match($null, ...) 抛 ArgumentNullException，报错位置离真正原因很远。

第 2、3 条的共同点：它们让保护逻辑看起来在工作，实际上没有。 这类问题靠 review 很难发现，只有断言"杀掉之后端口确实空了""退出码确实有值"才能暴露。

隔离配方：做法基本一致，差异来自约束不同

我们这周实测了一轮（node 24.18.0 / pnpm 12.6.0 / DSH 四个版本 0.1.7-rc.1 ~ 0.2.0-rc.2）。

相同：

• 都用 DSH_HOME=<一次性目录> 隔离，这是最关键的一步，两边一致
• 都是"装得上 → 起得来 → 卸得干净"三段式
• 都是静态检查 + runtime 实际启动两条腿

不同，以及为什么：

	你们的做法	我们的做法
端口隔离	给沙箱 profile 打 webserver.config.port 补丁	直接给 dsh CLI 传 -Port
desktop 隔离	DSH_HOME + Electron --user-data-dir	没做 desktop，只跑 web profile
版本矩阵	未提及	四个声明版本逐个跑，端口 34800 起顺序分配

为什么我们不打算照你们那样打 patch：我们跑的是 dsh 命令行，可以传参数；你们要跑的是 Electron 桌面端，那条路上没有 CLI 参数可用，打 patch 是唯一的手柄。所以这个差异不是偏好问题，是没得选——我们干脆绕开了。

你们那个"patch 的 config 是整体替换、键要写全"的提醒本身很值得让官方写进文档。补一个具体数字：webserver 的 config 一共五个键——host、port、compression、compressionLevel、compressionThresholdBytes。如果整体替换成立，换端口就得五个全写，只写 port 会把 compression 也丢掉，静默失去压缩。

实测数据供参考：

• 四个 DSH 安装共 1.8 GB / 106,317 个文件，单个 43–47 秒
• 装完后整轮矩阵 0.5 分钟
• 每格判据：bundle 200 / 213,710 B；RPC 真实端点 200 ok:true、编造端点 404；回滚后 cordis.patch.yml 1,259 行、0 处残留

关于 P1 / P2 / P3

P1（--profile <name> --ephemeral）—— 这条是根除，不是缓解

我们整套守卫属于「持有路径 + 校验路径」这一派：脚本里依然有 $runRoot / $disposableRoot / $logRoot，靠三层 Assert-* 在删除前拦住。

这个思路的天花板很明显：守卫只在每条删除路径都记得调用它时才有效。 我们现在靠 code review 加 20 个用例的回归测试来保证"每条删除都过了守卫"，但那是约定，不是机制。以后谁加一段清理代码忘了调 Assert-Deletable，没有任何机制会拦住。

--ephemeral 换了个层次：路径由 DSH 持有，作者根本不碰。手里没有路径变量，就写不出 Remove-Item $runRoot -Recurse。这不是"更小心"，是让这类错误在语法层面不可表达。这条我们非常希望落地。

附带好处是生命周期问题也一并解决——1.8 GB 的安装目录跟着 DSH 走，而不是靠脚本记得清理。

P2（dsh plugin verify <tarball>）—— 方向完全一致，而且你们已经做出来了

我们现在做的事本质上就是这个，只是没有统一入口：每个版本跑六阶段（安装 / 配置组合 / 可见性 / 卸载 / 回滚），产物是一份 key: value 的 summary.txt。

如果 dsh plugin verify 落地，建议输出规范里强调两点：

• 机器可读优先：像我们那样每行一个 key: value，而不是给人看的表格。CI 要消费，人眼表格反而是障碍。
• 记录实际值，不只是"通过"：实际用了哪个端口、bundle 多少字节、RPC 真实端点返回什么、编造端点是不是 404、回滚后残留几处。这些数字才是可复核的证据，只有 bool 的报告没法追责。

P3（标记文件）—— 和我们现在的实现是互补，不是替代

我们现在是结构校验：路径必须是白名单目录的直接子目录、名字精确匹配 home-<版本> / log-<版本>。这拦得住"删错目录""删得太深""名字不对"，但拦不住一种情况：某个目录恰好符合这个形状（比如别处有人建了个同名目录），我们会把它当成自己建的然后删掉。

你们说的标记文件查的是来源，正好补这个洞。所以严格讲不是谁更严，是两个不同维度：

• 形状：是不是白名单目录的直接子目录 + 名字精确匹配
• 来源：是不是 DSH 自己建的、标记文件在不在

建议两个都做，成本都很低。同意"廉价的第二道防线"这个定位——它防的不是设计错误，是实现疏忽。

很想看你们的 desktop 沙箱脚本

我们目前只做了 DSH_HOME 单隔离，Electron --user-data-dir 那一层没做，所以还没验证过沙箱实例和真实实例并行的完整边界。

如果方便，请把 desktop 沙箱脚本贴出来，我们直接对照补上，也顺便验证一下我们关于 webserver config 五键替换的判断对不对。

---

以上基于我们本机实测，环境不同可能有差异。

[f-infinite-z]

Reparse point 这条我们收下了——它正好补在我们规则堆的盲区上。

我们的"只删白名单目录"隐含一个假设：路径校验通过后，删除就是安全的。但 Windows 上 Remove-Item -Recurse 会跟进 junction/symlink，只要白名单目录内部有一个链接指向外部，前面所有校验都会失效。我们的场景还特别容易踩到：pnpm 在 profile 里的 node_modules 本身就大量使用 junction/hardlink（.pnpm 与 store 是 hardlink、link: 投影是 junction），正好是 reparse point 高发区。后续我们会把"沿路径逐级检查 ReparsePoint"补进守卫清单，并按你们的 GUARD-OK/GUARD-FAIL 模式加回归断言。

"人审的规则会随时间失效，机器校验的不会"——这句我们引用进内部文档了。谢谢这份对照表。

[kangtsang]

[Bug] 桌面端「禁用所有插件」恢复流程会静默丢失 <profile>/cordis.patch.yml 中的用户配置

环境

项	值
桌面端	DeepSeek Harness 0.2.0-rc.2（win-x64，nightly 通道）
宿主	DSH 0.2.0-rc.2
Profile	desktop（~/.dsh/profiles/desktop）
系统	Windows

现象

在桌面端触发一次 profile 恢复（disableAllPlugins，即「禁用所有插件 / 安全模式」）之后：

• 第三方插件的 bundles 被正确恢复并重新启用，功能正常；
• 但写在 <profile>/cordis.patch.yml 里的手写配置全部消失，且没有任何提示。

我这台机器上丢失的内容包括：三个自定义 LLM 供应商定义（provider A / B / C，各含 baseURL 与模型列表，此处已匿名化）、一个模型覆盖（某模型的自定义上下文窗口与输入模态）、以及一个插件的 enabled: false 开关。

配置文件从 2622 B 缩到 837 B，只剩应用自己托管的几个 UI 设置项。

外部表现是模型选择器里找不到原来的模型——我这边的表现是主模型静默回落到内置的 deepseek-official/deepseek-flash。但界面上没有任何错误或提示说明「你的配置已被移除」。

密钥本身没有丢失（~/.dsh/.credentials.yaml 未被触碰，其中的密钥引用仍在）。丢的只是引用密钥的供应商定义。

复现步骤

1. 在 <profile>/cordis.patch.yml 里手写几个条目（自定义 provider、模型覆盖或插件开关均可）。
2. 触发「禁用所有插件 / 安全模式恢复」，或任何会调用 disableAllPlugins 的路径。
3. 观察 <profile>/cordis.patch.yml：手写条目消失，仅剩应用托管项；同目录下多出一个 cordis.patch.yml.bak-<时间戳> 文件。

根因定位

恢复逻辑在 Electron 侧（app.asar 内）：

lib/main.js → DesktopProjectManager.disableAllPlugins()：

async disableAllPlugins() {
  return this.withLock(() => sanitizeProfile("dsh", this.paths.profile, WEB_PROFILE.bundles));
}

sanitizeProfile()（dsh-app-boot 与 main.js 各有一份）只做两件事：

const backupBase = `${patchPath}.bak-${Date.now()}`
// ...
renameSync(patchPath, backupPath)                                  // ① 把 cordis.patch.yml 整体改名备份走
if (manifest !== void 0) writeProfileBundles(profileDir, manifest, bundles) // ② 只重建 bundles
return backupPath

它的 doc comment 也写明了这个设计意图：

Back up the profile patch and retain only the caller's recovery bundles.
The caller must stop the profile and exclude concurrent profile writes.
Installed packages and other manifest fields are preserved; patches are never parsed.

关键证据

时间线（本机实测，.bak 文件名中的时间戳即 rename 发生时刻）：

时间	事件
15:17:43	cordis.patch.yml 最后一次正常写入，手写条目都在（2622 B）
17:10:09	disableAllPlugins 执行：patch 被 rename 为 cordis.patch.yml.bak-<时间戳>，bundles 重置为内置 web profile
17:17:24	应用重写出新的 patch（837 B），仅剩它自己托管的设置，手写条目不复存在

插件定义走 package.json 的 dsh.profile.bundles，恢复时被重建；而供应商定义走 cordis.patch.yml，恢复时被 rename 移走且此后从不读取回填。 这就是「插件好好的、只有自定义配置没了」的原因。

为什么这是个问题

我理解「不解析 patch」是有意为之的安全设计——如果用户的 cordis.patch.yml 本身已损坏，解析它会让恢复流程失败，而恢复流程的本意是「保证 app 一定能起来」。这一点我认为是对的。

问题出在代价与告知不对称：

1. 静默。恢复完成后没有任何 UI 提示、日志提示或文档说明告知用户配置已被移走。唯一线索是目录里那个 .bak-<时间戳> 文件，一般用户不会去翻。
2. 不可逆性取决于用户是否会翻目录。patch 层没有版本控制，恢复流程除了 rename 之外不做任何保留。
3. 受损的不只是「偏好」。自建 / 第三方 LLM 供应商、模型参数覆盖这类配置往往是用户投入最多、最难重建的内容（要在多个渠道重新查 baseURL、模型 ID、上下文窗口），却和 UI 开关一起被静默丢弃。

建议

按成本从低到高：

1. 至少给出提示（零行为风险）：恢复完成后在 UI 或日志里告知「profile 用户配置已备份到 <path>.bak-<ts>」。这是最小且最容易被接受的改动。
2. 提供显式恢复路径：在恢复流程结束后，或在插件管理器里提供一个「从备份恢复用户配置」的入口，把 .bak 里的条目合并回 profile 层。
3. 合并而非丢弃：在不解析 patch 的前提下，把备份的 patch 作为独立一层保留（例如恢复后生成一个独立的 user-layer 文件），避免既破坏「能启动」的保证，又丢掉配置。

文档层面的一点建议

profile-boot 中 $DSH_HOME/cordis.patch.yml（home 级用户层）的注释说明它 "outranks the per-profile layer"，但 profile 级的 cordis.patch.yml 会被上述恢复流程移走，而 home 级不会。建议在文档里点明这一点——想避免被恢复丢弃，请把手写配置放在 home 级 ~/.dsh/cordis.patch.yml。

我的临时规避（供对照）

在等待修复期间，我把供应商定义移到了 home 级 ~/.dsh/cordis.patch.yml（sanitizeProfile 不会动这一层，且它 outranks profile 层），而把会被应用改写的选择项（agent-default-model）留在 profile 层——否则 home 层的定义会永久压住我在 UI 里手动切换模型的选择。

这只是自救措施，不替代上游修复。如果你也遇到了这个问题，可以按同样的方式先保住配置。

[f-infinite-z]

附议，补两条我们核对到的事实，供定位与修复参考：

1. 这是 fatal recovery 的既有设计行为，不是偶发。sanitizeProfile（app-boot 的 profile-sanitize.ts）的语义就是"不解析 patch，把 profile 的 cordis.patch.yml 重命名为唯一 .bak-<timestamp> 备份，然后恢复调用方指定的 bundle 列表"；JSDoc 与设计文档都写明 "patches are never parsed"。恢复优先保证能启动，整个 patch 层被当作可疑输入移除。桌面端 disableAllPlugins 走的正是这条路径（project-manager.ts → sanitizeProfile('dsh', profile, WEB_PROFILE.bundles)）。

2. 痛点在"粒度"与"告知"：cordis.patch.yml 是 profile 里唯一同时承载"应用托管设置 + 用户手写配置"的文件，整体重命名后用户手写段随之消失；main.ts 里 backupPath 只进了 console.info，没有在恢复对话框或任何 UI 上呈现，所以用户无感。你看到的 .bak 文件就是它。

对我们 dsh-ops（启动生命周期防护）的直接意义：任何"写 disabled 行兜底"的修复在安全模式触发后都会失效（patch 被重命名、下次启动重建为空 patch），我们会在文档里标注这个边界。修复方向上，恢复时只重置应用托管段、或至少把备份路径与差异在 UI 上提示出来，应该都能消掉"静默"这部分伤害。