VSCode启动失败通常无需重装，应优先运行code --status定位扩展阻塞、GPU崩溃或环境缺失问题；若--disable-extensions能秒开，则100%为扩展链故障，需结合Developer: Show Running Extensions排查高耗时插件。
VSCode 启动失败，绝大多数情况不用重装，问题通常卡在扩展加载、GPU 渲染、环境变量缺失或用户数据损坏这几个环节。直接定位比反复重启更省时间。
code --status 能立刻告诉你卡在哪
终端运行 code --status 是最快判断启动卡点的方式。它不拉 GUI，只输出进程状态和扩展激活日志。
- 如果输出停在
Activating extension xxx且长时间无后续，基本是该扩展初始化阻塞（比如 ms-python.python 在无 Python 环境时仍尝试探测） - 出现
ERR! spawn ENOENT表示某个扩展依赖的二进制命令没找到（如 prettier 需要全局 prettier，但 PATH 里没有） - 末尾有大量
Failed to load module "appmenu-gtk3"（Linux）或libEGL initialization failed（Windows/macOS），说明 GPU 渲染层已崩溃，不是扩展问题
禁用扩展后能秒开，说明问题 100% 出在扩展链
code --disable-extensions 能绕过所有扩展初始化逻辑。如果它能立刻打开空窗口，就排除了 VSCode 本体、系统兼容性、权限等问题。
- 不要直接卸载扩展。先运行
Developer: Show Running Extensions（Ctrl+Shift+P），看 Activation Time > 1000ms 或状态为Activating的插件 - 重点关注默认激活的插件：ms-vscode.js-debug、ms-python.python、gitlens、Remote - SSH——它们常在无用户操作时就拉起服务、扫描仓库或连接远端
- 临时跳过全部扩展但保留语言支持？用
code --skip-extensions，它比--disable-extensions更轻量，仍会加载部分核心语言功能
Ubuntu GNOME 下 Codex 插件卡加载，本质是环境没继承
通过桌面收藏夹图标启动 VS Code 时，GNOME 不会把终端里的 HTTP_PROXY、ulimit 等环境带进去，而 Codex 的 app-server 启动依赖代理和文件描述符限制。
- 别改系统级
/usr/bin/code，风险高且易被更新覆盖 - 写一个包装脚本
code-with-codex-env，里面显式设置HTTP_PROXY、HTTPS_PROXY、NO_PROXY和ulimit -Sn - 关键在最后一行用
exec /usr/bin/code "$@"，让 VS Code 进程直接继承包装脚本的环境，而不是 fork 子进程丢失上下文 - GNOME 收藏夹指向这个脚本，而非原
code命令
端口占用导致调试/扩展服务无法启动，不能只 kill -9
报 EADDRINUSE :::3000 或 Unable to start debugging，八成是上一次 Node 进程、Live Server 或 Codex 的 app-server 没退出干净。
- 查端口：Linux/macOS 用
lsof -ni :3000，Windows 用Get-NetTCPConnection -LocalPort 3000，拿到 PID 才准 - 杀进程不能只
kill -9或taskkill /f /pid：Node 常派生 npm/yarn/子线程，硬杀主进程后子进程继续占端口 - 正确做法：Linux/macOS 先
kill 1234（发 SIGTERM），等 2 秒无响应再kill -9 1234；Windows 用taskkill /f /t /pid 1234（/t是关键，连带干掉子树） - Codex 或 Remote-SSH 的服务端口无法通过配置文件修改，必须杀进程，不能指望改
launch.json或设置项
真正难排查的不是“哪个环节出错”，而是“为什么这个环节在桌面启动时失效，却在终端里正常”——环境隔离、进程继承、权限边界这些底层细节，往往比插件开关更决定成败。
