dsh-hmr 的默认 ignored 会把「同盘、profile 之外」的监视根静默忽略（附 picomatch 实测）

[ws177]

更正（2026-10-05，本正文已按实测重写）

原文的核心结论 ——「默认忽略规则会静默丢弃整个同盘、profile 之外的监视根，热重载等于关闭」—— 是错的，我撤回。经复测：

1. 原文的机制解释（「**/.* 把开头的 .. 段当成点号文件段匹配掉」）不成立：**/.* 对单个 .. 匹配，.. 后面还有内容才失配（picomatch('**/.*')('..') = true，('../..') = false，'../a/.cache') = false）；
2. 而且坏的不是 **/.* 一条 —— 前导 .. 让四条默认规则全部失配（../a/node_modules、../a/cache、../a/.cache 均为 false，去掉前缀均为 true）；
3. 原文那张"证据表"是用反斜杠候选路径算出来的，而 chokidar 在把路径交给 matcher 函数之前会统一 normalizePath()（sysPath.normalize() 再 replace(/\\/g, '/')），所以那是应用里不会出现的输入；
4. 在复现的监听环境里，谓词不会因为此前缀丢弃整个 root：外部 root 下修改源码文件能够触发，坏掉的是默认排除规则；
5. 原文那句"线上行为与表格完全一致"所依据的观测，真因是另一件事（见下节），不是谓词丢树。

原文的 摘要、根因 两节与那张表因此作废，下文是重写后的版本。原文中仍然成立的部分（"不是安全问题"、环境）保留在末尾。

---

摘要（重写）

dsh-hmr 的 ignored 谓词不感知「监视根相对 profile 目录的前缀」。当监视根位于 profile 之外时，relative(profileDir, path) 以 .. 开头，默认的 ["**/node_modules", "**/.*", "cache", "data"] 全部失配，于是 node_modules、.cache、cache、data 这些本该排除的目录不再被排除 —— 而故障是静默的：没有报错、没有警告日志。另外 cache 与 data 两条默认规则是基名锚定的，只在相对路径最顶层生效，与 root 位置无关，因此在 profile 内它对本就是失效的。

根因（重写）

dsh/node_modules/@deepseek-ai/dsh-hmr/lib/index.js（默认配置在 :240-246，谓词与 watcher 在 :379-392）：

const match = picomatch(ignored)                                  // ["**/node_modules", "**/.*", "cache", "data"]
const watchBaseDir = realpathSync(this.baseDir)                   // profile 目录
this.watcher = watch(root, {
  ...this.config,
  cwd: watchBaseDir,
  ignored: (path) => match(relative(watchBaseDir, path)),         // ← 问题在这里
  ignoreInitial: true
})

relative(profileDir, path) 对「同盘但在 profile 之外」的候选返回以 .. 开头的路径，而四条默认规则没有一条是为这种前缀写的：

picomatch(D)('../a/node_modules') = false      // 应为 true
picomatch(D)('../a/cache')        = false
picomatch(D)('../a/.cache')       = false
picomatch(D)('a/node_modules')    = true       // 对照：去掉 '..' 前缀

同时，cache 与 data 这两条没有 **/ 前缀，是基名锚定的，只在相对路径最顶层匹配：

picomatch('cache')('cache')                = true
picomatch('cache')('dev-plugins/p/cache')  = false

也就是说这两条对任何嵌套的 cache/data 目录从来就不生效，profile 内也一样。

实测证据（重写）

A. 谓词层（真 picomatch 4.0.4 回放） —— 上节命令即证据，结论是"前导 .. 让四条默认规则全部失配"，而不是"整棵树被忽略"。

B. 监听层（真 chokidar 4.0.3 + 真 picomatch 4.0.4，真实目录树） —— 同一份谓词，两种监视根布局各跑一遍，判据为「源码文件必须触发；node_modules/.cache/cache/data 必须静默」：

监视根	源码文件	node_modules	.cache	cache	data
profile 内	触发	正确排除	正确排除	泄漏	泄漏
profile 外（兄弟目录）	触发	泄漏	泄漏	泄漏	泄漏

