2026 年 9 月 18 日，GitHub 官方博客与 npm 文档宣布推出 stage-only（仅暂存）粒度访问令牌，重塑 JavaScript 开源生态中自动化包发布的信任链。本文从开源生态视角解读。
令牌机制
据官方说明，创建粒度访问令牌时可选择“Read and write (stage only)”：自动化工作流用 npm stage publish 把新版本提交到暂存区，但该令牌无权直接向注册表发布；包维护者随后在 CLI 或 npmjs.com 上审查，并通过双因素认证（2FA）审批后版本才公开发布。使用该令牌直接执行 npm publish 会被拒绝，即使该令牌配置了 bypass-2FA 权限也是如此。令牌仍保留移动 dist-tag、废弃版本等其他写入权限，因此仍需按写令牌同等保护。
对开源生态的意义
npm 注册表是 JavaScript 开源生态的分发枢纽，而长期有效、具备直接发布权限的自动化令牌一旦在 CI 环境中泄露，攻击者可立刻向大量下游项目投送恶意包。暂存加人工审批相当于在机器产出与公开安装之间加了一道不可被令牌自身绕过的关卡：CI 负责提交、维护者负责拍板，责任边界清晰。对由志愿者维护的开源项目，这一机制让“自动化效率”与“维护者最终把关”可以同时存在。
迁移时间线与版本要求
该功能为可选启用，不改变现有令牌及其直接发布能力。按照此前公布的计划，npm 目标在 2027 年 1 月移除通过 bypass-2FA 令牌直接发布的能力；暂时无法迁移到 Trusted Publishers（可信发布者）的团队，可把 stage-only 令牌作为过渡路径。使用暂存发布需具备包的发布权限、账号启用 2FA、npm CLI 11.15.0 或更高版本，以及 Node.js 22.14.0 或更高版本。npm stage approve 与 reject 均要求 2FA，而 stage publish 本身不需要，以便无人值守流水线提交。
给维护者的建议
建议开源维护者尽快盘点仓库中的发布令牌：用 stage-only 替换可直接发布的旧令牌，把审批动作纳入发布检查清单；具备条件的项目可直接评估 Trusted Publishers，并配合最小权限、定期轮换与令牌用途隔离。对下游使用者而言，维护者侧多一道审批，就意味着依赖链上少一类“令牌泄露即投毒”的供应链风险。
小结
npm 于 2026 年 9 月 18 日推出 stage-only 粒度令牌，以暂存发布、维护者 2FA 审批与 2027 年 1 月取消 bypass-2FA 直译为时间表，是开源生态供应链安全治理的一次扎实改进。