选择命令行版本：
🌐 Synopsis
npm stage
注意：此命令不支持工作区。
🌐 Note: This command is unaware of workspaces.
🌐 Description
分阶段发布允许软件包维护者要求所有发布都提供在场证明。在场证明是指人在操作中参与、介入并提供认证（双重认证，2FA）——在本例中，是发布 npm 包时的认证。
🌐 Staged publishing allows package maintainers to require proof-of-presence for all publishes. Proof-of-presence is where a human is involved, interjects, and provides authentication (2FA) during an action — in this case, publishing an npm package.
通常，当维护者使用自动化工作流进行发布时，缺乏存在证明，因为没有方便的方式在过程中插入并提供双因素认证（2FA），而使用具有绕过权限的精细访问令牌和受信任的发布流程进行发布时则不存在这种问题。分阶段发布允许用户让他们的自动化工作流在没有 2FA 提示的情况下暂存一个包，将 2FA 的操作推迟，让维护者批准暂存的包并在稍后发布。
🌐 Typically when maintainers use automated workflows to publish, proof-of-presence is lacking as there's no convenient way to interject the process and provide 2FA, as is the case for publishing with a granular access token with bypass and the trusted publishing flow. Staged publishing allows users to have their automated workflows stage a package without a 2FA prompt, deferring the act of 2FA, allowing the maintainer to approve the staged package and publish at a later point.
npm stage publish 命令会打包当前工作目录，并将该版本的包放入注册表中，处于不可公开访问的状态，允许维护者在稍后批准该包。暂存操作不会要求两因素认证（2FA），可以使用任何类型的令牌进行，而批准操作则会要求。
🌐 The npm stage publish command packs the current working directory and places that version of the package into the registry in a state where it's not available for public access, allowing maintainers to approve the package at a later point in time. The act of staging does not prompt for 2FA and can be done with any token type, the act of approving will.
关键行为：
🌐 Key behaviors:
npm stage publish 与 npm publish 相当，并将在 package.json 中遵守 "private": true，拒绝安排该软件包。🌐 Prerequisites
在使用 npm stage 命令之前，请确保满足以下要求：
🌐 Before using npm stage commands, ensure the following requirements are met:
🌐 Subcommands
npm stage publish [<package-spec>] - 为发布准备软件包npm stage list [<package-spec>] - 列出所有已暂存的软件包版本npm stage view <stage-id> - 查看特定阶段包的详细信息npm stage approve <stage-id> - 批准一个分阶段发布的软件包npm stage reject <stage-id> - 拒绝已暂存的包npm stage download <stage-id> - 下载 tar 包以进行检查🌐 2FA Requirements by Subcommand
| 命令 | 是否需要双重验证 | 备注 |
|---|---|---|
npm stage publish | 否 | 设计用于自动化工作流程；将双重验证延迟到批准阶段 |
npm stage list | 否 | 查看已暂存的软件包 |
npm stage view | 否 | 查看已暂存软件包的详细信息 |
npm stage approve | 是 | 提示进行双重验证以发布已暂存的软件包 |
npm stage reject | 是 | 提示进行双重验证以永久移除已暂存的软件包 |
npm stage download | 否 | 下载 tarball 以便本地检查 |
🌐 Tag Behavior
--tag 标志遵循与 npm publish 相同的逻辑。如果未提供标签，则默认为 latest 标签。对于预发布版本（例如 1.0.0-beta.1）和非最新的 semver 版本，必须显式提供标签——否则 CLI 将报错，就像 npm publish 一样。
🌐 The --tag flag follows the same logic as npm publish. If no tag is provided, the latest tag is used by default. For pre-release versions (e.g., 1.0.0-beta.1) and non-latest semver versions, the tag must be explicitly provided — otherwise the CLI will error, just as npm publish would.
标签是已暂存包的不可变属性。一旦包使用给定标签进行暂存，该标签就无法更改。如果你需要使用不同的标签暂存相同版本的包，你必须首先使用 npm stage reject 拒绝现有的已暂存包，然后再使用所需的标签重新暂存它。
🌐 The tag is an immutable property of the staged package. Once a package is staged with a given tag, the tag cannot be changed. If you need to stage the same version with a different tag, you must first reject the existing staged package using npm stage reject and then re-stage it with the desired tag.
🌐 Token Behavior
分阶段发布的关键区别在于 npm stage publish 无论令牌类型如何，都从不需要双因素认证提示。这正是它适合自动化工作流程的原因。npm stage publish 的目标是将在场证明推迟到更晚的时间点。
🌐 The key difference with staged publishing is that npm stage publish never requires a 2FA prompt, regardless of token type. This is what makes it suitable for automated workflows. The goal of npm stage publish is deferring proof-of-presence to a later point in time.
| 令牌类型 | npm stage publish | npm publish |
|---|---|---|
| 带旁路的 GAT | 可暂存 | 可发布（如果包发布权限允许） |
| 不带旁路的 GAT | 可暂存 | 需要二次验证提示（如果包发布权限允许） |
| 会话令牌 | 可暂存 | 需要二次验证提示 |
| 信任令牌（OIDC） | 可暂存（如果允许） | 可发布（如果允许） |
🌐 Trust Relationship Permissions
通过分阶段发布，信任关系现在支持细粒度的命令权限。通过信任关系颁发的短期令牌只能用于 npm stage publish 和 npm publish。短期令牌不能运行 npm stage 子命令。
🌐 With staged publishing, trust relationships now support granular command permissions. Shortlived tokens issued through trust relationships can only be used with npm stage publish and npm publish. Shortlived tokens cannot run npm stage subcommands.
npm trust <provider> 支持 --allow-publish 和 --allow-stage-publish 来控制通过每个信任关系可用的命令。
🌐 Best Practices
注意: 添加分阶段发布并不会使你的账户或组织更加安全。维护者仍然必须使用以下列出的最佳实践。
npm stage publish。npm publish。 我们建议你仅在信任关系上启用 npm stage publish 并禁用 npm publish。🌐 Configuration
npm stage publish为发布准备软件包，将存在性验证（2FA）推迟到稍后的时间
🌐 Stage a package for publishing, deferring proof-of-presence (2FA) to a later point in time
🌐 Synopsis
npm stage publish <package-spec>
🌐 Flags
| 标志 | 默认 | 类型 | 描述 |
|---|---|---|---|
--tag | “latest” | 字符串 | 如果你让 npm 安装一个包而没有指定特定版本，它将安装指定的标签。这是添加到 package@version 的标签，如果在 npm dist-tag add 命令中没有提供明确的标签。当被 npm diff 命令使用时，这是默认用于获取将与本地文件进行比较的 tarball 的标签。如果在 npm publish 命令中使用，这是将添加到提交到注册表的包的标签。 |
--access | 对于新软件包为“public”，对于已有软件包不会更改当前级别 | null、"restricted"、"public" 或 "private" | 如果你不希望你的作用域包被公开查看（和安装），请设置 --access=restricted。未作用域的软件包不能设置为 restricted。注意：默认情况下不会更改已有软件包的当前访问级别。在发布期间指定 restricted 或 public 的值将以与 npm access set status 相同的方式更改已有软件包的访问权限。值 private 是 restricted 的别名。 |
--dry-run | false | 布尔值 | 表示你不希望 npm 做任何更改，它只应报告它本会做的事情。这个参数可以传递给任何修改本地安装的命令，例如 install、update、dedupe、uninstall，以及 pack 和 publish。注意：其他与网络相关的命令（例如 dist-tags、owner 等）不会遵守此设置。 |
--otp | null | null 或 String | 这是来自双因素认证器的一次性密码。在使用 npm access 发布或更改包权限时需要。如果未设置，并且注册表响应因一次性密码而失败，npm 将在命令行提示输入一次性密码。 |
--workspace， -w | 字符串（可多次设置） | 在当前项目配置的工作区上下文中启用命令运行，同时仅运行该配置选项定义的工作区进行过滤。workspace配置的有效值如下：_ 工作区名称 _ 工作区目录路径 * 路径到父工作区目录（将导致该文件夹内所有工作区）。当设置为npm init命令时，可以设置为尚未存在的工作区的文件夹，创建该文件夹并将其设置为项目内的新工作区。 | |
--workspaces | null | null 或 Boolean | 设置为 true 可在 所有 已配置的工作区上下文中运行该命令。显式将其设置为 false 会导致像 install 这样的命令完全忽略工作区。当未显式设置时： - 操作 node_modules 树的命令（安装、更新等）会将工作区链接到 node_modules 文件夹。 - 执行其他操作的命令（测试、执行、发布等）将作用于根项目，除非 在 workspace 配置中指定了一个或多个工作区。 |
--include-workspace-root | false | 布尔值 | 当命令启用了工作区时，包括工作区根目录。当为 false 时，通过 workspace 配置指定单个工作区，或通过 workspaces 标志指定所有工作区，将导致 npm 仅在指定的工作区上操作，而不在根项目上操作。 |
--provenance | false | 布尔值 | 当从受支持的云 CI/CD 系统发布时，软件包将公开链接到其构建和发布的来源。 |
npm stage list列出所有已暂存的软件包版本
🌐 List all staged package versions
🌐 Synopsis
npm stage list [<package-spec>]
🌐 Flags
| 标志 | 默认值 | 类型 | 描述 |
|---|---|---|---|
--json | false | 布尔值 | 是否输出 JSON 数据，而不是正常的输出。* 在 npm pkg set 中，它允许在保存到你的 package.json 之前用 JSON.parse() 解析设置的值。并非所有 npm 命令都支持。 |
--registry | "https://registry.npmjs.org/" | URL | npm 注册表的基础 URL。 |
npm stage view查看特定阶段包的详细信息
🌐 View details of a specific staged package
🌐 Synopsis
npm stage view <stage-id>
🌐 Flags
| 标志 | 默认值 | 类型 | 描述 |
|---|---|---|---|
--json | false | 布尔值 | 是否输出 JSON 数据，而不是正常的输出。* 在 npm pkg set 中，它允许在保存到你的 package.json 之前用 JSON.parse() 解析设置的值。并非所有 npm 命令都支持。 |
--registry | "https://registry.npmjs.org/" | URL | npm 注册表的基础 URL。 |
npm stage approve批准一个分阶段的包，并将其发布到 npm 注册表
🌐 Approve a staged package, publishing it to the npm registry
🌐 Synopsis
npm stage approve <stage-id>
🌐 Flags
| 标志 | 默认值 | 类型 | 描述 |
|---|---|---|---|
--otp | null | null 或 字符串 | 这是来自双因素认证器的一次性密码。在使用 npm access 发布或更改包权限时需要。如果未设置，并且注册表响应因一次性密码而失败，npm 将在命令行提示输入一次性密码。 |
--registry | "https://registry.npmjs.org/" | URL | npm 注册表的基础 URL。 |
npm stage reject拒绝一个预发布的软件包，将其从注册表中移除
🌐 Reject a staged package, removing it from the registry
🌐 Synopsis
npm stage reject <stage-id>
🌐 Flags
| 标志 | 默认值 | 类型 | 描述 |
|---|---|---|---|
--otp | null | null 或 字符串 | 这是来自双因素认证器的一次性密码。在使用 npm access 发布或更改包权限时需要。如果未设置，并且注册表响应因一次性密码而失败，npm 将在命令行提示输入一次性密码。 |
--registry | "https://registry.npmjs.org/" | URL | npm 注册表的基础 URL。 |
npm stage download下载已暂存包的 tar 包以进行检查
🌐 Download the tarball of a staged package for inspection
🌐 Synopsis
npm stage download <stage-id>
🌐 Flags
| 标志 | 默认值 | 类型 | 描述 |
|---|---|---|---|
--json | false | 布尔值 | 是否输出 JSON 数据，而不是正常的输出。* 在 npm pkg set 中，它允许在保存到你的 package.json 之前用 JSON.parse() 解析设置的值。并非所有 npm 命令都支持。 |
--registry | "https://registry.npmjs.org/" | URL | npm 注册表的基础 URL。 |
🌐 See Also