vscode离线安装插件后无法启动，90%非插件本身问题，而是进程残留、用户数据损坏或扩展冲突导致初始化阶段崩溃；需优先结束所有code进程、执行code --disable-extensions --no-sandbox验证，并通过--log trace查看main.js初始化前的报错。
VSCode离线安装插件失败后无法启动，90% 不是插件问题，而是 VSCode 自身进程残留、用户数据损坏或扩展冲突导致的启动卡死——它根本没走到「加载插件」那一步，就已经在初始化阶段崩溃或退出了。
VSCode双击无反应或闪退，先查进程和日志
症状：图标点击后无窗口、任务管理器里 Code.exe（Windows）或 Code Helper（macOS/Linux）短暂出现又消失。
- 关掉所有 VSCode 进程：包括系统托盘里的
Code Helper、后台Code进程，不能只关窗口 - 临时禁用全部扩展：终端执行
code --disable-extensions --no-sandbox，能启动说明是某个扩展破坏了启动流程 - 查看启动日志：Windows 下运行
code --log trace，macOS/Linux 用/Applications/Visual Studio Code.app/Contents/MacOS/Electron --log trace，关键线索藏在main.js初始化段和extensionHost启动前的报错里 - 别忽略
~/.vscode/extensions/目录权限：如果离线安装时用了sudo code --install-extension，该目录可能属 root，普通用户启动时会因无法读取扩展而静默失败
装完插件后启动就崩，大概率是扩展冲突或配置损坏
典型场景：在内网机器上离线装了 ms-python.python 或 redhat.java 后，VSCode 再也打不开。
- 立即备份并清空用户数据目录：
%APPDATA%\Code（Windows）、~/Library/Application Support/Code（macOS）、~/.config/Code（Linux） - 特别注意
settings.json里是否手动加了"locale": "zh-cn"这类非法值——中文包不兼容会导致 nls 模块加载失败，进而拖垮整个 UI 初始化 - 检查
extensions.json是否被写入了损坏的扩展条目：比如路径指向不存在的.vsix解压目录，或包含非法 JSON 字符（常见于手动编辑后未校验） - 某些带 native binary 的插件（如
ms-vscode.cpptools）若架构不匹配（ARM Mac 装了 x64 包），VSCode 在加载 extension host 时直接 abort，不会报错，只闪退
离线环境里“装上了却启动不了”，本质是扩展没真正落地
很多开发者以为拖进 .vsix 就算完成，其实 VSCode 离线安装分两层：第一层是解压注册，第二层是首次激活时拉依赖——后者失败不会阻止启动，但前者失败会让 VSCode 在初始化 extension host 阶段 panic。
- 确认
.vsix是原始未解压文件：用unzip -l plugin.vsix检查顶层是否为extension/目录；若显示一堆零散文件，说明已被资源管理器自动解压，VSCode 拒绝识别 - 含 LSP 的插件（如
redhat.java）必须配套语言服务器二进制：离线环境下，~/.vscode/extensions/redhat.java-*/server/必须存在可执行文件，否则 extension host 加载到一半就 crash - 不要跳过
--allow-unverified：离线时签名验证失败不报错，但会阻塞 extension host 初始化，加这个参数才能让 VSCode 继续往下走 - 企业环境需警惕组策略：若右下角状态栏显示
Extensions disabled by policy，任何安装行为都会被拦截，连进程都起不来
最常被忽略的一点：VSCode 启动失败时，它不会告诉你哪个扩展坏了，也不会生成明确错误对话框。它只是放弃加载，然后安静退出——所以排查必须从进程生命周期和日志时间戳入手，而不是盯着扩展列表找“少装了谁”。