两栏的"泄漏"是同一个根因：候选路径不被任何默认规则覆盖；差别只是前缀。

C. 说明等级，避免又一次把结论说过头 —— 上表来自复现监听环境的测量（真实的 chokidar/picomatch/目录树，shipped 的调用形状），不是在「以外部 root 启动的完整应用」里测的。我没有那个直接证据，理由见下节。

另一件独立的事（这条是完整应用里实测的）：运行中改 root 不会重建监视器

原文那句"线上行为与表格完全一致（外部同盘根 30 秒无反应）"的观测本身是真的，但真因不是谓词：

• profile 内的 root：改完源码 141 ms 热重载（不重启）；
• 把 root 改成同盘、profile 之外的目录（目录先建好，再触发一次配置重载）：之后连改三次 revision 常量，30 秒以上毫无反应；改回 profile 内那份，立刻恢复；
• 在插件里加探针直接询问运行中的 hmr 服务：它自报的 root 始终是原来的 %DSH_HOME%\profiles\desktop\dev-plugins —— 那个外部 root 根本没有被建成监视根；
• 代码上对得上：watch(root, …) 只在 start() 里出现一次，配置重载路径只调用 reconcileProfilePatches。

所以那句话应该写成：改 patch 里的 root 不会重建已在运行的监视器，外部 root 只会（可能）在下次启动时生效 —— 后半句我没有验证，不断言。原文据此得出的"整个根被静默丢弃"是把这个真因误记到了谓词头上。

建议修法（重写，且不作为结论）

我原来推荐「剥掉开头的 ..」是错的：剥掉的正是 pattern 需要的信息，node_modules/.cache 的排除会一起坏掉，自定义规则也对不上候选。

在我实际对照过的三种谓词里（shipped / 剥前缀 / 相对每个 root），只有"判定相对每个 root"同时满足两种布局，也能连 cache/data 那条一起修好：

ignored: (path) => match(relative(rootDir, path)),   // 每个 root 各自相对

但我不把它写成结论：判据（以外部 root 启动一次应用、改一次源码、看是否触发）我还没做。下面两条我认为属于维护者的 API 决策，不该由报告者顺手定：

1. 对既有「相对 profile 目录」语义下写的自定义规则是破坏性变更 —— 显式标注、加 ignoreBase: 'profile' | 'root' 或别的方式；
2. cache/data 若本意是全局排除，应写成 **/cache/**/data（或移出默认表）。

无论如何建议保留一条：当某条 ignore 规则把某个配置的 root 整个吞掉时打 warn。这个 bug 每一版的代价都在「静默」上。

不是安全问题

明确一点：这不是认证或沙箱绕过。与安全相关的只有「排除规则静默失效会让被监视的范围超出预期」。它对 /api 围栏或插件加载器的信任模型没有任何影响。

环境

Windows 11 x64，DSH 0.2.0-rc.2（desktop profile），Node 24。

[LingYi-Liang]

同盘、profile 外的目录这个我也复现了。在 Windows 上用了当前 master（5badb15）的 ignored 判断和 Chokidar 4.0.3：分别修改文件三次，profile 内的目录收到三次 change，外面的目录一次都没收到；同一个外部目录去掉 ignored 后，三次都能收到。

不过 patch 文件那一段在当前 master 上没有复现。watchConfig 会先去掉 ignored 和 cwd，再单独监听配置文件。我把配置放在测试目录的 .dsh 下面，用现有的 watchConfig 跑，三次修改都收到了。

这里测的是真实文件监听和 watchConfig，没有启动完整 DSH。修法上想先确认一下：自定义 ignored 现在是相对 profile 目录匹配的，这个语义需要继续保留吗？改成相对每个 root 后，一些现有规则的含义可能会变。

[ws177]

感谢复现，也感谢指出 patch 那一段 —— 你是对的，那一段我撤回。

关于 patch/config 那一段：我错了，而且是我自己不严谨

