code --status 可秒出VSCode所有后台子进程的PID、CPU%和内存占用，关键看CPU%、Memory、Process三列，是定位高负载进程的唯一可信起点。
直接看 code --status，别猜、别 reload、别关再开——它能秒出真实子进程的 PID、CPU% 和内存占用，这才是唯一可信起点。
怎么用 code --status 快速定位高负载进程
这个命令不依赖 UI，不触发插件激活逻辑，输出就是当前所有后台子进程的快照。关键看三列：CPU%、Memory、Process 名称。
-
Extension HostCPU 长期 >60% → 某插件在 onSave、onDidChange 或监听失败后卡死，不是“慢”，是彻底挂住 - 进程名含
tsserver或pyright→ 语言服务正在全量解析node_modules/@types或venv，和你写的代码无关 -
Search进程 RSS >300MB →rg.exe（ripgrep）正扫node_modules或符号链接目录，search.followSymlinks设为false可堵住源头 - 看到
copilot或lingma-server占满 CPU → 后台索引在跑，关闭当前文件不影响它，但可临时禁用对应插件验证
files.watcherExclude 配错等于没配
VSCode 默认用 chokidar 监听整个工作区，node_modules 里几万小文件会让 inotify 事件爆炸式触发，Node 子进程持续满载——你什么都没改，CPU 就 80%+。
- 必须写在项目根目录的
.vscode/settings.json中，用户级设置无效 - 通配符必须是
"**/node_modules/**": true，"node_modules"、"*/node_modules/*"、"/node_modules/"全部不生效 - 改完必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区
- Linux 用户还需检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就得调高，否则 watcher 会静默失败并不断重试
崩溃类问题：为什么禁用插件后还崩
点“Disable”只是阻止新加载，旧进程仍在跑——这是最常被忽略的坑。很多插件注册了 onStartupFinished 或 onLanguage:python 这类激活事件，一旦触发就常驻内存。
- 先运行命令面板中的
Developer: Show Running Extensions，按CPU%排序，确认哪些插件真在跑 - 右键目标插件 →
Disable (For All Folders)（注意不是仅限当前工作区） - 必须完全关闭当前 VSCode 窗口，再重新打开工作区
- Python/TS 项目还可手动清理残留：
ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后kill -9 [PID]
日志里藏了最直接的线索
弹窗只说 Extension host terminated unexpectedly，但日志里有堆栈、路径、甚至 Node.js 版本不兼容提示。光看 UI 是猜，看日志才是查。
- 打开输出面板（
Ctrl+Shift+U），下拉选择Extension Host - 搜索
Extension host terminated unexpectedly或ERR!，往上翻几屏找堆栈开头 - 常见线索：
TypeError: Cannot read property 'onDidChange' of undefined（访问已销毁对象）、at augment.*.js:123:45（直指插件文件）、Failed to load module 'vscode'（Node.js 环境异常） - 日志路径：
%APPDATA%\Code\logs\exthost1.log（Windows）、~/Library/Application Support/Code/logs/*/exthost1.log（macOS）
真正麻烦的不是插件多，而是某些插件（比如旧版 Python、SFTP、AI 补全类）会在启动时尝试 spawn 外部进程，而路径含空格、中文或权限不足会导致静默失败——这种错误不会报在控制台，只会在日志末尾留一行 ENOENT 或 EACCES，容易被跳过。
