VSCode文件监控吃CPU的核心原因是默认监听node_modules等目录触发大量inotify事件，应先用code --status定位高占用进程，再在项目.vscode/settings.json中配置"/node_modules/": true等规则并彻底重启工作区，Linux还需调高inotify.max_user_watches至524288。
VSCode 文件监控吃 CPU，核心原因不是“它太重”，而是默认监听了不该监听的目录——比如 node_modules，一进来就触发几万次 inotify 事件，Node.js 子进程直接满载。
用 code --status 先确认是不是 watcher 在疯跑
别猜，直接开终端执行：code --status。重点看两行：
-
Extension HostCPU% 长期 >60%，说明某个扩展（比如esbenp.prettier-vscode）在反复监听失败后卡死 -
Search进程内存 >300MB，大概率是rg.exe正在扫node_modules或符号链接目录 - 拿到高占用进程 PID 后，用
ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页确认命令名，比如node /path/to/pylance或tsserver
files.watcherExclude 必须配对、写对、重启才生效
这是最直接有效的控制点，作用于 VSCode 内置监视器，不依赖任何扩展。
- 必须写在项目根目录的
.vscode/settings.json里，用户级设置对多项目无效 - 通配符必须是
"**/node_modules/**": true——"node_modules/**"、"*/node_modules/*"、"node_modules"全都无效 - 常见必加项：
"**/dist/**": true、"**/build/**": true、"**/.git/**": true、"**/coverage/**": true、"**/*.log": true - 改完保存后，必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区才生效
Linux 用户要检查 inotify 句柄数是否够用
Linux 默认 max_user_watches 常为 8192，一个 node_modules 就可能耗尽，导致 watcher 静默失败、反复重试——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
某些扩展的监听行为不走 files.watcherExclude，得单独关
比如 TypeScript、ESLint、GitLens 这类语言/工具扩展，启动后会自己拉起独立 watcher，和 VSCode 主监视器无关。
- TypeScript：设
"typescript.preferences.includePackageJsonAutoImports": "off"，避免导入时反复解析@types - ESLint：改
"eslint.run": "onSave"，并精简"eslint.probe"（比如去掉.json） - GitLens：关掉
"gitlens.codeLens.enabled"和"gitlens.hovers.enabled"，能降 30%–50% 内存 - Python：把
python.languageServer从Pylance改为Jedi，后者不做全量语义分析
真正卡住的地方往往不在配置本身，而在于改完没彻底重启窗口，或者误把 **/node_modules/** 写成 node_modules/** ——这种细节错一点，files.watcherExclude 就等于没配。
