VSCode离线安装插件时，.vsix文件由主进程直接解压并注入扩展注册表，全程不联网；关键依赖目录名严格匹配publisher.name-version格式、package.json中engines.vscode版本兼容，且需满足activationEvents条件才能激活。
离线安装 VSCode 插件时，数据根本不经过 Marketplace 服务器——所有传输只发生在你本地文件系统与 VSCode 主进程之间。
vsix 文件如何被 VSCode 加载？
VSCode 不会“解析”或“联网校验”你提供的 .vsix 文件，而是直接解压并注入扩展注册表。整个过程完全离线，但依赖两个关键环节：
-
code --install-extension命令调用的是 VSCode 主进程（Code.exe/Code），不是渲染进程，因此不走网络栈 - 解压后，VSCode 将扩展目录（如
ms-python.python-2023.10.0）写入~/.vscode/extensions/，并读取其中的package.json来注册激活事件、贡献点和依赖声明 - 如果该扩展声明了
extensionDependencies，VSCode 会在启动时检查这些依赖是否已安装——但不会自动下载，仅报错或禁用主扩展
为什么有时安装后插件不生效？
常见原因不是数据流问题，而是元数据或路径状态不一致：
- 扩展目录名必须严格匹配
publisher.name-version格式，否则 VSCode 启动时不扫描（例如把ms-python.python-2023.10.0.vsix手动解压到python-ext/就无效） -
package.json中的engines.vscode字段若高于当前 VSCode 版本，安装会静默失败（无提示），可通过code --list-extensions --show-versions验证是否真被识别 - Windows 下若用普通 CMD 运行
code命令但未勾选“Add to PATH”，实际调用的是旧版 VSCode 或系统残留的code.cmd，导致扩展装到错误用户目录
离线环境下的依赖链怎么处理？
VSCode 本身不提供离线依赖解析能力，所谓“依赖”只是静态声明，没有运行时拉取机制：
- 如果你安装
esbenp.prettier-vscode，它在package.json中声明依赖esbenp.prettier，这只是提示你需要手动装后者，VSCode 不会尝试从任何地方下载 - 批量部署时，必须先用
code --list-extensions导出完整列表，再逐个下载对应.vsix，顺序无关紧要，但缺失任一依赖都可能导致功能异常 - 某些扩展（如
ms-python.python）会附带二进制工具（如pyright），这些是打包进.vsix的，无需额外下载——但若扩展更新后改用远程下载模式（如通过fetch()动态加载语言服务），离线时就会失败
真正容易被忽略的点：VSCode 的扩展激活是惰性的，很多插件只有打开特定文件类型或触发命令才加载。安装完没反应，不等于数据流出了问题，大概率是没满足 activationEvents 条件，比如还没打开一个 .py 文件就去查 Python 插件状态。
