code --status是VSCode性能诊断第一入口，可查看Extension Host、tsserver等子进程PID及实时CPU%和内存占用，重点排查插件冲突、文件监听爆炸及语言服务全量索引问题。
直接运行 code --status 查进程真实负载
VSCode 界面没卡但风扇狂转，说明问题不在主 UI 进程，而在某个后台子进程里。任务管理器里那个 Code Helper 进程只是壳，不能信。必须在终端执行 code --status，它会列出所有真实子进程（Extension Host、tsserver、pyright、cpptools-srv、Search 等）的 PID、实时 CPU% 和内存占用。
重点关注这几类：
-
Extension HostCPU > 60% 且不回落 → 某插件在 onSave 轮询、监听失败后卡死，或注册了onStartupFinished后常驻不退出 -
tsserver/pyright/cpptools-srv占高 → 不是语言本身慢，是正在全量索引node_modules/@types或整个依赖树 -
Search进程内存 > 300MB →rg.exe正在扫node_modules或符号链接目录 -
Shared Process占高 → 遥测（telemetry.telemetryLevel）、设置同步或自动更新在后台轮询
禁用插件后 CPU 不降？旧进程根本没退出
点“Disable”只是阻止新加载，已激活的插件进程仍在跑——这是最常被忽略的坑。很多插件（比如 ms-python.python、esbenp.prettier-vscode、gitlens.gitlens）一旦触发 onLanguage:python 就会长驻内存。
正确操作必须三步到位：
- 先运行命令面板中的
Developer: Show Running Extensions，按 CPU% 排序，确认哪个插件真在跑 - 右键目标插件 →
Disable (For All Folders)（注意不是仅当前工作区） - 必须完全关闭当前 VSCode 窗口（不是
Developer: Reload Window），再重新打开工作区
对 Python/TS/C++ 项目，建议手动清理残留：ps aux | grep -i "pyright\|tsserver\|cpptools"，找到 PID 后 kill -9 [PID]。
files.watcherExclude 写错等于白配
VSCode 默认用 chokidar 递归监听整个工作区。遇到 node_modules（几万小文件）、dist、.git 目录时，inotify 事件爆炸式触发，Node.js 子进程直接满载——你什么都没干，CPU 就稳定在 70%+。
关键点：
- 通配符必须是
"**/node_modules/**": true，写成*node_modules*、/node_modules/或*/node_modules/*全无效 - 配置必须加在项目根目录的
.vscode/settings.json中，不是用户级settings.json - 配置后必须完全关闭 VSCode 窗口再重开才生效；仅保存文件不触发更新
- Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高
语言服务降级比禁用插件更实用
Python 和 TypeScript 扩展不是“慢”，是默认太贪：试图把整个依赖树加载进内存做类型推导。一个含 50+ 包的项目，Extension Host 内存轻松破 1.2GB。
实操建议：
- 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% 内存
真正难处理的是那些带无限重试逻辑的插件（比如 Codex 插件 v26.325+ 的死循环 Bug），这类必须降级到已知稳定版本，重启生效——别指望配置能绕过代码缺陷。