那一段是我从谓词推断出来的（"同一谓词也管着 manifest/patch 的监视"），我把它写成了断言，没有实测。按你指出的 watchConfig 会先去掉 ignored 和 cwd 再单独监听配置文件，我在完整应用上补了端到端验证（Windows 11 x64，DSH 0.2.0-rc.2 desktop profile）：

操作（编辑 cordis.patch.yml，不重启）	观测
把某插件条目的 disabled: false 改成 true	该插件的 /api/.../status 立刻变 HTTP 404；内部探测集从 19/19 掉到 16/19
再改回 false	3 秒内 /status 恢复（返回 200 与预期 JSON），探测回到 19/19
新增一条 - id: <telemetry 条目> disabled: true	该条目在活加载树里的状态由 schema 变为 inactive

也就是说：配置文件确实是被单独监听的，profile patch 的改动会即时生效，你和我各自的测试在这一点上一致。原文第二段（"第二个后果：点号目录下的配置也不会被热重载"）请当作无效。

关于修法：ignored 的语义要不要保留

我的看法是：当前这套"相对 profile 目录匹配"的语义，在 profile 之外的 root 上从来就没有真正生效过，所以对"外部 root"而言没有需要保留的行为。理由就是你复现出的那条路径：只要 root 在 profile 外，relative(baseDir, path) 必然以 .. 开头，而默认规则里的 **/.* 会把它整个吃掉 —— 此时用户自定义的 pattern 根本轮不到参与匹配。

真正会被"改成相对每个 root"影响的是profile 内部的路径：像 data、foo/bar 这类自定义 pattern，今天相对 profile 目录解释，改成相对 root 后含义会变。这是对已有自定义配置的破坏性变更，只是它藏在"修 bug"里。

所以我倾向于最小且不改变语义的修法：只归一化候选路径，把开头的 .. 段剥掉再匹配（.. 永远不可能是合法的点号文件名）：

const candidate = relative(watchBaseDir, path).replace(/^(\.\.[\\/])+/u, '')
return match(candidate)

• profile 内的路径：candidate 与今天完全相同，任何现有规则（含自定义）含义不变；
• profile 外的路径：从"整根被静默忽略"变成"按默认/自定义 pattern 正常判断"；
• 默认的 **/node_modules、**/.*、cache、data 两种写法下都仍然成立。

如果长期确实想要"相对每个 root"的语义，建议做成显式的行为变更（例如加一个 ignoreBase: 'profile' | 'root' 开关、文档标注 breaking + 迁移说明），而不是在修 bug 时顺手改掉 pattern 的含义 —— 否则自定义 ignored 的用户会静默地换掉行为。

另外强烈建议把"某个配置的 root 被谓词整个吃掉"变成一条 warn 日志：这个 bug 之所以难查，代价全在"静默"上；有了这条日志，第一次配置就会暴露。

我这边的端到端数据（供参考）

Windows 11 x64，0.2.0-rc.2 desktop profile，用宿主模块里的手改 revision 常量做探针：

配置的监视根	结果
工作区在另一个盘（X:\...）	改动 Host 模块会在进程内重载（复现两次）
同盘、profile 之外（两处不同路径）	同样改动 30 秒内毫无反应
同盘、profile 之内	改动 2 秒内生效（/status 的 revision 翻转）

这与你 chokidar 层面的结果是同一个根因：跨盘时 path.relative 退化成绝对路径、不带 ..，所以"恰好能工作" —— 这也是它长期没被发现的原因。

[LingYi-Liang]

谢谢补测，配置监听这点我们结果一致。

我按你这段改法又跑了一次 Windows 文件监听。外部目录能收到修改了，但它下面的 node_modules 和 .cache 也各收到了三次 change，默认排除没有生效。

另外，自定义 ignored 可以替换默认值。我用 ..\..\plugins\generated 这条规则单独测了：原来能排除 generated 目录，剥掉前缀后就排除不了了。所以外部目录的自定义规则也有兼容性需要保留。我先把这两个例子补在这里，修法还需要把它们一起考虑进去。

