vscode启动卡住不动90%以上是扩展激活阻塞主线程；先执行code --disable-extensions验证，若秒开则必为扩展问题，再运行developer: show running extensions排查activation time超1000ms或状态为activating的插件。
VSCode启动卡住不动，90%以上是扩展在激活阶段阻塞了主线程，不是配置错、也不是安装损坏——先用 code --disable-extensions 验证，能秒开就不用往下看了。
卡在“正在加载扩展”：扩展激活阻塞主线程
这是最常见场景，本质是某个扩展的 activate() 函数执行同步 I/O（比如 fs.readFileSync）、未设超时的网络请求，或依赖的子进程（如 Python、SSH）卡在 spawn 阶段。
- 终端运行
code --disable-extensions，能正常启动 → 100% 是扩展问题 - 启动后立刻按
Ctrl+Shift+P，输入并运行Developer: Show Running Extensions，重点关注Activation Time (ms)超过 1000 或状态为Activating的扩展 - 高频嫌疑扩展：
ms-python.python（旧版会强制初始化环境）、gitlens（默认全仓库扫描）、ms-vscode.js-debug（无 JS 文件也拉调试服务）、Remote - SSH（连接失败时静默挂起） - 别急着卸载，先改配置：比如关掉
gitlens.advanced.caching.enabled，或给python.defaultInterpreterPath指定明确路径，避免自动探测
卡在“正在初始化窗口”或黑屏：GPU 渲染或沙盒冲突
尤其在 Intel 核显 + NVIDIA 独显切换的笔记本、远程桌面（RDP）、或 WSL2 环境下高发。VSCode 渲染器基于 Electron，某些驱动对 WebGL 初始化异常敏感，会导致整个渲染线程卡死。
- 临时验证：终端运行
code --disable-gpu，能进界面就说明是 GPU 加速问题 - Windows 用户可追加
--disable-gpu-compositing；Linux 用户可试--disable-features=UseOzonePlatform - 永久生效需编辑
argv.json（路径：%APPDATA%\Code\User\argv.json或~/Library/Application Support/Code/User/argv.json），加入"disable-gpu": true - 注意：
--disable-gpu不影响扩展功能，只是换条路跑；而--disable-extensions是绕过问题，不是解决
启动后空白欢迎页 / 无限加载：URI 解析失败或用户数据损坏
典型现象是控制台（Developer: Toggle Developer Tools → Console）刷出大量 Failed to fetch，但不是网络问题——是 VSCode 内部构造 vscode-file:// 或 vscode-webview:// 资源路径时出错，常因用户目录含中文、空格或 OneDrive 同步路径引起。
- Windows 下路径如
C:\Users\张三\会直接导致 URI 构造失败，表现为欢迎页空白或侧栏不显示 - 临时解决：启动时指定干净路径，如
code --user-data-dir="C:\vscode-data"（确保全英文、无空格、不在同步盘） - 更彻底：重命名整个用户数据目录（
%APPDATA%\Code或~/.config/Code），VSCode 会重建干净目录；扩展本体仍在~/.vscode/extensions，重启后手动启用即可 - Linux 用户若报
libXss.so.1: cannot open shared object file，说明缺系统依赖，运行sudo apt install libxss1（Ubuntu/Debian）或sudo yum install libXScrnSaver（CentOS/RHEL）
CentOS 7 / RHEL 7 上完全打不开：glibc 版本硬性不兼容
VSCode 1.86+ 明确要求 GLIBC_2.28+，而 CentOS 7 自带 glibc 2.17，这是底层 ABI 级不兼容，任何配置都无效——不是 bug，是官方已放弃支持。
- 终端启动时看到
/lib64/libc.so.6: version 'GLIBC_2.28' not found就是这个原因 - 不要尝试升级系统 glibc：会直接崩系统，得不偿失
- 可行方案只有三个：
降级 VSCode 到 1.85 及以前版本（仍支持 glibc 2.17）、用容器运行（如 docker run -it --rm -v $(pwd):/workspace -p 3000:3000 codercom/code-server）、或换发行版（如 Ubuntu 22.04+） - 注意：压缩包解压版和 .rpm/.deb 包在该场景下表现一致，区别只在于安装方式
真正难排查的从来不是“哪个扩展卡住了”，而是“为什么它卡得没报错”——比如 Remote - SSH 连不上远端时 UI 线程直接挂起，控制台却一片安静；又比如 Codex 插件在多用户服务器上因 /tmp/codex-ipc 权限冲突失败，日志里只有一行 EACCES 而已。这些地方没日志、不弹窗、也不崩溃，纯靠经验盯住 Activation Time 和 code --status 输出才能揪出来。
