code --disable-extensions是唯一可信起点，它跳过全部插件加载流程、不读配置、不调用activate()，若禁用后正常则100%为插件导致；否则需查gpu、数据目录或vscode本体。
直接用 code --disable-extensions 启动，能立刻确认是不是插件导致的启动异常——如果禁用后能正常打开、不卡、不白屏、不闪退，那问题 100% 出在某个已安装插件上；否则就得查 GPU、用户数据目录或 VSCode 本体。
为什么 code --disable-extensions 是唯一可信起点
图形界面点“禁用全部扩展”只是往 settings.json 写个数组，很多插件（比如 ms-python.python）在配置读取前就已注入代码，禁用根本没生效。而 --disable-extensions 跳过整个插件加载流程：不读 settings.json、不扫描 .vscode/extensions.json、不调用任何插件的 activate() 函数。它才是真正的“干净启动”。
常见误操作：
- 拼错成
code --disable-extension（少 s），命令无效 - 把参数放在
code前面，如--disable-extensions code，被忽略 - 和
--extensions-dir同时使用，后者会被强制忽略
确认是插件问题后，怎么快速定位肇事者
别手动一个个开关——尤其当你装了 50+ 插件时，效率极低，还容易漏掉组合冲突（A 和 B 单独没事，一起开就崩）。优先用内置二分法工具：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS） - 输入并运行
Developer: Start Extension Bisect - 每次重启后只回答“是”（问题复现）或“否”（正常），3–4 轮就能锁定具体插件 ID
若连命令面板都打不开，就用命令行逐个禁用：
- 先列所有插件：
code --list-extensions - 优先试高危项：
code --disable-extension ms-python.python、code --disable-extension esbenp.prettier-vscode、code --disable-extension bradlc.vscode-tailwindcss - 一次禁多个也行：
code --disable-extension dbaeumer.vscode-eslint --disable-extension rust-lang.rust-analyzer
崩溃日志里藏着最直接的线索
弹窗只说 Extension host terminated unexpectedly，但真正关键信息在日志末尾。运行 Developer: Open Extension Host Log，重点看最后一段 ERROR 行：
- 典型线索：
at activate (/Users/xxx/.vscode/extensions/esbenp.prettier-vscode-9.10.3/dist/extension.js:1)→ 直接指向esbenp.prettier-vscode - 若日志为空，说明崩溃发生在日志初始化之前，必须退回命令行阶段用
--disable-extension排查 - 配合
Developer: Show Running Extensions看Activation Time> 1000ms 或Status为Activation failed的插件
真正难搞的不是报错的插件，而是那种不报错、不崩溃、却卡在激活阶段死等外部进程（比如代理超时、sftp 连接 hang 住、AI 插件拉不到模型）的插件——它会让整个 extensionHost 阻塞，后续所有插件排队等它，你只觉得“VSCode 启动慢”，却看不到错误提示。
