应立即执行“Developer: Restart Extension Host”热重启扩展宿主，恢复语法高亮、自动补全等功能而不丢失编辑会话、终端和调试状态；若仍崩溃，需用code --disable-extensions验证是否插件所致，并结合Extension Host日志定位肇事扩展。
崩溃时第一反应：别重启，先热重启扩展宿主
VSCode 界面还能点、文件能保存，但语法高亮消失、右下角语言标识变灰、Format Document 命令搜不到——这大概率是 exthost 进程挂了，不是编辑器本体崩溃。此时直接关掉重开，反而会丢失终端、调试会话和未保存的编辑状态。
快捷键 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Restart Extension Host 即可。它只杀掉并重建扩展宿主进程，不触碰任何用户设置或工作区配置。
- 若执行后立刻再次弹出
Extension host terminated unexpectedly，说明有插件在activate()阶段就出错（比如ms-python.python找不到 Python 解释器） - 某些插件（如
bradlc.vscode-tailwindcss）重启后需重新扫描 CSS 类，短暂卡顿属正常，不是失败信号 - 如果命令面板里连
Developer: Restart Extension Host都搜不到，说明共享进程（Shared Process）也已卡死，必须彻底退出所有 VS Code 窗口再重开
确认是否插件导致：用 --disable-extensions 启动
点击 ▶️ 按钮没反应、终端一闪而过、甚至 VSCode 根本打不开窗口——90% 是某个插件在启动早期让扩展宿主静默崩溃，UI 层的“禁用全部扩展”按钮根本来不及生效。
唯一干净的起点是终端执行：code --disable-extensions。它不读 settings.json、不扫描 .vscode/extensions.json、不触发任何插件的 activate() 函数，100% 跳过所有插件加载逻辑。
- 执行后能正常运行代码、打开终端、显示语言标识 → 100% 插件问题，不用再查系统或 Python 版本
- 执行后仍崩溃 → 问题可能出在 VSCode 本体、Electron 环境或系统级限制（如中文路径、
EACCES权限错误、GPU 加速冲突） - 注意：
--disable-extensions只对本次启动生效，不影响插件文件本身，也不修改任何配置
定位肇事插件：日志 + 二分法排查
日志比 UI 更可信，但得知道看哪条。崩溃早于日志写入？那就退回命令行阶段；日志里有线索？优先信它。
先执行 Developer: Open Extension Host Log，拉到末尾找以 Error 或 FATAL ERROR 开头的行。典型线索如：at ExtensionHostProcess._onExtProcessError ... ms-python.python —— 这个 ID 就是元凶。
- 若日志为空或只有
INFO，说明崩溃发生在进程启动前（比如 IPC 通信被防火墙拦截），必须用code --disable-extensions验证 - 若日志明确指向某个插件，但你不确定它是否真有问题，可用
code --disable-extension ms-python.python单独禁用测试 - 插件太多？用
code --list-extensions列出全部，优先试近期更新或高危类型：ms-python.python、esbenp.prettier-vscode、bradlc.vscode-tailwindcss - Linux 用户特别注意：
Codex类插件在桌面快捷方式启动时易因环境变量缺失失败，改用终端code .启动常能绕过
容易被忽略的底层陷阱
真正麻烦的不是插件多，而是某些插件（比如旧版 Python、SFTP、AI 补全类）会在启动时尝试 spawn 外部进程，而路径含空格、中文或权限不足会导致静默失败——这种错误不会报红字，也不会进日志，只表现为“一切正常但功能缺失”。
- Ubuntu/Arch 用户遇到
Codex卡加载或闪退，先查ulimit -n：默认 1024 不够它预加载 1410 个资源文件，临时提至 2048 再试 -
main.log里出现Failed to create window（macOS）、Segmentation fault（原生模块冲突）、EACCES（WSL/Docker Desktop 权限）等关键词，说明问题已脱离插件层 - 崩溃卡在
Starting extension host？补上--log debug：code --verbose --log debug，它会暴露具体哪个插件的activate()抛了异常
