VSCode插件离线安装后node_modules缺失，须在联网机完整触发插件初始化（如打开.py文件等待pyright下载完成），再整目录拷贝含node_modules的扩展文件夹至内网机对应路径，不可仅传.vsix或手动npm install。
vscode插件离线安装后node_modules缺失怎么办
VSCode插件（如ms-python.python、esbenp.prettier-vscode）在离线安装.vsix后功能失效，多数不是插件没装上，而是其内部依赖的node_modules目录根本没生成——因为这些模块通常由插件激活时动态npm install或下载二进制LSP服务器触发，而离线环境直接跳过这步，留下空壳。
真正有效的做法是：在联网机器上**完整触发一次插件初始化流程**，再打包整个扩展目录。例如：
- 用相同版本VSCode打开
.py文件，等状态栏不再显示Downloading pyright...，且代码补全可用 - 找到对应扩展路径：
~/.vscode/extensions/ms-python.python-*（Linux/macOS）或%USERPROFILE%\.vscode\extensions\ms-python.python-*（Windows） - 确认该目录下存在
node_modules子目录，且大小不为0（通常几十MB起） - 把整个目录压缩打包，而非只拷
.vsix
如何提取插件真实依赖的node_modules结构
不能靠npm install手动还原，因为很多插件依赖的是私有构建产物或平台特定二进制（如debugpy的.so/.dll），它们不发布在npm registry上。
必须走官方加载路径反向捕获：
- 在联网机上启用VSCode开发者工具（
Help → Toggle Developer Tools），切换到Console面板 - 安装目标插件后，打开对应类型文件（如
.js触发esbenp.prettier-vscode），观察控制台报错或网络请求（即使失败也会打印出试图加载的模块路径） - 重点盯住
Failed to load module类日志，它暴露了插件实际需要但未打包的node_modules子路径 - 检查插件
package.json里的activationEvents和main字段，确定首次加载时执行的入口JS，再顺藤摸瓜找require()链
离线还原时常见的PATH与权限陷阱
把扩展目录拷到内网机后仍不工作，大概率是路径或权限断裂：
-
code --install-extension命令只解压.vsix，不会重建node_modules；必须用cp -r（Linux/macOS）或robocopy（Windows）完整复制已初始化好的扩展目录到~/.vscode/extensions/，并确保目录名不含版本号冲突（如已有ms-python.python-2023.10.0，新包就不能叫ms-python.python-2024.1.0） - Linux下常见
EACCES错误：扩展目录属主是root，但VSCode以普通用户运行，需chown -R $USER:$USER ~/.vscode/extensions/ms-python.python-* - Windows下注意长路径限制：若扩展路径含中文或过深，可能触发
EPERM，建议解压到C:\vscode-ext\这类短路径再软链接过去
为什么有些插件离线后仍尝试连网
不是插件“故意”联网，而是它内置的 telemetry、language server 自更新、或文档提示功能默认开启。关键控制点在插件自身配置：
- 检查插件
package.json里是否有"enableTelemetry": true，若有，需手动编辑该文件设为false - 像
ms-python.python会默认启用python.analysis.autoSearchPaths，导致后台扫描site-packages并尝试上报统计——关掉它："python.analysis.autoSearchPaths": false - 某些插件（如
redhat.vscode-yaml）会在首次加载时检查schema store，需提前配置"yaml.schemas"指向本地文件，避免超时卡死
离线部署最易被忽略的，是插件对「首次运行行为」的强依赖——它不像普通npm包能静态打包，而是靠VSCode宿主环境动态拉起进程。没跑通第一次，就永远缺那几MB的关键二进制。
