VSCode 的 watcher 吃光 CPU 和内存是因为默认为大量小文件（如 node_modules）每个子目录注册监听器，导致事件风暴；需通过 files.watcherExclude 精准排除无关路径、关闭扩展自启监听、并调高系统 inotify 限制。
为什么 VSCode 的 watcher 会吃光 CPU 和内存
VSCode 默认使用操作系统的原生文件监视机制（如 Linux 的 inotify、macOS 的 FSEvents、Windows 的 FindFirstChangeNotification），但当工作区包含大量小文件（比如 node_modules、dist、.git）时，它会为每个子目录注册监听器，触发频繁的事件合并与路径匹配。这不是 VSCode 故意卡你，而是默认配置没做裁剪——尤其在 WSL2 或远程开发场景下，inotify 句柄数不足还会直接报错：ENOSPC: System limit for number of file watchers reached。
- 典型诱因：打开整个项目根目录（而非仅 src）、未排除构建产物目录、启用多个扩展（如 ESLint、Prettier、TypeScript 插件）各自启动独立 watcher
- 真实瓶颈常不在 VSCode 主进程，而在后台运行的
code-watcher子进程或 Electron 的 Node.js 事件循环 - Windows 用户还可能遇到
chokidar底层 fallback 到轮询（usePolling: true），导致持续磁盘 I/O
用 files.watcherExclude 精准屏蔽无关路径
这是最直接有效的控制点——它作用于 VSCode 内置的文件监视器，不依赖扩展，且优先级高于扩展自己的配置。
- 在工作区
.vscode/settings.json中设置（避免污染全局）：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/bower_components/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/coverage/**": true,
"**/logs/**": true
}
}
- 注意通配符语法：
**匹配任意层级子目录，*只匹配当前层级；路径末尾的/**表示“该目录及其全部子孙” - 不要写成
"node_modules/**"（缺**/前缀），否则只匹配项目根下的node_modules，嵌套子模块（如 lerna monorepo 中的packages/foo/node_modules）仍会被监听 - 如果用了 pnpm，还需额外加
"**/.pnpm/**": true，因为 pnpm 的硬链接结构会让 watcher 更难收敛
关闭不必要的扩展自动监视行为
很多语言扩展（尤其是 TypeScript、ESLint、Vetur、Go）会在激活后自行启动文件监听，它们不走 files.watcherExclude，必须单独关。
- TypeScript：设置
"typescript.preferences.autoImportSuggestions.enabled": false可减少对node_modules的扫描频率；更彻底的是禁用"typescript.preferences.includePackageJsonAutoImports": "auto" - ESLint：确保
"eslint.run": "onType"（而非onSave或onStartup），并检查是否误启用了"eslint.workingDirectories"扫描了不该扫的子目录 - Remote-SSH / WSL 用户：确认没有在远程端重复启用本地已有的扩展；可改用
Remote Explorer的「Extensions on SSH」视图，只启用真正需要的几个
系统级调优（Linux/macOS）
当 VSCode 报 ENOSPC 错误，说明内核的 inotify 限制被击穿，这时需调整系统参数，不是 VSCode 能自己解决的。
- 临时提升（重启失效）：
sudo sysctl fs.inotify.max_user_watches=524288 - 永久生效：向
/etc/sysctl.conf追加一行fs.inotify.max_user_watches=524288，然后执行sudo sysctl -p - macOS 用户注意：
FSEvents没有类似限制，但如果用的是nodemon或某些 CLI 工具配合 VSCode，它们可能内部用了chokidar并强制启用轮询，此时应检查这些工具自身的配置（如nodemon --poll）
真正麻烦的从来不是配置项本身，而是不同层级的 watcher（系统 → VSCode → 扩展 → 第三方 CLI）相互叠加又互不可见。一个 node_modules 目录，可能同时被 VSCode 主进程、TypeScript 语言服务、ESLint 扩展、以及你正在终端里跑的 webpack --watch 四路监听——这时候光调 watcherExclude 不够，得一层层揪出来关掉。
