extension host崩溃是扩展问题，非vscode本身故障；需先用code --disable-extensions进入安全模式验证，再通过developer: show running extensions和extension host日志交叉定位泄漏扩展，并配置affinity与watcherexclude治本。
这是 Extension Host 进程崩溃的明确信号，不是 VSCode 本身坏了，而是某个扩展在吃内存、卡死或触发 Node.js 底层异常（比如 SIGSEGV 或 FATAL ERROR: Ineffective mark-compacts）。
怎么快速确认是不是扩展惹的祸
别猜，直接进安全模式切断所有干扰：
- Windows / Linux：终端运行
code --disable-extensions - macOS：确保已配置
code命令后，同样运行code --disable-extensions - 如果此时不再弹
Extension host terminated unexpectedly，说明 100% 是扩展问题；如果还崩，得查系统、VSCode 本体或用户目录残留（比如%APPDATA%\Code或~/Library/Application Support/Code下的损坏缓存）
如何精准定位是哪个扩展在泄漏或崩溃
安全模式验证后，用两个确定性手段交叉锁定：
- 打开命令面板（
Ctrl+Shift+P），运行Developer: Show Running Extensions—— 它显示每个扩展当前估算的内存占用（单位 MB），重点关注ms-python.python、esbenp.prettier-vscode、gitlens这类常驻服务型插件 - 看崩溃日志里最后一行调用：输出面板 → 切换到
Extension Host，找含_onExtProcessError或具体扩展 ID（如bradlc.vscode-tailwindcss）的堆栈；若刷屏太快，可先禁用一半扩展再重启对比 - 特别注意“组合冲突”：比如
ms-python.python和ms-python.pylance同时启用，会重复加载解析器；prettier-vscode+eslint+editorconfig共同设为默认 formatter，保存时触发多轮 AST 构建并驻留
为什么加 --max-memory=4096 有时没用
这个参数只限制 VSCode 主进程（Electron 渲染器）的 V8 堆内存，对 Extension Host 进程完全无效 —— 后者是独立 Node.js 子进程，默认无上限。你看到的高内存（比如持续 >500MB）往往来自它。
- 真正治本的是在
.vscode/settings.json中配"extensions.experimental.affinity": { "ms-python.python": 2 }，让高危扩展跑在独立进程中，避免一个泄漏拖垮全部 - 同时必须配
"files.watcherExclude"排除**/node_modules/**、**/dist/**等目录，否则 chokidar 监听数万小文件会耗尽 inotify 句柄，内存随项目规模线性增长 - 临时缓解可用
code --max-memory=4096 --disable-gpu --disable-extensions启动，但不解决根本——扩展一旦启用，宿主仍可能因循环监听或未 dispose 的 watcher 崩溃
复杂点在于：崩溃不一定立刻发生，可能是某个扩展在后台缓慢泄漏（比如监听器没 dispose()、缓存没 clear()），导致内存爬升到临界点才报错；而日志里那行 FATAL ERROR: Ineffective mark-compacts near heap limit 往往已是最后通牒，线索其实在它之前几十行被刷掉的 warning 里。
