code --status卡在扩展加载即为插件问题：若输出停在“Activating extension”、出现ERR! spawn ENOENT或“Extension host terminated unexpectedly”，说明某扩展崩溃阻塞启动，需用code --disable-extensions验证并逐个禁用高危插件排查。
code --status 卡在扩展加载就是插件问题
运行 code --status（macOS/Linux）或在 Windows PowerShell 中执行相同命令），如果输出停在 “Activating extension”、长时间无响应，或末尾出现 ERR! spawn ENOENT、Extension host terminated unexpectedly，基本可锁定是某个扩展崩溃导致启动失败。
此时不要急着重装 VSCode——插件初始化失败不会影响核心进程，但会阻塞整个 UI 启动流程。常见高危插件包括 ms-python.python、esbenp.prettier-vscode、bradlc.vscode-tailwindcss，尤其是含原生模块或近期更新过的版本。
- 先用
code --disable-extensions验证：能启动 → 100% 是插件问题 - 再用
code --list-extensions查出全部已安装插件列表 - 用
code --disable-extension publisher.name分批禁用，例如code --disable-extension ms-python.python - 注意：某些插件（如旧版
vscode-icons）即使被“禁用”，也可能通过劫持argv.json干扰启动，需手动删掉其安装目录
用户数据目录损坏会导致反复闪退或设置丢失
VSCode 的配置、缓存、扩展安装路径全集中在用户数据目录：~/.vscode（Linux/macOS）或 %APPDATA%\Code（Windows）。一旦其中某个子目录（如 Cache、GPUCache、Crashpad）损坏，就会引发启动闪退、终端无法打开、设置不保存等看似随机的问题。
验证方式很简单：备份后重命名该目录（例如改为 Code-backup），再运行 code。VSCode 会自动生成全新干净目录。若新目录下一切正常，说明旧目录中某处已损坏。
- 可逐步迁移文本类配置：仅复制
settings.json、keybindings.json、tasks.json - 绝对不要复制二进制子目录：
Cache、GPUCache、Crashpad、Extensions（除非你确认里面没有坏插件） - Windows 用户注意：
%APPDATA%\Code和%USERPROFILE%\AppData\Roaming\Code是同一路径，别重复操作
--disable-gpu 和 --no-sandbox 是远程/容器环境的救命参数
在远程桌面、Docker 容器、老旧显卡驱动或企业策略限制环境下，VSCode 启动失败往往静默发生——没弹窗、没日志、直接黑屏或白屏。根本原因通常是 Chromium 渲染层的 GPU 加速或沙箱机制被阻断。
Linux 容器里常见报错 Failed to move to new namespace，本质就是缺少 cap_sys_admin 权限，此时 --no-sandbox 不是可选项，而是必要参数。
- 第一步试
code --disable-gpu：强制软件渲染，绕过显卡驱动问题 - 第二步试
code --disable-gpu --no-sandbox：彻底关闭沙箱（仅用于排查，勿长期使用） - macOS 上若遇到 Metal 渲染异常，还可加
--disable-metal - 这些参数可组合使用，例如
code --disable-extensions --disable-gpu --no-sandbox
log trace 日志暴露 Electron 初始化失败点
GUI 弹窗和错误提示太表层，真正关键的崩溃信息藏在主进程日志里。code --log trace 输出的是 Electron 底层初始化、窗口创建、IPC 连接建立等环节的原始日志，比任何 GUI 提示都可靠。
如果 code --log trace --status 在终端卡住，改用 code --log trace --verbose 并紧盯最后几行——时间戳最晚的那几条，往往就是崩溃前的最后一句调用或错误断言。
- 日志里看到
Failed to create window→ GPU 或显示服务异常 - 出现
IPC connection failed→ 主进程与 renderer 进程通信中断，大概率是扩展或数据目录问题 - 若日志在
app.onReady前就终止 → 属于 Electron 级别失败，需优先检查系统依赖（如 glibc 版本、libX11）
cap_sys_admin，导致 --no-sandbox 成为必须项，否则连日志都打不出来。排查时得一层层剥，别跳步。 
