code --status 是定位失控 Node 进程的唯一可靠入口，它实时列出 Extension Host、tsserver 等子进程 PID 与 CPU%，配合 files.watcherExclude（如 "/node_modules/": true）并重启工作区可有效解决 CPU 过高问题。
code --status 是定位失控 Node 进程的唯一可靠入口
VSCode 里吃 CPU 的 node 进程，几乎都不是主进程，而是 Extension Host、Search 或语言服务器（如 tsserver、pyright、lingma-server）启动的子进程。任务管理器里看到的 “Code Helper” 只是壳，没参考价值。
直接在终端执行：code --status，它会列出所有子进程的 PID、CPU% 和内存占用——不卡 UI、不依赖插件、结果实时。
- 重点关注
Extension Host：CPU > 60% 且持续不降 → 某个插件（如esbenp.prettier-vscode、gitlens.gitlens）在轮询或解析失败后卡死 -
Search进程内存 > 300MB 或 CPU 飙高 → 很可能正在用rg.exe扫描node_modules或符号链接目录 - 命令行含
tsserver、pyright、cpptools-srv的进程 → 对应语言服务索引行为失控，不是“慢”，是默认加载整个依赖树
记下高占用进程的 PID，再用 ps -p [pid] -o args=（macOS/Linux）或任务管理器“详细信息”页看完整命令行，就能确认是哪个扩展或服务在发疯。
files.watcherExclude 写错等于没配，通配符必须是 **/xxx/**
VSCode 默认用 chokidar 递归监听整个工作区。一旦项目里有 node_modules（几万小文件），内核级 inotify 事件就会爆炸式触发，node 子进程持续满载——你什么都没做，风扇就狂转。
必须在项目根目录的 .vscode/settings.json 中配置，不是用户级设置：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/*.log": true
}
}
- 通配符必须是
**/node_modules/**，写成*/node_modules/*、/node_modules/或node_modules全无效 - 配置生效需关闭并重新打开整个工作区，仅保存文件或重载窗口不触发更新
- Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288建议调高（临时：echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches）
语言服务器和 AI 插件的索引行为最容易被忽略
Python 扩展（ms-python.python）和 TypeScript 语言服务不是“慢”，是默认把整个依赖树加载进内存做类型推导；通义灵码这类 AI 插件则默认对整个工作区做代码索引——它们都以 node 进程形式运行，但 UI 里完全没提示。
- Python：把
python.languageServer从 Pylance 改为Jedi（Jedi 不做全量语义分析） - TypeScript：设
typescript.preferences.includePackageJsonAutoImports为off，避免导入时反复解析node_modules/@types - ESLint：设
eslint.run为onType，并精简eslint.probe的文件类型（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
别把整个磁盘或用户目录当工作区打开
这是最常被忽略的根源性操作。VSCode 的文件监视器不会智能跳过无关目录——只要你把 /home/user 或 C:\ 当作工作区打开，chokidar 就会尝试监听所有子路径，包括 ~/Downloads、~/Desktop、甚至挂载的网络盘。
- 只打开真正要编辑的子文件夹，比如
~/projects/my-app，而不是~/projects - 如果必须打开多项目根目录，用 VSCode 的“多根工作区”（.code-workspace）并为每个文件夹单独配置
files.watcherExclude -
search.exclude和files.exclude是另一层过滤，顺手加上也能减轻 I/O 压力，但不能替代files.watcherExclude
真正卡住的时候，往往不是某个功能太重，而是监听范围失控——**/node_modules/** 这一行写对了，重启也做了，但工作区开得太大，照样白搭。
