code --status可快速定位VSCode启动失败根因：Electron崩溃、GPU初始化失败或沙箱被拒；Linux缺libglib-2.0.so.0/libX11.so.6；Windows缺VC++运行时；macOS签名失效。
VSCode 启动失败时先看 code --status
这个命令能快速暴露底层问题，比如 Electron 渲染进程崩溃、GPU 初始化失败或沙箱启动被拒。它不依赖 GUI，即使界面打不开也能运行。常见输出里重点关注 mainThreadExtensionService 报错（插件冲突）、gpuStatus 为 unavailable（显卡驱动或禁用标志异常），以及 nodeProcessId 是否缺失（Node.js 运行时根本没起来）。
检查 libglib-2.0.so.0 和 libX11.so.6 是否缺失（Linux 常见）
VSCode 二进制依赖系统级 C 库，尤其在最小化安装的 Linux 发行版（如 Alpine、某些 Docker 镜像、Arch 的 base 安装）上容易缺这些。运行 ldd /usr/share/code/code | grep "not found" 可直接列出缺失项。
-
libglib-2.0.so.0：通常由glib2或libglib2.0-0包提供（Ubuntu/Debian 用后者，CentOS/RHEL 用前者） -
libX11.so.6：属于 X11 客户端库，没装桌面环境时极易缺失，需装x11-libs或libx11-6 - Alpine 用户必须额外装
glib+xlib+dbus（VSCode 用 D-Bus 做 IPC）
Windows 上 ERROR_CODE: STATUS_DLL_NOT_FOUND 多半是 VC++ 运行时问题
VSCode 桌面版基于 Electron，而 Electron 的 native 模块（如 node_modules.asar.unpacked 下的 .dll）依赖 Microsoft Visual C++ 2015–2022 Redistributable。不是所有 Windows 系统都默认带全，尤其是 Server 版或精简镜像。
- 下载并安装
vc_redist.x64.exe（64 位系统）或vc_redist.x86.exe（32 位） - 别只装最新版——Electron 22+ 要求至少 v14.34.33810，旧版 VSCode（如 1.7x）可能仍依赖 v14.29
- 用
Dependency Walker或dumpbin /dependents code.exe查具体缺哪个 DLL，比盲目重装更准
macOS 上 Library not loaded: @rpath/Electron Framework.framework/Electron Framework
这是典型的签名/路径绑定错误，多出现在手动移动过 Visual Studio Code.app、或从非官方渠道下载了篡改包的情况。macOS Gatekeeper 会拦截未签名或签名失效的二进制。
- 确认来源：只从 code.visualstudio.com 下载，不要用第三方打包器（如 Homebrew Cask 有时缓存旧签名）
- 重置签名：终端执行
xattr -rd com.apple.quarantine "/Applications/Visual Studio Code.app" - 验证框架完整性：
codesign --verify --deep --strict "/Applications/Visual Studio Code.app"，报错即说明签名损坏
codesign --verify --deep --strict "/Applications/Visual Studio Code.app" # 输出为空表示通过；若报 "code object is not signed at all"，就得重装
VSCode 启动失败的根因往往不在它自己，而在它和系统运行时之间那层薄薄的胶水——库路径、符号版本、沙箱策略、签名信任链。修的时候别急着重装，先让 code --status 或 ldd 说句话。
