VSCode崩溃卡死时应立即按Ctrl+Shift+I打开开发者工具查Console红色堆栈，若无效则查main.log中ERR!、Failed to create window等关键词，或运行code --verbose定位启动断点。
VSCode 崩溃后不弹错误框、不闪退、只是卡死或反复重启？别急着重装，它其实默默记下了所有线索——关键是要去对的地方找，而不是等它“主动告诉你”。
崩溃时怎么快速打开开发者工具看实时错误
很多崩溃发生在渲染进程（比如点击某个菜单后界面冻结），这时 Developer: Toggle Developer Tools 是第一反应按钮。它不是事后分析工具，而是“正在崩溃时”的透视镜。
- 快捷键：
Ctrl+Shift+I（Windows/Linux）或Cmd+Option+I（macOS），无需等 VSCode 完全响应，卡住时也尽量按 - 切换到
Console面板，优先扫红色堆栈——尤其是带Uncaught Error或Cannot read property 'xxx' of null的行 - 若 Console 空白但界面无响应，切到
Network标签，看是否有大量 pending 请求（常见于插件调用语言服务器超时或证书校验失败） - 注意：某些崩溃会直接 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()函数抛了异常 - Windows 用户避免用 Git Bash 运行该命令，改用 PowerShell；macOS 用户注意检查
sw_vers是否 ≥ 12.0，否则--verbose输出可能被截断
崩溃后 Output 面板为什么经常是空的，怎么让它吐出有用信息
Output 面板不是“所有日志的汇总”，而是“各服务主动上报的结构化输出”。空 ≠ 没日志，而是你没选对通道，或插件根本没开启日志开关。
- 先确认面板已打开：
Ctrl+Shift+U（别依赖侧边栏图标，它可能被隐藏） - 右上角下拉菜单必须手动切换到对应服务，比如崩溃前刚用了 Git 操作，就选
Git；如果是 Python 扩展异常，选Python或Pylance，而不是默认的Tasks - 部分插件（如
prettier、eslint）需显式开启日志："prettier.trace.server": "verbose"，否则Output里只有激活事件，没有运行时细节 - 如果所有通道都是空的，且
Developer Tools → Console也无报错，大概率是主进程崩溃早于任何扩展加载——这时只能靠main.log或code --verbose
真正容易被忽略的是：崩溃日志不是“一次性快照”，而是分层生成的。主进程、渲染进程、扩展宿主各自写各自的文件，跨进程通信失败时，线索往往散落在 main.log 和 exthost*.log 的时间戳交界处。别只盯着一个文件猛翻，对比时间戳才是关键。
