code --status是唯一可信起点，可立即列出extension host、tsserver等子进程pid、cpu%和内存占用；需据此定位高占用进程，配置"/node_modules/": true并彻底重启窗口。
VSCode 高 CPU 占用几乎从不源于编辑器主进程，而是某个后台子进程失控——code --status 一眼就能定位真凶，不用猜、不重装、不盲禁扩展。
怎么看哪个进程在疯跑
别盯着任务管理器里那个 Code Helper (Renderer)——它只是壳。真正吃 CPU 的是子进程：
-
Extension HostCPU% 长期 >60%：大概率是esbenp.prettier-vscode、gitlens.gitlens或ms-python.python在反复解析或监听失败后卡死 -
tsserver或pyright占高：不是语言本身慢，是正在全量加载node_modules/@types或整个依赖树做类型推导 -
rg（RipGrep）内存 >300MB：八成在扫node_modules、.git或符号链接目录 -
Shared Process占高：遥测、同步或自动更新在轮询，可临时加"telemetry.telemetryLevel": "off"验证
记下高占用进程的 PID，再用 ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”，确认命令行里是不是含 pylance、tsserver 或 rg --files。
为什么 files.watcherExclude 配了没用
VSCode 默认用 chokidar 递归监听整个工作区，遇到 node_modules 这种几万小文件的目录，inotify 事件爆炸式触发，Node.js 子进程直接满载——你什么都没干，CPU 就飙到 100%。
- 必须写在项目根目录的
.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% 内存
禁用扩展必须彻底重启窗口
点“Disable”只是阻止新加载，旧进程仍常驻内存。很多插件注册了 onStartupFinished 或 onLanguage:python，一旦激活就一直跑着。
- 先运行命令面板中的
Developer: Show Running Extensions，确认ms-python.python确实在运行中 - 右键该插件 →
Disable (For All Folders)（注意不是仅当前工作区） - 必须完全关闭当前 VSCode 窗口（不是
Developer: Reload Window），再重新打开工作区 - 对 Python 项目，建议手动清理残留：
ps aux | grep -i "pyright\|python.*language"，找到 PID 后kill -9 [PID]
最常被忽略的是：files.watcherExclude 改完不关窗重开 = 白配；code --status 不看 PID 对应的命令行 = 白查；禁用扩展后只重载窗口 = 白禁。
