vscode崩溃时应立即按ctrl+shift+i（win/linux）或cmd+option+i（macos）打开开发者工具抓取实时错误，优先查看console中红色堆栈（如uncaught error），若无法启动则转向main.log和exthost日志查err!、exthost process exited等关键线索。
VSCode 崩溃时，Ctrl+Shift+I 打开的开发者工具不是“事后分析器”，而是唯一能抓到实时崩溃瞬间的透视镜——但前提是它还能启动；一旦渲染进程已死，就得立刻转向日志文件，别等弹窗、别重装。
崩溃卡死时怎么快速打开开发者工具看实时错误
很多崩溃发生在点击菜单、切换标签或触发某个扩展命令后，界面冻结但进程还在。这时 Ctrl+Shift+I（Windows/Linux）或 Cmd+Option+I（macOS）是第一反应，不用等界面响应，卡住时也尽量按。
- 切到
Console面板，优先扫红色堆栈，特别是含Uncaught Error或Cannot read property 'xxx' of null的行 - 如果
Console空白但界面无响应，切到Network标签，看是否有大量pending请求——常见于插件调用语言服务器超时，或证书校验失败（比如企业代理拦截 HTTPS） - 注意：某些崩溃会直接 kill 渲染进程，导致 DevTools 自身无法打开。此时按了没反应，就说明该退到日志文件了
main.log 里哪些关键词能一眼锁定崩溃根源
main.log 是主进程的“黑匣子”，记录从启动到退出的全部生命周期事件。崩溃前最后一行成功日志 + 紧接着的报错，往往就是断点。
- 搜索
ERR!或[error]，比搜ERROR更精准，避免匹配到日志中的普通字符串 - 重点盯
Failed to create window（macOS 显卡驱动/系统版本问题）、Segmentation fault（原生模块冲突）、EACCES（权限拒绝，常见于 WSL 或 Docker Desktop 环境） - 看到
Exthost process exited with code后跟非零数字（如1、-6），说明扩展宿主已崩，此时必须查exthost*.log，而非继续翻main.log -
WebGL: CONTEXT_LOST_WEBGL出现多次？基本可判定是 GPU 加速兼容问题，加--disable-gpu启动验证
如何用 code --verbose 快速复现并定位启动阶段崩溃
如果 VSCode 根本打不开（图标转圈、任务管理器里有进程但没窗口），code --verbose 是唯一可靠入口——它绕过 GUI 层，强制把初始化每一步都打印到终端。
- 关闭所有 VSCode 实例后，在终端执行：
code --verbose - 观察输出最后停在哪一步：常见卡点是
Starting extension host（扩展宿主加载失败）、Creating window（窗口创建失败）、Loading app（Electron 主进程依赖缺失） - 若卡在
Starting extension host，立刻补上--log debug：code --verbose --log debug，它会暴露具体哪个插件的activate()函数抛了异常 - 终端输出中若出现
Segmentation fault或IPC connection closed，大概率是某扩展调用了不兼容的原生模块
扩展宿主崩溃后，为什么 Developer: Open Extension Host Log 有时打不开
因为 exthost 进程崩溃得太早，连日志写入逻辑都没来得及初始化。这不是日志“没生成”，而是根本没机会写。
- 先运行
Developer: Open Extension Host Log，如果日志为空或提示“无法打开”，说明崩溃发生在日志系统就绪之前 - 此时别再翻日志，直接进安全模式：
code --disable-extensions（macOS/Linux）或 Shift+点击图标（Windows） - 安全模式下稳定 → 100% 是插件问题；仍崩溃 → 问题在 VSCode 本体、系统环境（如 Node.js 兼容性）、或用户配置（如
settings.json里写了非法 JSON） - 确认是插件导致后，别用“禁用全部再逐个启用”这种低效方式，改用
code --disable-extension ms-python.python这类精确禁用命令，能跳过激活逻辑，更快隔离
真正难的不是找日志，而是判断哪条日志是“因”、哪条是“果”。比如 Extension host terminated 是结果，而它上面三行那个 TypeError 才是根因——很多人只盯着最后一行，反而绕远路。
