vscode插件更新无真正后台机制，必须手动配置extensions.gallery.serviceurl和cacheurl为国内镜像源（如https://vscode.cdn.azure.cn/_apis/public/gallery）并重启才生效。
VSCode 没有真正意义上的“后台下载更新”机制，所谓后台只是定时轮询 + 静默下载，且不可控、无进度、不支持暂停。想提升插件更新效率，必须绕过默认行为，手动干预关键环节。
extensions.autoUpdate 开启后到底在做什么
设置 extensions.autoUpdate 为 true 后，VSCode 不会常驻进程监听更新。它只在两个时间点触发检查：
- 启动 VSCode 时（首次加载扩展系统）
- 空闲约 6 小时后（内部定时器，非精确，可能延迟更久）
每次检查都是单次 HTTP 请求，失败时无提示；下载过程占用网络和磁盘 I/O，但 UI 层隐藏了弹窗和进度条。Windows 用户尤其容易误判为“后台在跑”，实际是请求发完就等结果，没有重试逻辑、没有队列管理。
为什么改 extensions.gallery.serviceUrl 是最有效提速手段
插件下载慢的根因是直连 marketplace.visualstudio.com 和 vsextensions.blob.core.windows.net，国内用户常遇 DNS 解析慢、TLS 握手超时、CDN 节点返回高延迟 IP。镜像源不是“可选优化”，而是必须配置项。
- 推荐使用
https://vscode.cdn.azure.cn/_apis/public/gallery（社区维护，协议兼容性好，更新及时） - 必须同时设置
extensions.gallery.cacheUrl，否则部分插件页无法加载 - 修改位置：用户
settings.json（路径见知识库），改完需重启 VSCode 才生效 - 别用已失效的镜像如
vscode.bj.bcebos.com，实测 2026 年上半年起响应失败率超 70%
命令行安装仍失败？检查这三个隐性依赖
code --install-extension 在 CI/CD 或远程开发中容易失败，问题往往不在命令本身：
- 环境变量未继承：确保运行前设置了
VSCODE_EXTENSIONS_MSA_URL=https://vscode.cdn.azure.cn - 代理冲突：Clash / Surge 等工具开启时，VSCode 默认不走系统代理，需显式加参数
--proxy-settings=off或配http.proxy - 语言服务器二进制包不走 gallery 协议：如
ms-python.python更新后会额外请求https://github.com/microsoft/vscode-python/releases，这部分镜像无效，只能靠代理或离线下载
“Update All”按钮的隐藏限制与替代方案
界面右上角的 Update All 按钮只会更新当前 启用状态 的插件，禁用的插件无论是否有新版都跳过。它也不区分更新优先级，可能导致核心插件（如 ms-vscode.vscode-typescript-next）和主题插件同时更新，引发 API 不兼容。
- 安全顺序：先手动更新语言服务类插件（TypeScript、Python、Rust Analyzer），再更新 GitLens、Prettier 等工具类
- 批量操作：用命令面板运行
Extensions: Show Enabled Extensions和Extensions: Show Disabled Extensions分开处理 - 别依赖自动重启：更新后务必手动重启窗口（
Developer: Reload Window），否则旧版代码可能仍在 Extension Host 进程中运行
最易被忽略的是：插件更新后的实际生效依赖于 Extension Host 进程重启，而这个进程不会因插件更新自动销毁——你看到“已更新”字样，不代表新逻辑已在运行。
