确认文件监听卡顿需查code --status中Search内存>300MB或Extension Host CPU>70%，并用Developer: Open Process Explorer看火焰图是否集中在chokidar/fs.watch；files.watcherExclude必须写为"/node_modules/": true等双星号加前后斜杠格式，且仅在项目级.vscode/settings.json生效，改后须彻底重启工作区。
VSCode 文件监听卡顿，八成不是机器问题，而是 files.watcherExclude 没配对、没生效，或者 Linux 的 inotify.max_user_watches 耗尽了。
怎么确认是文件监听在拖慢 VSCode？
别猜，直接看进程。终端执行 code --status，重点观察两行：
-
Search进程内存 > 300MB → 很可能是rg.exe（RipGrep）正在暴力扫node_modules或日志目录 -
Extension HostCPU 长期 > 70% → 多数由未排除的监听目录触发大量onDidChangeFile事件，chokidar 来不及消费，堆积重试
再打开命令面板，运行 Developer: Open Process Explorer，点开每个进程右侧的“Profile”图标录一段 10 秒 CPU Profile——如果火焰图里大量堆在 chokidar、fs.watch 或 Node.js 的事件循环回调里，基本就坐实了。
files.watcherExclude 必须怎么写才生效？
常见错误写法："node_modules/**"、"*/node_modules/*"、"node_modules" —— 全部无效，VSCode 直接忽略。
真正能匹配任意层级子路径的，只有双星号前后都带斜杠的格式：
"**/node_modules/**": true"**/dist/**": true"**/build/**": true"**/.git/**": true"**/*.log": true
必须写进项目根目录下的 .vscode/settings.json（不是用户级设置），改完后必须关闭并重新打开该工作区——仅“重载窗口”不触发新规则。
Linux 下 inotify.max_user_watches 不够会怎样？
它不会报错，也不会弹提示，而是静默失败：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 是两回事
前者关的是搜索范围，后者关的是文件系统事件监听——两者独立，缺一不可。
没配 search.exclude，按 Cmd+Shift+F 搜代码时，rg.exe 仍会把 node_modules 当文本暴力遍历，吃光内存和 I/O。
配置结构一致，也写在 .vscode/settings.json 里：
"search.exclude": { "**/node_modules": true, "**/dist": true, "**/build": true }
注意："**/node_modules" 和 "**/node_modules/**" 在 search.exclude 里都有效，但为统一风格，建议全用前者。
最容易被忽略的点是：files.watcherExclude 规则只对新增监听生效；已建立的监听不会自动刷新。所以哪怕你改对了配置，也得彻底关掉工作区再重开——这点比大多数文档写得更硬性。
