从 VS Code 1.123 （6 月 3 日发布）开始，新发布的扩展版本在自动推送更新前会延迟两小时。思路很简单：如果不法分子窃取插件维护者的账号、上传恶意更新包，这两小时缓冲期可以让官方及时发现问题，并在该版本推送给数百万开发者之前将其下架。不过用户依旧可以随时手动点击更新。微软说得很直白：

当启用自动更新时，新版本将在发布后两小时自动更新，为存在问题或疑似遭篡改的发布版本增设了一道额外防护屏障。

但有一个例外：该延迟机制不适用于微软、GitHub 和 OpenAI 等“可信发布者”的扩展插件。这些扩展插进仍然会即时推送更新。考虑到大量用户安装的可信发布者的账号恰恰是不法分子入侵的高价值目标，这项特殊豁免条款显得颇为不合理。

此次改动紧跟各类软件包生态系统推出的同类安全管控措施。Pip 26.1 最近推出了可配置的依赖冷却期，团队可以屏蔽发布不足七天的包。研究发现，七天的冷却期可以阻止已发生的供应链攻击中十分之八的案例。RubyGems 也为 Bundler 添加了可选的冷却期。npm、pnpm、Yarn 和 Bun 在过去一年中都引入了最小发布时长限制设置。VS Code 现在也在 IDE 扩展层加入了这一机制，尽管两小时的窗口期比其他生态系统设置的要短得多。

Reddit 的一个讨论帖对这一时长并不买账。其中获得 650 多个点赞的热门评论定下了基调：

两小时冷静期远远不够，因为很多供应链入侵是在几天甚至几周后才被发现的。我觉得默认延迟时长应该设置得更长一些，同时再提供可供用户自定义时长的选项。

一名安全行业从业者对这种“即时更新”的固有主流观点提出了强烈反对：

我在网络安全领域听过的最大的一个神话就是“确保一有更新就立即下载”。我曾在极高安全等级的环境中工作过，我们从来不会第一时间跟进更新。除非是针对高危特定漏洞的补丁，其余更新一律会延后一周乃至一个月。

并非所有人都全盘否定两小时的冷静窗口。一位评论者指出，大多数恶意包是由自动扫描器发现的，而不是人工：

绝大多数恶意 npm 软件包都不是用户发现的，而是自动化安全扫描工具检测出来的，VS Code 插件的情况也是如此。新版本包一经发布，安全扫描工具会立刻检索可疑代码。但两小时的缓冲时长确实太短了。毕竟就算扫描工具标记出存在风险的安装包，仍需要人工核查，确认威胁真实存在。

多名评论者认为，设置更新缓冲期完全没有抓住问题核心。有人提议 VS Code 应当效仿移动端操作系统对应用的管理模式，为插件提供沙箱隔离机制并设置明确的权限。还有人建议采用分阶段灰度推送：先向 5% 的用户推送新版，再过几小时开放给 10% 的用户，随后数日里逐步扩大推送范围，直至所有用户。如此一来，若更新包遭到恶意篡改，受影响的只会是一小部分用户，扫描工具和社区也能在大范围分发前及时处置风险。

已有开发者在其他平台使用更长更新缓冲期的实际经验，印证了该方案的价值。一位网友表示自己将 npm 库的更新延迟设置为两周，并表示“这种设置避免的问题比造成的问题多”。还有人分享说，他们的公司对内部 npm 仓库强制执行六天延迟策略。一位 pnpm 用户称，minimumAgeRelease 配置在过去几个月内帮他们避免了两次供应链攻击。

目前仍未推出更新缓冲机制的生态是 WordPress。正如 InfoQ 最近报道的，一名攻击者在 Flippa 上购买了 30 多个插件，在第一次提交时就植入了后门，然后等待了八个月才激活。该平台没有发布延迟机制，没有控制权变更审查，也不强制要求代码签名。VS Code 的这一改变尽管力度有限，却让这套安全机制缺失的问题再也无法被无视。

对于管理 VS Code 部署的团队来说，两小时延迟机制默认启用，无需额外配置。那些想要更长窗口期的团队可以完全禁用自动更新，再通过基于策略的许可名单，或是自建内部精选插件市场来统一管控插件版本。

VS Code 1.123 现已可供下载，支持 Windows、macOS 和 Linux。

查看英文原文：https://www.infoq.com/news/2026/06/vscode-extension-update-delay/