直接运行code --status可立即定位真实高占用子进程（如extension host、tsserver、pyright、rg等），而非“code helper”壳进程；需结合pid查命令行、严格配置files.watcherexclude、禁用/降级插件并彻底重启窗口。
直接运行 code --status，就能立刻看到真实高占用进程——不是“Code Helper”那个壳，而是 Extension Host、tsserver、pyright、rg 这些子进程。
怎么看 code --status 输出里谁在吃 CPU
打开终端，cd 到任意目录，执行 code --status。它会列出所有子进程的 PID、CPU% 和内存占用。重点关注这几类：
-
Extension Host：CPU% 长期 >60%，说明某个扩展（比如esbenp.prettier-vscode或gitlens.gitlens）在 onSave 或监听失败后卡死 -
tsserver/pyright/cpptools-srv：不是语言本身慢，是正在全量加载node_modules/@types或整个依赖树做类型推导 -
rg（ripgrep）：内存 >300MB，大概率在扫node_modules或符号链接目录 -
Shared Process：占高通常来自遥测轮询、设置同步或自动更新，可临时加"telemetry.telemetryLevel": "off"验证
记下高占用进程的 PID，再用 ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”，确认命令行里是否含扩展名或语言服务器路径。
files.watcherExclude 配错等于没配
VSCode 默认用 chokidar 监听整个工作区，遇到 node_modules（几万小文件）、dist、.git 就触发 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就要调高
禁用扩展 ≠ 进程退出
点“Disable”只是阻止新加载，旧进程仍在后台常驻——尤其那些注册了 onStartupFinished 或 onLanguage:python 的插件。
- 先运行命令面板中的
Developer: Show Running Extensions，按 CPU% 排序，确认哪个插件真在跑 - 右键目标插件 →
Disable (For All Folders)（注意不是仅当前工作区） - 必须彻底关闭当前窗口，再重新打开工作区
- 对 Python/TS 项目，建议手动清理残留：
ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后kill -9 [PID]
语言服务降级比禁用更稳
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% 内存
最易被忽略的是：即使你改了配置，不重启窗口就等于白改；而很多插件启动后不会因配置变更自动 reload，得靠 kill + 重开才能真正清空上下文。
