code --status是唯一可信起点，可立即列出Extension Host、tsserver等子进程的PID、CPU%和内存占用；需据此定位高占用进程，配置files.watcherExclude为"/node_modules/": true并彻底重启窗口。
code --status 能立刻确认是不是 Extension Host 在疯跑
别看任务管理器里一堆 “Code Helper”，那只是壳。真正干活的是 Extension Host、tsserver、pyright 这类子进程。终端执行 code --status，直接列出所有子进程的 PID、CPU% 和内存占用。
重点关注：
- CPU% 长期 >60% 的 Extension Host → 某个插件（比如 esbenp.prettier-vscode 或 eamodio.gitlens）在 on-save 或文件监听失败后卡住
- 命令行含 tsserver？说明 TypeScript 服务反复解析 node_modules/@types，不是你写的代码出问题
- copilot 或 lingma-server 占满 CPU？那是后台索引在跑，和你当前编辑无关
Developer: Open Process Explorer 看谁 RSS 不释放
内存泄漏型卡顿往往不体现在 CPU 上，但会拖慢整个 Extension Host。运行 Developer: Open Process Explorer，展开 extensionHost 节点，看每个插件的 RSS（单位 MB）。
关键判断点：
- prettier-vscode 格式化大 JSON 时飙到 500MB 属正常；但关掉所有文件后还稳在 350MB，大概率泄漏
- gitlens 在 >10k 文件仓库中启用缓存后 RSS 持续 >400MB，且不随窗口关闭下降
- 禁用插件后 RSS 不降？必须执行 Developer: Restart Extension Host，否则旧进程还在跑
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 会静默失败并不断重试
Extension host terminated unexpectedly 报错怎么定位
按 Ctrl+Shift+I 打开开发者工具，切到 Console 标签页，重点扫三类报错：
- RangeError: Maximum call stack size exceeded：某插件递归监听文件变化（比如 watch 了整个 node_modules）
- Cannot read property 'onDidChangeActiveTextEditor' of undefined：插件在语言服务未就绪时就调用了编辑器 API
- 重复出现的 ERR! spawn ENOENT：插件试图调用本地不存在的命令（如 python3 或 rustc），且没做 fallback
再切到 Output 面板 → 选 Extension Host，往上翻看最后几条日志，带 ERR! 的那行通常紧挨着崩溃前最后一句 Activating extension，后面跟着插件 ID（如 ms-python.python）就是目标
真正的麻烦不是插件崩溃，而是它悄悄卡在激活阶段、不报错也不退出，让后续所有插件排队等它。这类问题必须靠 Developer: Show Running Extensions 和 Developer: Start Extension Bisect 双验证，单看控制台日志容易漏掉。