[ws177]

感谢补测 —— 你这两条反例都成立，而且我上一轮给的修法是错的，我撤回。

你的两条反例：一条我复现了，一条我没有，如实说

我把你的场景做成了真实文件监听（真的 chokidar 4.0.3 + 真的 picomatch 4.0.4，真实目录树），三种谓词对照，判据是「源码文件必须触发、node_modules / .cache / cache / data 必须静默」。你的两条例子结果分开：

监视根相对 profile 目录	现状（shipped）	剥掉开头 ..（我上轮的修法）	相对每个 root（你的主张）
在 profile 内	cache、data 泄漏	cache、data 泄漏	全部正确
在 profile 外的兄弟目录	四条默认全泄漏	cache、data 泄漏	全部正确

你的第 2 条（自定义规则）我确认成立：..\..\plugins\generated 在剥掉前缀后必然对不上候选 —— picomatch('..\..\plugins\generated')('plugins/generated') = false，这是纯匹配问题，不需要跑监听。这一条足以否定我那个修法。

你的第 1 条（node_modules/.cache 在剥掉前缀后仍泄漏）我没有复现出来，如实报告，不当作你在说错：

• 我按"被排除项是外部 root 的直接子级"搭了一棵树（<外部 root>/node_modules、<外部 root>/.cache），剥掉前缀后候选变成 node_modules、.cache，pm('**/node_modules')('node_modules') = true、pm('**/.*')('.cache') = true，两者都被正确排除；
• 换成嵌套形状（<外部 root>/p/node_modules）结果相同；
• 我这边在剥前缀之后仍然泄漏的是 cache 和 data（见下一节：那两条是基名锚定的，与 root 位置无关）。

我们大概不是同一套归一化代码：我测的是 relative(base, path).replace(/^(\.\.[\\/])+/u, '')。如果你那边用的是带反斜杠的候选、或者归一化发生在别的位置，结论会不一样 —— 这一点我承认我没有你的实现细节。但无论哪一边，"剥前缀"这个修法都是错的，理由就是你的第 2 条加上下面 cache/data 那条。

还有一条你可能也会关心：cache / data 今天本来就是坏的

ignored 的默认值是 ["**/node_modules", "**/.*", "cache", "data"]，但后两条没有 **/ 前缀，是基名锚定的：

picomatch('cache')('cache')                = true
picomatch('cache')('dev-plugins/p/cache')  = false

也就是说它们只在相对路径的最顶层生效。harness 里 profile 内的 node_modules、.cache 都被正确排除，而 cache、data 没有。这跟 root 在不在 profile 里无关，是独立的一条。

我上轮那段解释也错了，一起撤回

我写的是「**/.* 会把这些开头的 .. 段当成点号文件段匹配掉，于是整个根被忽略」。把该谓词拿真实 picomatch 回放，结果是：

picomatch('**/.*')('..')                    = true
picomatch('**/.*')('../..')                 = false
picomatch('**/.*')('../a/.cache')           = false
picomatch('**/node_modules')('../a/node_modules') = false

两点更正：

1. 不是「.. 被当成点号段」的直观解释 —— 我实测到的就是这个形状：**/.* 对单个 .. 匹配，而 .. 后面只要还有内容就整体失配，所以 ../..、../a/.cache 都是 false。我把编译出来的正则贴出来对过，但「它到底排除什么形状」我不想再写超出上面这几个观测的解释 —— 上一次就是因为讲了机制而没有测机制，才把这话说错的。
2. 不只是 **/.* 一条 —— 前导 .. 让四条默认规则全部失配：pm(D)('../a/node_modules')、('../a/cache')、('../a/.cache') 全是 false，而同样的路径去掉 .. 前缀都是 true。这一点影响修法选择：如果只是点号规则的问题，锚定那条规则就够了；四条一起坏，说明问题在候选路径的前缀上。

另外 chokidar 在把路径交给 matcher 函数之前会统一做 normalizePath()（sysPath.normalize() 再 replace(/\\/g, '/')），函数型 matcher 不会被 normalizeIgnored() 包装，所以我最早那张用反斜杠候选算出来的表是无效输入。

