VS Code插件安装卡在“Installing…”时，需同步查看三类日志定位卡点：Extension Management日志确认是否发起安装请求，exthost日志检查插件注册与激活是否成功，main.log捕获磁盘级错误（如ENOENT、EACCES）；三者缺一不可。
怎么看 vsix 安装卡在哪一步
VSCode 界面只显示“Installing…”或直接消失，从不告诉你失败点。真正线索全在日志里，而且必须看两处：Extension Management 和 exthost 日志，它们职责完全不同。
-
Extension Management记录“有没有开始装”：按Ctrl+Shift+P→ 输入并执行Developer: Open Extension Logs，打开最新日期下的该文件，搜install或你的.vsix文件名。如果完全没出现，说明 VSCode 根本没收到安装请求——UI 卡死、被杀软拦截，或拖拽时没松手 -
exthost日志才管“装完能不能活”：执行Developer: Open Logs Folder，进exthost子目录，打开最新日志，搜插件 ID（如ms-python.python）或activate。若搜不到，不是版本问题，是.vsix解压失败或package.json缺失/格式错误 - 别漏掉
main.log：它藏在同一个日志文件夹下，专门报磁盘级错误，比如ENOENT（目标目录不存在）、EACCES（权限拒绝），这类问题在 Extension Logs 里根本不会出现
为什么提示 “Extension is corrupt” 却不是文件真损坏
这个报错绝大多数时候和文件完整性无关，而是 VSCode 在加载阶段就拒绝解析元数据。常见触发条件比你想象得更隐蔽。
- 用 Windows 资源管理器双击打开
.vsix再保存，会破坏 ZIP 结构和签名——哪怕只是看一眼再关掉，也会导致后续静默失败 - macOS 下浏览器下载后自动解压出
._xxx.vsix隐藏文件，再打包上传，VSCode 读到非法条目直接拒载 - 手动删过
~/.vscode/extensions/xxx但没清 registry 缓存，VSCode 检查到状态不一致，就报 “corrupt” 当作兜底错误 - 验证方法很简单：
unzip -t your-extension.vsix（Linux/macOS）或Expand-Archive your-extension.vsix -WhatIf（PowerShell）。输出OK才算真完整；报broken或missing，重下
code --install-extension --force 为什么有时也不起作用
--force 能跳过签名和版本比对，但它不是万能钥匙。失效往往是因为环境卡点没清理干净，而不是命令写错了。
- VSCode 进程还在后台跑：Windows 查任务管理器里所有
Code.exe和Code Helper.exe，macOS/Linux 运行code --status，必须返回 “no running instance” 才算干净 - 权限锁死目标目录：
~/.vscode/extensions/被设为只读（尤其 WSL 或企业策略下），sudo code --install-extension xxx.vsix --force可临时绕过（仅限 Linux/macOS） -
engines.vscode版本硬不兼容：比如.vsix里package.json写着"^1.93.0"，而你本地是1.92.2，VSCode 连解压步骤都不会触发，--force压根没机会生效 - 路径含空格却没加引号（Windows）：
code --install-extension C:\my ext\python.vsix会被拆成两个参数，报ENOENT；必须写成code --install-extension "C:\my ext\python.vsix"
离线环境下 Python/C++/LLDB 插件装上却不工作
这些插件不是单个 .vsix 就能搞定的。主扩展只是“壳”，真正的语言服务、调试器后端需要额外二进制组件，且它们通常不打包进 VSIX。
- Python：必须同时安装
ms-python.python和ms-toolsai.jupyter（否则内核无法启动）；Pylance 是可选但推荐，它依赖前者 - C/C++：核心
ms-vscode.cpptools需要对应平台的cpptools-srv二进制（如cpptools-win32.vsix），且cppToolsPath设置必须指向解压后的实际路径 - CodeLLDB：GitHub Release 页面下载的
.vsix已含lldb，但架构必须严格匹配——x64版本装在arm64Mac 上，首次启用时就会报Cannot find lldb，且无明确提示 - 所有这类插件首次启用时仍会尝试联网拉取资源（如 Jupyter 内核列表、clangd 二进制），离线状态下需提前确认依赖是否已全部部署到位
最常被忽略的其实是日志系统分工：Extension Management 告诉你“动作发没发出”，exthost 告诉你“插件活没活过来”，main.log 告诉你“磁盘让不让你写”。三者不对照着看，等于蒙眼排障。
