直接查看exthost日志定位崩溃插件：ctrl+shift+p运行developer: open extension host log，末尾error行中的插件id（如ms-python.python）和文件路径即为罪魁祸首；若日志为空，则需用code --disable-extensions进安全模式排查。
直接看 exthost 日志定位报错插件
崩溃弹窗本身没线索，真正有用的错误藏在 exthost 日志里。别靠猜，立刻打开它：Ctrl+Shift+P → 输入并运行 Developer: Open Extension Host Log。日志末尾的 ERROR 行大概率就是崩溃前最后一句调用，比如：
ERROR Error: Cannot read property 'onDidChangeTextDocument' of undefined
at activate (/home/user/.vscode/extensions/ms-python.python-2026.3.1/dist/extension.js:1)
重点抓两处：ms-python.python 是插件 ID，extension.js 是出问题的文件路径——这就是你要处理的目标。
若日志为空或打不开，说明崩溃发生在日志初始化之前，得退到命令行阶段排查。
用安全模式快速确认是否为插件问题
第一步不是禁用插件，而是彻底隔离干扰：启动 VSCode 时进入安全模式，不加载任何扩展。
- Windows/Linux：点击图标前按住
Shift键再松开 - macOS：终端执行
code --disable-extensions
如果安全模式下完全稳定，说明 100% 是某个扩展导致；如果还崩，问题可能在系统、VSCode 本体或用户配置（如 settings.json 里写了非法值）。
分批启用 + 盯进程锁定“高危”插件
确认是插件引发后，别一口气全关再逐个开——组合冲突很常见（A 和 B 单独 OK，一起开就崩）。更稳妥的做法是分组启用 + 实时观察资源变化：
- 先启用语言类：Python、TypeScript、Rust-analyzer
- 再加工具类：GitLens、ESLint、Prettier
- 同时打开系统任务管理器，筛选
Code Helper (Renderer)或exthost进程，看哪个启用后 CPU 突升、内存暴涨或进程直接消失 - 特别注意近期更新过的插件，尤其是
augment、SFTP、AI 补全类、或依赖原生模块的 LSP 客户端（如rust-analyzer、pylsp）
很多崩溃不是插件“坏了”，而是它和当前 Node.js 版本不兼容——运行 node -v 确认是否 ≥18，建议升级到 v20.x LTS。
清缓存比重装插件更有效
卸载重装插件后还崩？大概率旧缓存没清理干净，或者配置文件本身触发了底层异常。
- 删掉插件缓存目录：
%USERPROFILE%\.vscode\extensions（Windows）或~/.vscode/extensions（macOS/Linux） - 检查是否有异常配置项，比如
sftp.json里写了非法密钥路径，或C_Cpp.default.compilerPath指向已删除的编译器 - 某些插件（尤其含 WebAssembly 或加密模块的）会卡在 Node.js 初始化阶段，光看日志不一定报错，但进程就是起不来
真正难搞的不是崩溃本身，而是那种“只在打开特定项目时才崩”的情况——这时候得结合 Developer: Toggle Developer Tools 的 Console 面板，看弹窗瞬间打出的堆栈里有没有指向具体插件名或文件路径。
