npm staged publishing GA：CI 发包先入暂存队列

这篇解决什么

自动发布能提速，也会放大凭证泄漏和恶意版本风险。staged publishing 让 CI 先上传待发布包，再由维护者用 2FA 批准进入 registry。

适合谁

适合 npm 包维护者、前端基础设施团队、开源项目和企业 DevSecOps。

操作步骤

1. 升级发布环境到 npm CLI 11.15.0 或更新版本
2. 把 CI 中的 npm publish 改为 npm stage publish
3. 配合 trusted publishing 和 OIDC
4. 设置 stage-only 权限限制
5. 维护者从 npmjs.com 或 CLI 审批
6. 发布后核对版本、tarball 和变更说明

可复制模板

包名：
CI 工作流：
发布命令：npm stage publish
审批人：
2FA 方式：
发布窗口：
回滚动作：

验收清单

• CLI 版本满足要求
• CI 使用 stage publish
• 审批人明确
• 2FA 已开启
• 发布后核对 tarball

常见错误

• 只收藏产品更新，没有把它改成当天能执行的工作卡。
• 只看发布标题，没有确认账号权限、适用版本、成本和数据边界。
• 把 AI 自动化结果直接当结论，没有保留人工复核和失败恢复动作。
• 外部链接散落在聊天记录里，后续复查时找不到来源和日期。

30 分钟小样本

先选一个真实但低风险的任务。前 5 分钟写清输入材料和目标产物；中间 15 分钟按本文步骤执行一次；最后 10 分钟记录输出、人工修改量、失败点和下一次复用条件。小样本通过后，再扩展到团队模板或固定 SOP。

复用方式

第一次执行时，把它当成个人操作卡；第二次执行时，把成功步骤整理成团队模板；第三次执行时，再判断是否值得升级成固定 SOP、工具页或培训材料。每次复查都要看官方页面是否改版、权限或价格是否变化、原来的示例是否还能跑通。

资料依据

• GitHub Changelog / Staged publishing and new install-time controls for npm / 2026-05-22

标签