结论的措辞我也要收紧：在 harness 里，谓词不会因为这个前缀就丢弃整个 root（外部 root 下改源码文件是能触发的），坏掉的是默认排除规则。我原来的"整个根被静默丢弃、热重载等于关闭"是错的。至于活体应用里外部 root 的真实行为，我下面说明为什么我至今没有直接证据。

顺带一条独立观测（这条是活体实测）：改 patch 里的 root 不会重建已在运行的监视器

我在真实应用里做了对照：profile 内的 root 改完源码 141 ms 就重载；把 root 改成同盘、profile 之外的目录（目录先建好，再触发一次配置重载），之后连改三次 revision 常量 30 秒以上毫无反应；随后改回 profile 内那份，立刻恢复。

当时我在插件里加了探针直接问运行中的 hmr 服务，它自报的 root 始终是原来的 [.../profiles/desktop/dev-plugins] —— 也就是说那个外部 root 根本没被建成监视根。代码上也对得上：watch(root, …) 只在 start() 里出现一次，配置重载路径只调 reconcileProfilePatches。

所以我不能说「换成外部 root 重启就会好」，只能说「运行中改不生效」 —— 前者我没有证据。这也解释了为什么我上次观测到「外部同盘 root 编辑后几分钟无变化」：当时监视器还在旧 root 上，那不是谓词把整棵树丢了。

修法：先不动，等一个判据

你问 ignored 的语义要不要保留。我的看法收窄成一句：在我实际对照过的那三种谓词里（shipped / 剥前缀 / 相对每个 root），只有「相对每个 root」与你的两条反例都相容，也是唯一连 cache/data 一起修好的那个 —— 这也正是你当时的主张，我现在同意它比我上轮那个"剥前缀"更对。我没有穷举所有候选，所以这不是"唯一正确的修法"。

但我不想再把它写成结论，原因就是上面那节：判据还没拿到。在「以外部 root 启动一次应用、改一次源码、看是否触发」这件事做完之前，我不下"哪个修法对"的判断。

顺带两条我认为该由维护者决定、不该由我顺手定的：

1. 对既有「相对 profile 目录」语义下写的自定义 pattern 是破坏性变更 —— 显式标注、加 ignoreBase: 'profile' | 'root' 开关、还是别的，这是 API 决策；
2. cache / data 如果本意是全局排除，应该写成 **/cache / **/data（或者干脆不放进默认表），现在这两条只在顶层生效。

另外我仍然建议保留一条：当某条 ignore 规则把某个配置的 root 整个吞掉时打 warn。这个 bug 每一版的代价都在「静默」上。

关于「两个例子要一起考虑」，我把它展开成约束

你说得对，单独看任何一个例子都会得出错的修法。把目前确认的几件事摆在一起，任何候选修法至少要同时满足：

1. 默认排除在 profile 外也要生效（前导 .. 不能让四条默认规则一起失配）；
2. cache / data 的语义要说清：今天它们只匹配相对路径最顶层，所以要么承认它们只在顶层生效、要么改成 **/cache / **/data，不能维持"名字像全局排除、实际锚在顶层"的现状；
3. 既有自定义规则的兼容性：..\..\plugins\generated 这类写法只有在前缀保留时才可能匹配 —— 如果改成相对 root，这类规则必然要迁移，所以要么显式 breaking + 迁移说明，要么给个开关，不能让它们在"修 bug"里静默换义；
4. 默认与自定义的替换关系要保留：你说自定义 ignored 可以替换默认值 —— 那么"忽略规则相对谁解释"这件事就必须对两者一致，否则替换默认值之后语义又变了。

第 3 与第 1/2 条是相互拉扯的：保留前缀对自定义规则友好但对默认规则不友好，改成相对 root 反之。我认为这是这件事真正的设计取舍，而不是一个可以顺手定掉的 bug —— 这也是我不再自己拍修法的原因。