基本可断定是某个插件崩溃导致——先用code --disable-extensions验证，再通过Developer: Start Extension Bisect二分定位，结合Extension Host日志中“Activating extension”行及堆栈线索精准锁定肇事插件。
“扩展宿主意外终止”弹窗反复出现，基本可以断定是某个插件在激活或运行时崩溃了——不是所有插件都崩，但只要有一个触发 Node.js 未捕获异常、同步阻塞超时或资源耗尽，整个 exthost 进程就会被系统强制杀掉。
用 code --disable-extensions 快速确认是不是插件问题
别点设置里“禁用全部扩展”，那个操作仍会加载插件元数据并尝试初始化，可能还没禁用完就崩了。必须用命令行强制跳过所有插件加载逻辑：
- Windows/Linux：打开终端，执行
code --disable-extensions（注意是--，不是-） - macOS：终端输入
code --disable-extensions，确保code命令已加入 PATH
如果此时 VSCode 完全稳定、无弹窗、CPU 内存正常，说明 100% 是插件导致；如果还崩，问题在系统环境、VSCode 本体或用户数据目录损坏。
用 Developer: Start Extension Bisect 二分定位罪魁
手动禁用再启用太慢，还容易漏掉“组合冲突”。VSCode 自带的二分排查工具能自动完成 3–4 轮测试，精准锁定激活即崩溃的插件：
- 先确保在
code --disable-extensions下运行正常 - 重启 VSCode（不带参数），按
Ctrl+Shift+P打开命令面板 - 输入并运行
Developer: Start Extension Bisect - 按提示保存、重启、观察是否弹窗；每次它会启用一半插件，帮你快速收敛范围
最后一轮确认后，VSCode 会直接高亮出那个让 activate() 卡死或抛错的插件 ID，比如 ms-python.python 或 augment.augment。
看 Extension Host 日志找崩溃前最后一行调用
弹窗文字没用，关键线索藏在日志里。打开 Ctrl+Shift+U → 下拉选 Extension Host，往上翻几屏，重点找：
- 含
Extension host terminated unexpectedly的行 - 紧挨着它的上一行，通常是
Activating extension 'xxx.xxx'—— 这就是目标 - 再往上扫堆栈，常见线索：
TypeError: Cannot read property 'onDidChange' of undefined（访问了已销毁对象）、ERR! spawn ENOENT（调用的命令如python3不在 PATH）、at augment.*.js:123:45（直指文件和行号）
日志路径可直接打开：%APPDATA%Codelogs\exthost1.log（Windows）、~/Library/Application Support/Code/logs//exthost1.log（macOS）。别只看最新日志，崩溃可能发生在昨天更新插件后的第一次启动。
特别留意这几类高危插件组合
有些插件单独用没事，一配对就崩，尤其当它们都监听相同事件（如保存、编辑器切换）时：
-
esbenp.prettier-vscode和dbaeumer.vscode-eslint同时设为editor.formatOnSave，格式化链路互相等待 -
gitlens.codeLens.enabled+ 大型 Git 仓库（>10k 文件），Codelens 渲染卡住主线程 -
Remote-SSH激活时，远程~/.vscode-server下 Node.js 版本低于本地（如本地 v18，远程 v16），LSP 初始化失败 - AI 补全类插件（如
github.copilot或某些未签名的augment分支）在 typing 时高频调用本地模型，触发内存 OOM
这些组合不会报明显错误，但会让 exthost 进程 CPU 拉满后被系统 kill，日志里只留一句 Killed —— 此时得结合任务管理器盯住 Code Helper (Renderer) 进程的内存曲线。
真正麻烦的不是找到哪个插件崩了，而是它崩之前已经污染了缓存或修改了底层配置（比如 sftp.json 里写了非法加密选项）。重装插件不清理 %APPDATA%CodeCache 或远程 ~/.vscode-server，问题大概率复现。
