插件离线安装后不生效最常见的原因是engines.vscode版本不匹配，需用unzip -p xxx.vsix extension/package.json | grep engines查看插件声明的最低vscode版本，并与code --version输出的主版本号（如1.85.2→1.85）严格比对，低于即不兼容；arm mac还需确认插件含darwin-arm64构建标识。
怎么确认插件版本和 VSCode 版本是否兼容
离线安装后插件不生效，最常见的原因是 engines.vscode 不匹配。VSCode 启动时会静默跳过所有声明最低版本高于当前 code --version 的插件，不会报错也不会提示。
- 先在有网机器上解压
.vsix：用unzip -p your-plugin.vsix extension/package.json | grep engines查看"vscode": "^1.85.0"这类声明 - 对比离线机上
code --version输出（如1.84.2），注意只比主版本号（1.84 → 不兼容） - 特别注意 ARM Mac 用户：
darwin-arm64构建版的插件无法在 Intel Mac 或 Windows 上运行，架构不匹配会导致扩展面板显示“已安装”但完全无响应
为什么 Volar / ESP-IDF / Remote-SSH 装完还是不能用
这类插件不是纯前端代码，它们依赖外部二进制服务（volar-server、idf.py、vscode-server），而 .vsix 文件默认只打包前端部分。
-
Volar：检查~/.vscode/extensions/volarjs.volar-*/server/（Linux/macOS）或%USERPROFILE%\.vscode\extensions\volarjs.volar-*\server\（Windows）下是否存在可执行文件；没有就说明语言服务没落地 -
ESP-IDF：离线安装插件后，必须手动配置idf.espIdfPath和idf.pythonBinPath指向本地已部署的 IDF 工具链，否则向导卡在“Detecting ESP-IDF” -
Remote-SSH：插件只是客户端，远程服务器上必须存在对应 commit_id 的vscode-server，且目录权限需为755，否则报bad owner or permissions
如何批量部署插件并确保 server 二进制完整
靠一个个拖 .vsix 文件进 VSCode，对含 native server 的插件来说只是半途而废。真正可靠的方式是整目录迁移。
- 在一台能联网、VSCode 版本和目标机一致的机器上，安装插件并触发预热：打开一个
.vue文件（Volar）、运行idf.py monitor（ESP-IDF）、或成功连接一次远程主机（Remote-SSH） - 等状态栏出现
Volar: Ready、终端输出Starting ESP-IDF Monitor或 SSH 连接成功后，直接拷贝整个volarjs.volar-1.12.0/或espressif.esp-idf-extension-1.5.0/目录到离线机的.vscode/extensions/下 - 不要手动重命名目录——ID 必须与
package.json中的publisher.name和name完全一致，否则 VSCode 无法识别已安装
离线环境里哪些操作必须提前做，不能补救
有些依赖一旦缺失，后续几乎无法在离线状态下修复，必须在外网阶段就一并处理。
-
Python插件依赖的pylint、black、debugpy等 Python 包，需要提前用pip download打包并传入内网，在插件设置中手动指定路径 -
C/C++插件的cpptools-srv二进制随插件更新，不同 VSCode 版本要求不同 commit_id；若离线机 VSCode 是 1.86.0，就必须用同版本跳板机导出 extensions 目录，换台机器下载的.vsix可能带错 server - 所有插件的
extension/package.json中声明的extensionDependencies（如 Volar 依赖vue.volar），必须在外网一次性下全，离线环境下无法自动拉取依赖
