code --status 可快速定位 VSCode 高 CPU 占用真凶：Extension Host、tsserver/pyright、Search 或 Shared Process 的异常 PID 和命令行一目了然，结合配置 files.watcherExclude、降级语言服务等措施即可精准治理。
VSCode CPU 占用高，90% 以上不是编辑器本身的问题，而是某个后台子进程在疯跑——code --status 一眼就能定位真凶，不用猜、不盲禁、不重装。
怎么用 code --status 快速定位高占用进程
别盯着任务管理器里那个“Code Helper”进程——它只是壳。真正干活的是子进程：
-
Extension Host: CPU% 长期 >60%，说明某个扩展（比如esbenp.prettier-vscode或gitlens.gitlens）在反复解析、监听失败后卡死 -
tsserver或pyright: 不是 TypeScript/Python 本身慢，是正在全量加载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 这种几万小文件目录，inotify 事件爆炸式触发，Node.js 子进程直接满载：
- 必须写在项目根目录的
.vscode/settings.json中（不是用户级设置） - 通配符必须是
"**/node_modules/**": true，写成*/node_modules/*或node_modules都无效 - 配置后必须完全关闭当前 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为onSave，并精简eslint.probe的文件类型（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
插件更新期间 CPU 满载的特别处理
插件更新会触发语言服务器重载、文件监视器重建、索引全量刷新三重叠加，尤其 files.watcherExclude 未配或错误时，node_modules 被扫描是 CPU 满载主因：
- 更新弹窗刚出现就立刻跑
code --status，重点关注Extension Host和单独的tsserver/pyright进程 - 更新前手动降级语言服务更可靠：Python 项目切
Jedi，TS 项目关includePackageJsonAutoImports - 更新后必须彻底退出 VSCode（不是重载窗口），再重启——否则旧 watcher 和语言服务进程仍驻留
- Linux 用户注意：临时调高的
inotify.max_user_watches在重启后失效，如需永久生效得写入/etc/sysctl.conf
最常被忽略的是：改了 files.watcherExclude 或语言服务配置后，只保存不重启窗口，等于白配；还有 Linux 下 inotify 句柄数不足时，watcher 会静默失败再重试，CPU 看似不高但文件变更根本不响应。
