code --status是唯一可信起点，可立即列出Extension Host、tsserver等子进程PID及CPU%；需据此禁用插件、配置"/node_modules/": true、降级语言服务器并彻底重启窗口。
用 code --status 看清谁在后台疯跑
VSCode 界面没卡但风扇狂转，问题几乎肯定出在某个子进程里，而不是主窗口。任务管理器里的 “Code Helper” 只是壳，code --status 才是唯一可信的起点——它直接列出所有真实子进程的 PID、实时 CPU% 和内存占用，不依赖 UI 响应。
重点关注以下几类：
-
Extension Host：CPU% 长期 >60%，说明某个插件（如esbenp.prettier-vscode、gitlens.gitlens）在 onSave 或监听失败后卡死 - 命令行含
tsserver、pyright、cpptools-srv的进程：对应语言服务在反复解析node_modules/@types或全量索引依赖树 -
Search进程内存 >300MB：大概率是rg.exe正在暴力扫描node_modules或符号链接目录
记下高占用进程的 PID，再用 ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”（Windows），确认是否来自你装的某个插件。
禁用插件 ≠ 停止进程，必须彻底重启窗口
点 “Disable” 只是阻止新加载，旧进程仍常驻内存——这是最常被忽略的坑。很多插件注册了 onStartupFinished 或 onLanguage:python 这类激活事件，一旦触发就一直跑着。
正确操作必须包含三步：
- 先运行命令面板中的
Developer: Show Running Extensions，确认哪些插件真在运行、占多少 CPU/内存 - 右键目标插件 →
Disable (For All Folders)（注意不是仅当前工作区） - 必须完全关闭当前 VSCode 窗口（macOS 要退出菜单栏图标），再重新打开工作区；
Developer: Reload Window没用
对 Python/TS 项目，还可手动清理残留：ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后 kill -9 [PID]。
files.watcherExclude 写错等于没配
VSCode 默认用 chokidar 递归监听整个工作区，遇到 node_modules（几万小文件）、dist、.git/objects 就会触发 inotify 事件风暴，Node.js 子进程持续满载——你什么都没干，CPU 就飙到 100%。
必须在项目根目录的 .vscode/settings.json 中配置（用户级设置无效），且通配符严格：
- 必须写成
"**/node_modules/**": true，写成"node_modules"、"*/node_modules/*"或"/node_modules/"全无效 - 推荐完整配置：
"**/node_modules/**"、"**/dist/**"、"**/build/**"、"**/.git/**"、"**/*.log" - 配置生效前提：关闭当前工作区，再重新打开；仅保存
settings.json不触发重载
Linux/macOS 用户顺手检查：cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，需调高，否则 watcher 会静默失败并不断重试。
别跳过语言服务器降级这个关键动作
Python 和 TypeScript 插件不是“慢”，是默认太贪——试图把整个依赖树加载进内存做类型推导。一个含 50+ 包的项目，Extension Host 常驻内存轻松破 1.2GB，CPU 卡在 90%。
比禁用插件更实用的是降级语言服务器模式：
- 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% 内存
这些配置改完后同样要关闭并重开工作区才生效。真正难排查的从来不是哪个插件名字可疑，而是它启动的语言服务在后台默默吃光资源，还留不下明显错误日志。
