files.watcherexclude 配置不生效的主因是通配符写法错误、作用域不当或未重启工作区；正确写法为"/node_modules/": true，须置于项目级 .vscode/settings.json 并完全重启工作区。
files.watcherExclude 配不生效？检查通配符写法和作用域
VSCode 文件监听 CPU 满载，八成是因为 files.watcherExclude 没配对——不是没配，是写错了。常见错误包括："node_modules/**"、"*/node_modules/*"、"node_modules"，这些全被 VSCode 忽略，等于没写。
真正生效的写法只有一种："**/node_modules/**": true。双星号前缀表示“任意层级路径”，后缀表示“该目录下所有子项”，缺一不可。
- 必须写进项目根目录下的
.vscode/settings.json，用户级设置（如~/Library/Application Support/Code/User/settings.json）对多项目无效 - 改完保存后，必须关闭并重新打开该工作区；仅按
Cmd+Shift+P → Developer: Reload Window不会应用新规则 - 推荐标配组合：
"**/dist/**": true、"**/build/**": true、"**/.git/**": true、"**/coverage/**": true、"**/*.log": true
Linux 下 inotify 句柄耗尽，监听会静默失败
VSCode 底层用系统 inotify 监听文件变化，Linux 默认 max_user_watches 常为 8192。一个中等 node_modules 就能占满，结果不是报错，而是 watcher 反复重建、静默退出——你感觉“改了文件没反应”“Git 状态不更新”“保存延迟明显”，但 CPU 却不高。
查当前值：cat /proc/sys/fs/inotify/max_user_watches。若低于 524288，立即调高：
echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
这个改动重启后失效；如需永久生效，追加一行到 /etc/sysctl.conf：
fs.inotify.max_user_watches=524288
macOS 用户不用调这个，FSEvents 无此限制，但 files.watcherExclude 仍要配。
search.exclude 和 files.watcherExclude 是两套独立机制
files.watcherExclude 控制“是否监听文件变更”，search.exclude 控制“全文搜索是否扫描该路径”。两者不互斥，漏配任何一个，都可能让 CPU 或内存爆表。
-
search.exclude同样写在.vscode/settings.json中，结构一致，但键名不同 -
"**/node_modules/**": true和"**/node_modules": true在search.exclude中都有效，但建议统一用前者保持风格 - 没配
search.exclude时，按Cmd+Shift+F搜索，rg.exe（RipGrep）会暴力遍历node_modules，瞬间吃光 I/O 和内存
WSL/Docker 或监听延迟高？试试启用实验性监听器
在 WSL2、Docker 挂载卷或网络文件系统上，VSCode 默认监听器常因路径解析问题静默失效，表现为“外部修改文件后不提示‘文件已被更改’”。
解决办法是启用实验性监听器："files.useExperimentalFileWatcher": true。它混合使用轮询 + 系统原生 API，在兼容性上更稳。
- 该选项在 VSCode 1.84+ 已默认开启，但旧版本或企业策略禁用时仍需手动添加
- 启用后必须完全退出 VSCode 再重启，热重载不生效
- 副作用是 CPU 占用略升（尤其大工作区），但对现代机器影响极小；若发现反而更卡，可关掉再试
真正难搞的是三者叠加：错误的通配符写法 + Linux inotify 句柄不足 + search.exclude 漏配。任何一个没到位，性能瓶颈就还在那儿等着你。
