code --status是定位VSCode高CPU问题的首要手段，可10秒内精准列出Extension Host、tsserver等子进程PID及CPU%，据此禁用插件、配置files.watcherExclude为"/node_modules/":true、降级语言服务并彻底重启窗口。
VSCode 启动后 CPU 飙高，基本不是编辑器本身的问题，而是某个子进程在后台疯跑——直接看 code --status 就能定位真凶，不用猜、不重装、不盲禁。
用 code --status 快速锁定高占用子进程
别信任务管理器里那个“Code Helper”进程，它只是壳。真正吃 CPU 的是 Extension Host、tsserver、pyright 或 rg.exe 这类子进程。
-
Extension HostCPU% 长期 >50% → 某个扩展（比如esbenp.prettier-vscode或gitlens.gitlens）在监听失败后卡死或反复解析 - 出现
tsserver或pyright且内存 >400MB → 正在全量加载node_modules/@types做类型推导 -
Search进程内存 >300MB →rg.exe正在扫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 子进程持续满载——你什么都没干，CPU 就飙到 70%。
- 必须写在项目根目录的
.vscode/settings.json中（不是用户级设置） - 通配符必须是
"**/node_modules/**": true，写成*/node_modules/*、/node_modules/或node_modules全无效 - 改完必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区才生效
- Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高
语言服务降级比禁用扩展更有效
Python 和 TypeScript 扩展不是“慢”，是默认把整个依赖树加载进内存做类型推导；一个含 50+ 包的项目，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、.md） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
禁用扩展必须彻底重启窗口
很多插件注册了 onStartupFinished 或 onLanguage:python 等激活事件，一旦触发就会常驻内存。禁用操作只是阻止新加载，旧进程不会退出。
- 先运行命令面板中的
Developer: Show Running Extensions，确认哪些插件真在跑 - 右键目标插件 →
Disable (For All Folders) - 必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区
- 对 Python/TS 项目，可手动清理残留：
ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后kill -9 [PID]
最隐蔽的坑是：配置写对了、插件也禁了，但没彻底关窗重开——所有优化都白做。这点容易被忽略，但恰恰是多数人卡住的地方。
