VSCode大型项目CPU飙高90%以上源于后台进程异常，用code --status可精准定位Extension Host、tsserver等高占用进程；需正确配置files.watcherExclude、调优语言服务器并彻底终止残留进程。
VSCode 在大型项目中 CPU 持续飙高，90% 以上不是编辑器本身的问题，而是某个后台进程在“疯跑”——code --status 一眼就能定位真凶，不用猜、不重装、不盲目禁用扩展。
怎么看谁在吃 CPU：必须用 code --status
别盯着任务管理器里那个 “Code Helper” 进程——它只是壳。真正干活的是子进程：
-
Extension Host长期 >60% CPU → 某个扩展（比如esbenp.prettier-vscode、gitlens.gitlens或ms-python.python）监听失败后卡死，或 onSave 逻辑反复触发 - 看到
tsserver、pyright、cpptools-srv占高 → 不是语言本身慢，是它们正在全量加载node_modules/@types或整个依赖树做类型推导 -
Search进程内存 >300MB →rg.exe（ripgrep）正在扫node_modules或符号链接目录 -
Shared Process占高 → 遥测、设置同步或自动更新在后台轮询；可临时加"telemetry.telemetryLevel": "off"验证
记下高占用进程的 PID，再用 ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”，确认命令行里是否含 pylance、tsserver、cpptools 等关键词。
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） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
禁用插件后 CPU 不降？旧进程根本没退出
很多插件注册了 onStartupFinished 或 onLanguage:python 这类激活事件，一旦触发就常驻内存。点 “Disable” 只是阻止新加载，旧进程仍在跑——这是最常被忽略的坑。
- 先运行命令面板中的
Developer: Show Running Extensions，按 CPU% 排序，确认哪些插件真在跑 - 右键目标插件 →
Disable (For All Folders)（注意不是仅限当前工作区） - 必须完全关闭当前 VSCode 窗口（不是
Developer: Reload Window），再重新打开工作区 - 对 Python/TS 项目，还可手动清理残留：
ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后kill -9 [PID]
真正卡住你的，往往不是某个开关没开，而是某个进程没杀干净、某个路径没排除对、某个配置没落在项目级 settings 里——这些细节不处理，所有优化都白搭。
