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 本体、系统兼容性、权限等问题。

VSCode

避免常见的 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 或设置项

真正难排查的不是“哪个环节出错”，而是“为什么这个环节在桌面启动时失效，却在终端里正常”——环境隔离、进程继承、权限边界这些底层细节，往往比插件开关更决定成败。