服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 2026年10月2日公告支持通过已认证会话或granular token暂存创建新包，包括stage-only token；首版本仍需维护者审批。
- 新包会出现0.0.0-stage占位版本。它公开可见，不等于暂存版本和内容已公开；后者等待审批。
- 暂存发布要求npm CLI 11.15.0及以上、Node 22.14.0及以上，并具备发布权限及启用账号2FA。
- 包创建后再配置trusted publisher，让CI提交暂存内容；OIDC不能代替维护者的交互审阅与2FA审批。
新包已出现，为什么首版本还不能安装？
GitHub在2026年10月2日宣布，npm stage publish可直接创建新包，无需先手工发布一个正式版本。适用范围包括公开的scoped和unscoped包，以及私有scoped包。
npm文档说明，新包暂存时会发布0.0.0-stage占位版本；审批前，目标版本不可安装，其内容不公开。批准后目标版本正式发布，按该包的访问权限使用。占位可见不能证明私有内容公开，审批也不应被理解为改变包的公开或私有设置。
开始前核对版本、发布权限和2FA
当前暂存功能要求npm CLI 11.15.0及以上、Node 22.14.0及以上，还需具备包的发布权限并开启账号2FA。Trusted publishing文档的npm 11.5.1最低要求不能替代暂存功能更高的版本门槛。
首次创建可用已认证的本地会话，或权限匹配的granular access token，其中包括stage-only token。9月18日公告说明，这类token不能直接npm publish，即使配置了自动化绕过2FA；10月2日公告进一步补上了新包创建能力。
这里无需先有一次正式版本发布，也不等于尚未配置的OIDC工作流能直接创建所有新包。公告明确的顺序是先完成包创建，随后才能管理包设置并配置trusted publishing；范围外的费用或地区承诺没有给出。
步骤一：把首版本提交到暂存区
在目标包项目根目录确认package.json的包名和拟发版本，并沿用团队原有测试、构建及审阅制度，再运行npm stage publish。命令把该内容提交到暂存区；命令成功不是正式版本可安装的验收。
保存实际包名、拟发版本和stage-id，供维护者定位这一批内容。npm文档明确，提交暂存本身不要求2FA验证；这不会取消账号启用2FA的前提，也不会免除后面的审批验证。
步骤二：审阅实际内容，再以2FA审批
维护者可用npm stage list查看有权访问的暂存条目，再用npm stage view加目标stage-id查看详情。需要检查实际tarball时，用npm stage download加该stage-id下载；不要只根据包名或CI成功标记判断内容正确。
也可在npmjs.com的Staged Packages页签找到目标内容。核对包名、版本和待审内容后，用npm stage approve加stage-id，或在网页点击Approve；两种审批方式都会要求2FA，批准后目标版本才发布到包页面。
例如，假设团队为新包提交1.0.0，先看到0.0.0-stage而1.0.0仍待审。这时应由维护者检查同一stage-id后决定是否批准，不必另用npm publish抢先公开。这是流程示例，不代表某个真实包的运行结果。
步骤三：包创建后，再接入CI暂存
新包创建后，按实际包设置配置trusted publisher，再让获授权的CI工作流运行npm stage publish。OIDC让工作流以短期身份凭据认证；它是后续提交暂存内容的方式，不能用来绕过首次设置或维护者审批。
当前trusted publishing支持GitHub-hosted runner、GitLab.com shared runner和CircleCI cloud，尚不支持self-hosted runner。这一限制属于OIDC发布认证，不应扩大为所有本地会话或token暂存都禁止自托管环境。
OIDC支持npm stage publish，但npm stage list、view、approve、reject仍要求交互认证和人员在场证明。把CI提交和维护者审阅分成两个明确环节，不能把获得OIDC身份误当作可以无人值守批准。
允许暂存，不等于允许直接发布或改标签
Granular stage-only token也不是只读凭据。9月18日原公告明确，它仍保留移动dist-tags和弃用版本等写入能力，应按写入凭据保护。不要把拒绝直接发布理解为所有写入都被封住；这与OIDC连接的Allowed actions是两类权限。
Trusted publisher的Allowed actions中，直接npm publish与管理dist-tags是独立权限。核对实际连接的允许操作，不要为了让暂存流程通过而一并打开不需要的直接发布或标签权限；其他连接也不会随之改变。
还要检查旧连接规则：2026年5月20日前创建的配置自动保留npm publish-only；9月3日前的配置需明确选择至少一项操作。9月3日后的新配置自动允许npm stage publish，不能概括为所有历史连接已自动支持暂存。
最后分别保留提交、审阅和审批结果。进入队列、占位包可见或OIDC认证成功，都不能替代目标版本已批准的记录；发布权限、账号2FA和组织原有审批要求仍应各自满足。
资料来源
常见问题
npm stage publish没有要求输入2FA，是不是账号设置出错？
提交暂存本身不要求2FA验证，这是当前文档说明的正常边界。不过前提仍包括账号启用2FA，维护者通过CLI或网页批准内容时都会被要求验证。不要把提交阶段没有提示当成整个流程免2FA。
已有包能否也改用暂存发布？
可以。npm文档同时支持新包和已有包的暂存流程；10月2日公告重点是新增包也可通过暂存创建。已有包仍需满足发布权限、版本和2FA要求，提交暂存不会自动批准该版本。
暂存首版本后，会自动生成provenance证明吗？
不能仅凭暂存成功或审批记录认定已有provenance。npm文档的自动生成条件是通过trusted publishing的OIDC从GitHub Actions或GitLab发布，并且同时使用公开仓库和公开包。CircleCI目前不支持这项自动生成，私有仓库也不适用；应核对实际证明记录，它不等于内容质量保证。