<p>files.watcherExclude 配置不生效需先确认 VSCode 版本及工作区类型：1.80+ 版本在远程开发中该配置被忽略，仅本地工作区有效；须写入工作区设置、使用 /node_modules/ 等 glob 模式、值为 true、结尾 /** 关键；修改后需重启窗口才生效。</p>
files.watcherExclude 配置不生效？先确认 VSCode 版本和工作区类型
VSCode 1.80+ 对 files.watcherExclude 的行为做了调整：在远程开发（SSH/Containers）或使用文件系统代理的场景下，该配置可能被忽略，实际由后端服务控制。本地工作区才完全受控于这个设置。
常见错误现象：node_modules 依然被频繁扫描，CPU 占用高，保存文件后响应延迟。
- 检查是否在远程窗口中——此时需在远程端的
settings.json中配置，而非本地 - 确认配置写在「工作区设置」而非用户设置，否则多根工作区下可能不继承
-
files.watcherExclude是 glob 模式，不是正则；**/node_modules/**才匹配所有嵌套层级，node_modules只匹配项目根目录下的
正确写法：用双星号通配 + 显式排除常见干扰目录
VSCode 默认只排除 **/.git/objects/** 等极少数路径，node_modules 不在默认列表里。必须手动加，且推荐一并排除其他高频变更但无需监视的目录。
实操建议直接写进工作区 .vscode/settings.json：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/bower_components/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.next/**": true,
"**/out/**": true
}
}- 每个键是 glob 路径，值必须为
true（不能写"false"或省略） - 结尾的
/**很关键——它表示“该路径下所有子内容”，漏掉会导致只排除目录本身，不递归 - 如果项目有多个
node_modules（如 monorepo 中各 package 下），**/node_modules/**仍能全覆盖
watcherExclude 和 search.exclude 的区别别搞混
这两个配置常被一起设，但作用完全不同：files.watcherExclude 控制文件系统事件监听范围，影响 CPU 和内存；search.exclude 只影响搜索框（Ctrl+Shift+F）结果展示，不节省资源。
- 想降低资源占用，只改
files.watcherExclude就够了 -
search.exclude可以更宽松（比如排除**/*.log），但对性能无帮助 - 两者语法一致，但修改
search.exclude不会减少文件监视器压力
Windows 上启用 WSL 文件监视需额外处理
在 WSL2 中打开 Windows 文件系统（如 /mnt/c/Users/xxx/project）时，VSCode 默认使用 Windows 文件监视器，files.watcherExclude 可能部分失效，尤其对符号链接或深层嵌套的 node_modules。
- 优先把项目放在 WSL 原生路径（如
~/project），再用 VSCode Remote - WSL 打开 - 若必须用
/mnt/，可在 WSL 中执行echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p提升 inotify 限制 - VSCode 设置里关掉
files.useExperimentalFileWatcher（设为false），旧版 watcher 在 WSL 上反而更稳定
文件监视的排除逻辑是“静态路径匹配 + 启动时加载”，改完配置要重启 VSCode 窗口才生效。很多人改了没反应，其实是忘了重开——这点最容易被忽略。
