VSCode启动失败应优先运行code --verbose查看详细日志，定位卡点在Electron初始化、主进程加载或窗口创建阶段；Windows用PowerShell/CMD，macOS需≥12.0，Linux检查XDG_RUNTIME_DIR权限与dbus；确认系统满足ARM64（M1/M2需1.75+）、Windows 10≥1903等细化要求；通过~/.vscode/logs/main.log等日志分析错误；--disable-gpu可快速验证显卡问题；无窗口时需查桌面环境系统日志。
VSCode 启动失败时先看 code --verbose 输出
很多“打不开”其实是进程卡在启动阶段，没弹窗也没报错。直接终端运行 code --verbose 能强制启用详细日志，比等图标转圈靠谱得多。它会输出 Electron 初始化、主进程加载、窗口创建等关键步骤，失败点通常紧挨着最后一行成功日志。
- Windows 用户建议用 PowerShell 或 CMD 运行，避免 Git Bash 等兼容层干扰 GUI 启动
- macOS 上如果提示
Failed to create CoreImage context，大概率是显卡驱动或 macOS 版本过旧（低于 12.0） - Linux 下若卡在
Checking for running code instance...，可能是$XDG_RUNTIME_DIR权限异常或 dbus 未就绪
确认系统是否满足最低运行条件
VSCode 官方文档写的“64 位系统”只是底线，实际卡顿或闪退常源于更细的约束。比如 M1/M2 Mac 需要 VSCode 1.75+ 才真正支持原生 ARM64，旧版强行运行会触发 Rosetta 二次转译，极易崩溃；Windows 10 用户若版本低于 1903 (OS Build 18362)，可能缺 Windows.UI.Xaml 组件，导致渲染线程初始化失败。
- 检查命令：
systeminfo（Win）、sw_vers（macOS）、uname -m && cat /etc/os-release（Linux） - VSCode 1.85+ 已弃用 32 位 Linux 发行版支持，
file $(which code)显示ELF 32-bit就得换包 - 内存低于 2GB 的设备（尤其 WSL1）即使能启动，也会在打开文件夹后几秒内被 OOM killer 杀掉主进程
从 ~/.vscode/logs 里找真实错误线索
GUI 启动失败时，VSCode 仍会尝试写日志到用户目录，路径固定为 ~/.vscode/logs/<timestamp>（Windows 是 %USERPROFILE%\.vscode\logs\<timestamp>）。别只盯着最新文件夹——有时崩溃发生在主进程加载扩展前，真正线索藏在 main.log 或 sharedprocess.log 里。
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
-
main.log记录 Electron 主进程生命周期，出现Error: Cannot find module说明核心依赖损坏 -
renderer.log若大量重复WebGL: CONTEXT_LOST_WEBGL，基本可判定显卡驱动不兼容 - 删除整个
logs文件夹再启动一次，能排除日志轮转异常干扰判断
禁用 GPU 加速快速验证是否显卡相关
很多看似“打不开”的现象本质是渲染线程卡死，而非主进程崩溃。加参数 --disable-gpu 可绕过所有 GPU 初始化逻辑，强制走 CPU 渲染。如果此时能正常启动，问题就锁定在显卡驱动、OpenGL/Vulkan 运行时或显示器配置上。
- 完整命令：
code --disable-gpu --verbose（配合日志更准） - Windows 上若同时使用 Intel 核显 + NVIDIA 独显，NVIDIA 控制面板中把
code.exe设为“高性能处理器”能解决部分黑屏 - Linux 用户注意：Wayland 会忽略
--disable-gpu，需改用code --disable-gpu --x11强制切 X11
真正难排查的不是“完全打不开”，而是那种点开图标后进程存在但无窗口、任务栏也不显示的情况——这往往意味着窗口管理器拒绝了 Electron 创建的 native window，日志里却只有一句轻描淡写的 Window failed to load。这时候得去翻桌面环境的系统日志，比如 journalctl -u gdm（GNOME）或 cat ~/.xsession-errors（X11），而不是继续重装 VSCode。
