vscode默认不共享扩展缓存，每人每机独立下载同一插件，导致重复拉取、cdn压力大；需通过extensions.gallery.cacheurl配置局域网缓存服务，并配合nginx或专用工具实现.vsix文件复用，同时确保serviceurl与cacheurl同域、同协议、路径规范，且配置于用户级settings.json并彻底重启进程。
为什么团队里每个人都重下同一个插件
VSCode 默认不共享扩展缓存，每个用户、每台机器都独立向镜像源或 marketplace 发起完整下载请求。哪怕 100 个人装 esbenp.prettier-vscode，就会触发 100 次相同 .vsix 文件拉取——不是带宽被占满，是上游 CDN 被打穿，尤其在批量重装或 CI/CD 构建时更明显。
用 extensionsGallery.cacheUrl 做本地代理缓存
VSCode 支持把插件包缓存层下沉到局域网内，关键靠 extensions.gallery.cacheUrl 配置指向一个可读写的 HTTP 服务地址，而非只配 serviceUrl。它不改变市场 UI 行为，但所有 .vsix 下载会先查这个 cacheUrl 是否已存在对应版本，命中则直接 304 或 200 返回本地文件。
- 必须配合反向代理（如 Nginx）或轻量服务（如
vscode-extension-cacheNode.js 工具）暴露一个支持 Range 请求的静态文件服务 -
cacheUrl必须和serviceUrl同协议、同域名（否则跨域失败），例如都设为https://vscode.internal.example.com/ - 首次未命中时，VSCode 会从
serviceUrl下载并自动 PUT 到cacheUrl对应路径（需服务端允许 PUT 或预置写入逻辑） - 路径规则固定：
/{publisher}/{name}/{version}/{name}-{version}.vsix，不能自定义
CI/CD 流水线中避免重复拉取
在 Jenkins/GitLab CI 等环境里，code --install-extension 默认每次都是全新下载。不加干预，构建节点越多，对镜像源冲击越大。
- 提前把常用插件
.vsix文件放入制品库（如 Nexus、JFrog），并在 CI 脚本中用code --install-extension /path/to/pre-downloaded.vsix安装 - 禁止自动更新：
"extensions.autoUpdate": false，防止后台静默触发额外下载 - 构建镜像时固化扩展：在 Dockerfile 中运行
code --install-extension并 commit，后续容器启动即自带插件，零网络依赖 - 注意
engines.vscode兼容性：CI 中 VSCode 版本若低于插件要求的最低版本，安装会静默失败，需统一管理 VSCode 和插件版本矩阵
Windows 组策略或 macOS MDM 下的全局配置失效点
企业用组策略或 MDM 推送 settings.json 时，常发现部分机器仍走默认源——不是推送失败，而是 VSCode 进程未完全重启或配置被更高优先级覆盖。
-
extensions.gallery.serviceUrl和cacheUrl必须写在 **用户级 settings.json**（%APPDATA%\Code\User\settings.json等），工作区级或远程设置不生效 - 组策略推送后，必须杀掉所有
Code.exe和Code Helper.exe进程，仅关闭窗口无效 - 某些 MDM 工具会注入自己的
http.proxy设置，与serviceUrl冲突，导致请求发往代理却没走镜像路径，建议禁用代理或显式设"http.proxy": "" - macOS 上若用 LaunchAgent 启动 VSCode，需确保其继承了环境变量和配置文件权限，否则读不到推送的 settings.json
product.json 被覆盖，而运维忘了重推 cacheUrl；或者安全策略定期清理临时目录，把 Nginx 缓存区清空了却不通知开发侧。这些细节不记录、不监控，压测时流量就又打回原形。
