VSCode 文件监听吃光 CPU 和内存的根源是未正确配置 files.watcherExclude、系统 inotify 限制过低及扩展自启监听器；需在项目级 .vscode/settings.json 中设置 "**/node\_modules/**": true 等规则，调高 inotify 句柄数，并禁用 ESLint 等绕过主监听的扩展。
VSCode 文件监听吃光 CPU 和内存，核心原因是它为每个子目录注册监听器，遇到 node_modules 这类几万文件的目录就直接崩溃——这不是 bug，是默认没排除。
为什么 files.watcherExclude 必须配在项目级 .vscode/settings.json
全局设置会漏掉嵌套结构（比如 lerna monorepo 里的 packages/foo/node_modules），只有工作区级配置才能被 VSCode 监听器真正识别。通配符必须写对：**/node_modules/** 表示“任意层级下的该目录及其全部子孙”，少一个 **/ 前缀就失效。
-
"**/node_modules/**": true—— 必加，pnpm 用户额外加"**/.pnpm/**": true -
"**/dist/**": true、"**/build/**": true—— 构建产物必排除 -
"**/.git/objects/**": true—— 避免 Git 对象库触发高频事件 - 别写
"node_modules/**"或"**/node_modules"，路径不匹配就白配
扩展自己开的监听器不走 files.watcherExclude
TypeScript、ESLint、Vetur、Go 扩展激活后会绕过 VSCode 主监听器，各自用 chokidar 启动独立 watcher，它们完全无视你的 files.watcherExclude。这类监听只能靠关扩展本身：
- 按
Cmd+Shift+P/Ctrl+Shift+P输入Developer: Show Running Extensions，看Activation Events列含onStartup或*的扩展 - ESLint、GitLens、Prettier 这类“一开就扫全项目”的，右键选
Disable (Workspace) - 禁用后必须完全退出 VSCode（包括菜单栏图标），再重开才生效
Linux/macOS 用户不调 inotify 限制等于白配
即使配了 files.watcherExclude，系统级 inotify 句柄数太低，VSCode 仍会报 ENOSPC: System limit for number of file watchers reached 并退化为轮询（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 - WSL2 用户尤其注意：这个值默认只有 8192，不改根本跑不动中大型前端项目
search.exclude 和 files.watcherExclude 是两回事
前者只影响 Ctrl+Shift+F 全局搜索范围，后者控制文件变更监听——两个都得配，否则搜索时仍会卡死在 node_modules 里遍历。
-
"search.exclude": { "**/node_modules": true, "**/dist": true }—— 注意这里不用/**后缀 - 两者路径写法不同：
files.watcherExclude要求末尾带/**表示递归，search.exclude不需要 - 如果用了符号链接，顺手加
"search.followSymlinks": false，避免重复扫描
真正卡住的时候，往往不是某一个配置没设，而是 files.watcherExclude 漏了 .pnpm、inotify 没调、扩展又在后台自启监听——三者齐发，CPU 就直接飙到 100%。先盯死这三点，比装十个“优化插件”管用得多。
