code --status是定位VSCode高CPU问题的真相入口，可直接查看各子进程PID及实时CPU%，结合ps命令精准定位疯跑的扩展或语言服务器进程。
code --status 是唯一能直接告诉你“哪个进程在吃 CPU”的命令，别猜、别重装、别关插件再开——先运行它，看到 Extension Host、tsserver、pyright 或 cpptools-srv 的 CPU% 长期高于 60%，就说明多进程已失控，调整限制不是加资源，而是砍掉不该跑的。
怎么看哪个子进程在疯跑
VSCode 主界面卡不卡不重要，真正拖垮系统的是后台 Node.js 子进程。打开终端执行：
code --status
它会立刻列出所有子进程 PID、CPU% 和内存占用。重点关注这几类：
-
Extension Host：CPU > 60% → 某个扩展（比如esbenp.prettier-vscode或gitlens.gitlens）监听失败后卡死循环 -
tsserver/pyright/cpptools-srv：不是语言本身慢，是正在全量扫描node_modules/@types或整个构建目录做类型推导 -
Search进程内存 > 300MB：大概率rg.exe正在扫node_modules或符号链接目录 -
Shared Process占高：遥测、同步、自动更新在后台高频轮询
记下高占用进程的 PID，再用 ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”，确认实际启动命令——很多问题出在插件自己拉起的二进制，不是 VSCode 本身。
files.watcherExclude 必须配对且重启才生效
VSCode 默认用 chokidar 递归监听整个工作区，node_modules 这种几万小文件目录一触发就是 inotify 事件风暴，Node.js 子进程直接满载。这不是配置“建议”，是必选项：
- 必须写在项目根目录的
.vscode/settings.json中（不是用户级设置） - 通配符必须是
"**/node_modules/**": true，写成*/node_modules/*、/node_modules/或node_modules全无效 - 配置后必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区才生效
- Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高
远程开发时 extensions.experimental.affinity 控制插件在哪跑
Remote-SSH 下 CPU 暴涨，根本原因是 VSCode 默认把所有插件（尤其是 LSP 类）全扔到远程服务器上运行。本地只渲染 UI，远程却扛着全部解析压力：
- 在远程服务器的
~/.vscode-server/data/Machine/settings.json中添加：{"extensions.experimental.affinity": {"*": 0}}→ 强制所有插件本地运行（仅限支持 UI 扩展的） - 若必须远程运行某插件（如
ms-python.python依赖的pylsp），单独设：{"extensions.experimental.affinity": {"ms-python.python": 1}}（1 = 仅远程） - 禁用远程端插件要选 Disable (Remote)，不是 Disable (Workspace)
- 顺手关掉
telemetry.telemetryLevel和update.mode，避免 Shared Process 在后台轮询
语言服务降级比禁用插件更稳
Python 和 TypeScript 插件不是“有问题”，是默认太贪——试图把整个依赖树加载进内存做语义分析。中大型项目下，Extension Host 内存破 1.2GB、CPU 持续拉高是设计使然：
- 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% 内存
最常被忽略的一点：files.watcherExclude 配错等于没配，而 code --status 里看到的 PID，才是你该 kill 的真实目标——不是插件名，是那个正在跑的 node 进程。
