安全模式可快速确认是否为插件问题：windows/linux按住shift启动，macos执行code --disable-extensions；若安全模式下不崩溃，则必为扩展所致，否则需排查系统、vscode本体或配置。
用安全模式快速确认是否是插件问题
如果 VSCode 频繁弹出 扩展宿主意外终止，第一步不是猜哪个插件坏了，而是先切断所有插件干扰——直接进安全模式。这时候 VSCode 不加载任何第三方扩展，只跑官方核心逻辑。
- Windows/Linux：启动时按住
Shift键，再点击图标打开 - macOS 或命令行用户：终端执行
code --disable-extensions - 如果安全模式下完全不崩溃，说明 100% 是某个扩展惹的祸；如果还崩，问题可能在系统环境、VSCode 本体或用户配置上
逐个禁用 + 观察资源占用锁定罪魁
确认是插件导致后，别一口气全关——那样会漏掉“组合冲突”（比如 A 和 B 单独都 OK，一起开就崩）。更靠谱的做法是分批禁用 + 实时盯进程资源。
- 打开命令面板（
Ctrl+Shift+P），输入并运行Extensions: Disable All Installed Extensions - 重启 VSCode，确认稳定后，再逐组启用（比如先开语言类：Python、TypeScript；再加工具类：GitLens、Prettier）
- 同时打开任务管理器（
Ctrl+Shift+Esc），筛选Code Helper (Renderer)或exthost进程，看哪个启用后 CPU 突升、内存暴涨或直接消失 - 特别注意近期更新过的插件，尤其是
augment、SFTP、AI 补全类、大型 LSP 客户端（如rust-analyzer、pylsp）
查日志比猜更快：定位崩溃前最后一行调用
VSCode 的 exthost 日志里藏了最直接的线索，比如哪行 JS 报错、哪个插件的 activate 方法卡死、甚至 Node.js 版本不兼容提示。光看弹窗文字没用，得翻原始输出。
- 打开输出面板（
Ctrl+Shift+U），下拉选择Extension Host - 搜索关键词：
Extension host terminated unexpectedly或ERR!，往上翻几屏找堆栈开头 - 常见线索示例：
TypeError: Cannot read property 'onDidChange' of undefined（某插件访问了已销毁对象）；Failed to load module 'vscode'（Node.js 环境异常）；at augment.*.js:123:45（直指augment插件文件） - 日志路径（可直接用资源管理器打开）：
%APPDATA%Codelogs\exthost1.log（Windows）、~/Library/Application Support/Code/logs//exthost1.log（macOS）
别跳过缓存和环境：重装插件≠解决问题
很多人卸载再重装插件后还是崩，是因为旧缓存没清、Node.js 版本太低、或者 sftp.json 这类配置本身触发了底层加密模块异常——这些细节不处理，换十个版本都没用。
- 删缓存目录：
%USERPROFILE%.vscodeextensions（Windows）或~/.vscode/extensions（macOS/Linux），删完再重启 VSCode - 检查 Node.js：某些插件（尤其基于 WebAssembly 或原生模块的）要求 Node.js ≥18，运行
node -v确认，旧版建议升级到v20.x LTS - 检查特殊配置：如果你用了
sftp插件，确认.vscode/sftp.json中有"algorithms"字段，否则 SSH 协商失败会连带拖垮扩展宿主 - 关闭遥测有时也有效：设置里搜
telemetry，把Telemetry: Telemetry Level设为off，避免某些上报逻辑在弱网/代理下超时卡死
真正难排查的往往不是单个插件崩溃，而是多个插件对同一事件（比如文件保存、焦点切换）反复监听又没清理句柄，导致内存泄漏缓慢积累——这种问题必须靠日志 + 资源监控交叉验证，不能只依赖“禁用再试”。
