必须每次高CPU时运行code --status定位真实子进程，确认其反复启动原因；严格配置files.watcherExclude（/xxx/格式、项目级设置、彻底重启）、降级语言服务器（如Python改用Jedi）、手动清理残留进程。
VSCode高CPU占用反复出现，说明问题没被根除，不是重启或临时禁用就能压住的——必须定位到具体子进程、确认它为什么反复启动、再切断触发链。
code --status 必须每次出问题时都跑一遍
很多人只在第一次卡顿时运行 code --status，记下 PID 后就去改配置，结果过两天又飙高。但实际每次高 CPU 的“真凶”可能不同：
- 第一次是
Extension Host里ms-python.python启动了pyright，全量加载node_modules/@types - 第二次是
Search进程被rg.exe卡住，正在扫**/logs/*.log下几万行日志 - 第三次是
Shared Process因telemetry轮询失败后指数退避重试，每 2 秒拉一次遥测端点
所以只要风扇一响、Activity Monitor 里看到 Code Helper 持续 >60%，第一反应就是开终端跑 code --status，别凭记忆操作。
files.watcherExclude 配错或没生效是最常见漏网原因
你写了 "**/node_modules/**": true，但 CPU 还是高？检查这三点：
- 配置是否写在项目根目录的
.vscode/settings.json里（不是用户级settings.json） - 通配符是否严格为
**/xxx/**—— 写成*/node_modules/*、node_modules/或**/node_modules全无效 - 改完是否彻底关闭当前 VSCode 窗口（不是重载），再重新打开该工作区？仅保存文件不触发 watcher 重建
Linux 用户还要顺手检查：cat /proc/sys/fs/inotify/max_user_watches，低于 524288 就得调高，否则 watcher 会静默失败并不断重试，CPU 就这么被“骗”满的。
语言服务降级比禁用插件更稳
禁用 ms-python.python 能压 CPU，但你也丢了补全和跳转；而降级语言服务器，既保留基础功能，又砍掉最耗资源的部分：
- Python：把
python.languageServer改为Jedi（不加载@types，不做语义推导） - TypeScript：关掉
typescript.preferences.includePackageJsonAutoImports（避免导入时扫整个node_modules） - ESLint：设
eslint.run为onType，并精简eslint.probe（比如去掉.json和.md）
这些不是“阉割”，而是让语言服务回归它该干的事：语法检查，不是全量建模。
插件残留进程和配置常在后台复活
你以为禁用了 GitLens，但它可能还在后台跑着：
- 右键插件选
Disable (For All Folders)后，必须手动执行Developer: Reload Window，否则旧Extension Host进程仍驻留 - 检查
settings.json是否还留着"gitlens.codeLens.enabled": true这类开关，即使插件禁用，某些逻辑仍会被触发 -
.vscode/extensions.json里的"recommendations"会自动唤起插件，打开工作区时弹窗点“是”，前功尽弃
真正干净的做法：禁用 → 关闭窗口 → 终端执行 ps aux | grep -i "gitlens\|pyright\|tsserver" → 手动 kill -9 [PID] → 再打开。
反复高 CPU 的本质，是某个进程在“反复尝试做一件它做不完的事”——可能是监听爆炸、类型推导超时、遥测连不上、搜索路径失控。盯住 code --status 输出的 PID 和命令行，比任何经验贴都管用。
