code --disable-extensions 是定位 VSCode 扩展问题的第一步：若禁用后秒开且功能正常，即可100%锁定问题在扩展层；需配合 Developer: Show Running Extensions、code --status 及检查 settings.json/argv.json 进一步排查。
扩展管理不是启动问题的“开关”，而是定位和隔离问题的杠杆——禁用不等于修复，启用不等于安全。
code --disable-extensions 能否立刻验证扩展问题
能，而且是第一步必须做的动作。只要执行 code --disable-extensions 后 VSCode 秒开、界面响应正常、Ctrl+Shift+P 可用，就 100% 锁定问题在扩展层。
注意几个实操细节：
- Windows 用户若提示“不是内部或外部命令”，说明
code未加入 PATH，改用完整路径，例如："C:\Users\XXX\AppData\Local\Programs\Microsoft VS Code\Code.exe" --disable-extensions - macOS/Linux 下需先杀净残留进程：
killall -9 Code Helper或ps aux | grep code | grep -v grep | awk '{print $2}' | xargs kill -9 - 禁用后别急着重装扩展——它只是绕过问题，不是根治；很多崩溃源于配置漂移或启动参数冲突，而非扩展本身损坏
Developer: Show Running Extensions 查什么
这个命令（Ctrl+Shift+P → 输入运行）展示的是真实激活状态，比 UI 上的“已启用”更可信。重点关注两列：
-
Activation Time (ms)：超过 1000 毫秒的插件大概率在抢资源，比如ms-python.python在无 Python 文件时也硬启解释器，gitlens默认全仓库扫描 -
Status：长期卡在Activating或显示Activation failed，说明它根本没完成初始化，Extension Host 就被拖住甚至退出
配合 code --status 命令输出，能确认是否真有 ERR! spawn ENOENT（找不到可执行文件）或 ERR! timeout（启动超时）这类底层错误。
禁用扩展后仍崩溃？检查 settings.json 和 argv.json
扩展禁用了，但用户配置里还存着它的残余逻辑，照样会崩。常见坑点：
-
settings.json中存在语法错误（多逗号、少引号），VSCode 不报错，只静默卡死。临时重命名该文件再启动，能快速验证 -
argv.json（路径：%APPDATA%\Code\User\argv.json或~/Library/Application Support/Code/User/argv.json）里如果写了"enable-proposed-api": true或"disable-gpu": false这类非常规项，某些扩展会据此做非法调用，导致宿主进程异常退出 - Settings Sync 开启状态下，
settings.json里混入了平台相关路径（如 Windows 的C:\Users\...被同步到 macOS），某个扩展读到不存在的路径，直接抛错退出
为什么禁用一半扩展反而更难定位
因为扩展之间存在隐式依赖链。比如你禁用了 ms-python.python，但 ms-toolsai.jupyter 依赖它提供内核服务，结果 Jupyter 扩展卡在 Activating 状态，反过来拖垮整个 Extension Host。
更稳妥的做法是：
- 先全局禁用所有扩展，再逐个启用——每次启用后完全退出 VSCode 再重进，避免缓存干扰
- 优先启用“低风险”扩展（如主题、图标包），再试语言支持类（Python、TypeScript）、最后是网络/远程类（Remote-SSH、Codex）
- 遇到崩溃，立刻看“输出”面板 → 切换到对应扩展的通道（如
Codex或Python），里面常有比弹窗更早出现的Failed to load resources或Key not found in config日志
真正难处理的从来不是哪个扩展坏了，而是多个扩展共享同一份配置却各自解析失败——比如 TaoToken 统一 Key 之前，三个 AI 扩展各填一套 API Key，同步后一个读到另一个的 Base URL，触发无限重试把宿主进程内存吃满。
