定位 extension host terminated 错误需先查扩展宿主日志：Ctrl+Shift+P → Developer: Open Extension Host Log，末尾 ERROR 中的插件 ID（如 ms-python.python）即元凶；若日志为空，则用 code --disable-extension 逐个隔离验证，确认后删除对应插件目录即可。
插件崩溃时 extension host terminated 错误怎么定位
看到 Extension host terminated unexpectedly 或 Failed to activate extension，说明扩展宿主进程（exthost）已退出，但 VSCode 主界面可能还在——这不是卡顿，是后台支撑逻辑已断。关键不是看弹窗，而是立刻查日志。
打开命令面板（Ctrl+Shift+P / Cmd+Shift+P），运行 Developer: Open Extension Host Log。日志里最后一段 ERROR 通常就是罪魁祸首，比如：
ERROR Error: Cannot read property 'onDidChangeTextDocument' of undefined
at activate (/Users/xxx/.vscode/extensions/ms-python.python-2026.3.1/dist/extension.js:1)
注意报错路径中的插件 ID（如 ms-python.python）和版本号（如 2026.3.1），这就是要优先处理的目标。
若日志为空或打不开，说明 exthost 崩溃得太早，连日志写入都失败了——此时必须退到命令行启动阶段排查。
如何用 --disable-extension 快速隔离问题插件
code --disable-extension 是比“禁用再启用”更干净的验证方式：它跳过加载指定插件的全部逻辑，包括其 activate() 函数调用，避免残留状态干扰。
- 先列出所有插件：
code --list-extensions - 挑一个近期更新/常出问题的，例如
code --disable-extension ms-python.python - 如果启动正常，就确认是它；如果不正常，换下一个，比如
code --disable-extension esbenp.prettier-vscode - 别用
--disable-extensions一锅端——它虽然快，但无法锁定具体是哪个插件在 spawn 子进程时失败（比如 Python 插件调python命令却因路径含空格崩掉）
注意：禁用命令只影响本次启动，不修改插件文件。若确认某插件是元凶，可直接删其目录：rm -rf ~/.vscode/extensions/ms-python.python-2026.3.1（macOS/Linux）或 del /s /q "%APPDATA%\Code\Extensions\ms-python.python-2026.3.1"（Windows）。
为什么某些插件一启动就崩溃，而其他时候正常
崩溃往往发生在特定上下文：打开某个项目、切换工作区、甚至只是聚焦编辑器窗口。常见诱因不是代码本身，而是环境耦合：
- 插件依赖的外部工具路径含中文、空格或特殊符号（如
C:\Program Files\Python39\python.exe→ spawn 失败，日志只显示exit code: null） - 语言服务器（LSP）启动超时被强制 kill，尤其在低内存或 SSD 响应慢的机器上
- 插件使用了已被 VSCode 废弃的 API（如
vscode.workspace.rootPath，新版已改用vscode.workspace.workspaceFolders） - 多个同类型插件共存（如同时启用
esbenp.prettier-vscode和esbenp.prettier-eslint），互相劫持格式化触发时机
这类问题不会在安全模式下暴露，因为安全模式不加载插件；也不会在空项目里复现——必须用你实际出问题的项目路径启动测试：code --disable-extension ms-python.python /path/to/your/project。
exthost 崩溃后还能不能恢复未保存内容
能，但前提是没手动删掉 Backups 目录或关掉自动保存。
VSCode 的恢复机制不依赖插件，而是靠本地缓存快照。强制退出后重启，只要看到“恢复编辑器”弹窗，就立刻点“恢复”。若没弹窗，检查：
-
files.autoSave是否设为off（建议改成onFocusChange） - 用户数据目录下的
Backups子目录是否还存在（Windows：%APPDATA%\Code\Backups；macOS：~/Library/Application Support/Code/Backups） - 是否启用了
workspaces.json自动恢复（该文件损坏会导致恢复流程静默失败）
最易被忽略的一点：崩溃插件可能已污染 globalStorage 数据库（比如 Python 插件写入异常的 interpreter 缓存），导致下次启动时即使禁用该插件，仍会因读取旧缓存而再次崩溃。这种情况下，清空 globalStorage 比重装插件更有效。
