npm 正式上线分阶段发布功能，软件包上架前新增人工审核环节

Node.js 默认包管理器 npm 已正式推出分阶段发布功能：在已发布版本可供用户安装之前，增加了一个显式的维护者审批环节。

与以往的直接发布（发布后立即开放给使用者安装）不同，预构建的压缩包会被上传到一个暂存队列，该队列在 npmjs.com 网站和 CLI 中均可见。随后，人工维护者必须完成双因素身份验证才能正式放行发布。暂存阶段本身不需要双因素认证，兼容所有类型的令牌，因此非交互式的 CI 流水线不受影响，身份核验环节被后置到审批环节。该功能要求 npm CLI 版本不低于 11.15.0、Node 22.14.0 及以上，且软件包必须已存在于注册表中。

该工作流包含了一套子命令：

npm stage publish # submit the version to the stage queuenpm stage list # list staged versions awaiting approvalnpm stage view <stage-id> # inspect the staged tarballnpm stage approve <stage-id> # promote it to the registry, prompts for 2FAnpm stage reject <stage-id> # discard it

GitHub 建议将分阶段发布与基于 OIDC 的可信发布结合使用，可将相关配置限定为仅允许暂存发布，如此一来该工作流发起的直接 npm publish 将被拒绝。已在使用批量可信发布配置的团队可以复用该配置来迁移软件包，随后将持续集成环境升级至新版命令行工具，并替换发布指令即可。CLI 参考文档列举了 --tag、--provenance 等参数标志，它们的行为与 npm publish 发布命令完全一致。

本次版本更新除原有 --allow-git 参数外，新增了 --allow-file、--allow-remote 和 --allow-directory 三个参数。这些参数均可配置为 all 或 none，支持在 .npmrc 或 package.json 文件中进行设置。在 v12 版本里，--allow-git 的默认配置将改为 none。

这一系列改动的背后是接连爆发多起破坏性极强的软件供应链安全事件：先是 Shai-Hulud 蠕虫攻击事件，然后是官方弃用传统令牌。安全研究员 Adnan Khan 在 X 平台发文直白地表示：

所有向 NPM 发布软件包的开发者即日起都应当启用该功能。

通过 OIDC 在持续集成环境执行发包操作，在软件包正式对外开放前完成审核。

Shai-Hulud？拒绝。

Hacker News 用户 weinzierl 表示：

往好了看，分阶段发布就像是一个创可贴。但从长远来看，它有可能会损害我们为构建更安全基础设施所做的努力。

这番言论随即引来一则回复：

它怎么可能是有害的呢？

对于可信发布来说，这不是创可贴，而是一项重大改进，它杜绝了一类针对持续集成环境劫持发包的攻击。我相信攻击者可能还会找到其他方法，但这确实是堵住了一个巨大的缺口。

还有人对该功能的采用率提出质疑，用户 turkeyboi 表示，只有当“维护者真正使用它”时才有帮助；用户 Klaster_1 则提议是否应当默认强制开启该功能。Reddit 上的一位评论者认为，该方案只能降低恶意包的扩散速度，算不上根治供应链安全问题的良方。

各大竞品包管理器迅速跟进：pnpm 11.3 增加了具有相同子命令的 pnpm stage，Yarn 提供了 ，而 release-it 则支持 "stage": true 选项。除此之外，pnpm 还默认延迟安装刚发布不久的新版本，作为配套的防护手段。

GitHub 公布了后续计划：默认将可绕过 2FA 的细粒度访问令牌设为仅允许暂存；在 v12 版本中增加 allowScripts 字段，将安装脚本改为默认不执行。

查看英文原文：https://www.infoq.com/news/2026/08/npm-stage-available/