注意: 你必须使用 5.5.1 或更高版本的 npm 才能使用访问令牌。

访问令牌是在使用 API 或 npm 命令行接口 (CLI) 进行身份验证时,替代使用用户名和密码的一种方式。访问令牌是一个十六进制字符串,可以用来进行身份验证,并赋予你安装和/或发布模块的权限。

🌐 An access token is an alternative to using your username and password for authenticating to npm when using the API or the npm command-line interface (CLI). An access token is a hexadecimal string that you can use to authenticate, and which gives you the right to install and/or publish your modules.

截至 2025 年 11 月,仅支持 Granular access tokens。已删除传统访问令牌。

🌐 As of November 2025, only Granular access tokens are supported. Legacy access tokens have been removed.

你可以创建访问令牌,以便让其他工具(例如持续集成测试环境)访问你的 npm 包。例如,GitHub Actions 提供了存储密钥的功能,比如访问令牌,你可以用它们来进行身份验证。当你的工作流运行时,它将能够以你的身份完成 npm 任务,包括安装你有权限访问的私有包。

🌐 You can create access tokens to give other tools (such as continuous integration testing environments) access to your npm packages. For example, GitHub Actions provides the ability to store secrets, such as access tokens, that you can then use to authenticate. When your workflow runs, it will be able to complete npm tasks as you, including installing private packages you can access.

你可以使用来自网页或命令行接口的令牌,无论哪种方式最方便。在每个环境中所做的操作都会反映到另一个环境中。

🌐 You can work with tokens from the web or the CLI, whichever is easiest. What you do in each environment will be reflected in the other environment.

npm 令牌命令让你:

🌐 npm token commands let you:

  • 查看令牌以便于跟踪和管理
  • 根据 IP 地址范围 (CIDR) 限制访问
  • 删除/撤销令牌

有关在网页和命令行接口上创建和查看访问令牌的更多信息,请参见“创建和查看访问令牌”。

🌐 For more information on creating and viewing access tokens on the web and CLI, see "Creating and viewing access tokens".

关于粒度访问令牌

🌐 About granular access tokens

细粒度访问令牌允许你根据使用令牌的目的来限制令牌提供的访问权限。使用细粒度访问令牌,你可以:

🌐 Granular access tokens allow you to restrict access provided to the token based on what you want to use the token for. With granular access tokens, you can:

  • 限制令牌可以访问的包和范围
  • 授予特定组织的令牌访问权限
  • 设置令牌到期日期
  • 基于 IP 地址范围限制令牌访问
  • 在 只读 和 读写 权限之间选择。对于包和范围,读写 权限可以是 发布和暂存 新版本,或者仅 暂存(见“关于仅暂存的令牌)。
  • 配置一个令牌以**绕过双因素认证(2FA)**要求

你可以在你的 npm 账户上创建最多 1000 个细粒度访问令牌。你可以设置令牌的有效期限,至少为未来一天。每个令牌可以访问最多 50 个组织,以及最多 50 个软件包、50 个作用域,或者 50 个软件包和作用域的组合。访问令牌与用户的权限相关联;因此,它在任何时候都不能拥有超过用户本身的权限。如果用户对某个软件包或组织的访问被撤销,他们的细粒度访问令牌对这些软件包或组织的访问权限也会被撤销。

🌐 You can create up to 1000 granular access tokens on your npm account. You can set how long your token is valid for, at least one day in the future. Each token can access up to 50 organizations, and up to either 50 packages, 50 scopes, or a combination of 50 packages and scopes. Access tokens are tied to users’ permission; hence it cannot have more permission than the user at any point in time. If a user has their access revoked from a package or an org., their granular access token will also have its access revoked from those packages or org.

当你授予令牌对一个组织的访问权限时,该令牌只能用于管理组织设置以及与组织相关的团队或用户。它并不赋予令牌发布组织管理的包的权限。

🌐 When you give a token access to an organization, the token can only be used for managing organization settings and teams or users associated with the organization. It does not give the token the right to publish packages managed by the organization.

绕过双因素认证(2FA)功能适用于具有写入权限的令牌,并且在创建令牌时默认为 false。当绕过 2FA 选项设置为 true 时,此设置会优先于账户级和包级的 2FA 设置,适用于发布等包和自动化操作。这意味着即使账户级 2FA 已启用和/或包级 2FA 是必需的,使用该令牌进行发布时仍会绕过 2FA。如果某个包或组织要求严格执行 2FA,请不要将绕过 2FA 设置为 true。

🌐 The Bypass 2FA capability applies to tokens with write access and is set to false by default at token creation. When the Bypass 2FA option is set to true, this setting takes precedence over account-level and package-level 2FA settings for package and automation actions such as publishing. This means that even if account-level 2FA is enabled and/or package-level 2FA is required, 2FA will still be bypassed when using the token to publish. Do not set Bypass 2FA to true if a package or organization requires fully enforced 2FA.

关于仅舞台令牌

🌐 About stage-only tokens

当一个分级访问令牌对包和作用域具有读写权限时,你可以选择它被允许发布的方式:

🌐 When a granular access token has Read and write access to packages and scopes, you can choose how it is allowed to publish:

  • 读取和写入(发布和部署):该令牌可以直接向注册表发布新软件包版本。
  • 只读和写入(仅阶段):该令牌 无法 直接发布新版本包。相反,它会为包维护者准备一个版本以供审核和发布。

仅限阶段的令牌是自动化(例如持续集成和部署 CI/CD)的更安全入门方式。因为阶段令牌不能直接发布新版本——每个阶段版本都必须由具有两因素认证(2FA)的维护者审核和提升——所以即使令牌泄露或被滥用,也无法在没有维护者批准的情况下将新版本上传到注册表。这缩小了直接发布的风险;否则并不会限制令牌的写入能力。

🌐 Stage-only tokens are a safer on-ramp for automation such as continuous integration and deployment (CI/CD). Because a stage-only token can't publish a new version directly — each staged version must be reviewed and promoted by a maintainer with two-factor authentication (2FA) — a leaked or misused token can't get a new version onto the registry without that maintainer approval. This narrows the risk of direct publishing; it does not otherwise restrict the token's write capabilities.

仅用于阶段的令牌 可以:

🌐 A stage-only token can:

  • 用 npm stage publish 提交一个新版本的软件包供审核
  • 弃用软件包版本
  • 移动 dist 标签

仅用于阶段的令牌 不能:

🌐 A stage-only token cannot:

  • 直接发布一个新版本的包。尝试发布新版本会失败并出现错误 E_STAGE_REQUIRED。

注意: Stage-only 仅限制 直接发布新版本。它不是通用的安全边界——stage-only 令牌仍保留上面列出的其他写入权限,所以使用时应像对待任何其他令牌一样小心。

使用仅限阶段的令牌发布

🌐 Publishing with a stage-only token

当你用仅限阶段的令牌发布新版本时,注册表不会立即发布它。相反:

🌐 When you publish a new version with a stage-only token, the registry does not publish it immediately. Instead:

  1. 暂存版本。 在你的自动化工具或命令行里,运行 npm stage publish 而不是 npm publish。这样会上传版本并创建一个还没上线的暂存。 如果你用仅限暂存的令牌运行 npm publish,发布会失败,出现 E_STAGE_REQUIRED 错误,提示你运行 npm stage publish 并让版本通过审批。
  2. 查看阶段。 维护者可以使用 npm stage list 列出待处理阶段,并使用 npm stage view <stage-id> 或 npm stage download <stage-id> 检查某个阶段。
  3. 发布版本。 启用了双重认证的维护者可以用 npm stage approve <stage-id> --otp <code> 将预发布版本发布到注册表,或者用 npm stage reject <stage-id> 丢弃它。

直接发布正在被淘汰

🌐 Direct publishing is being deprecated

拥有直接发布权限的绕过双重验证(2FA)令牌将被弃用。使用细粒度访问令牌直接发布新软件包版本的功能将在 2027 年 1 月 被移除。为做好准备,请将发布新版本的自动化切换为 读取和写入(仅限暂存) 令牌,并配合上面描述的暂存工作流程使用。另请参见“账户身份操作需要交互式 2FA 验证”,了解绕过 2FA 令牌的相关变化。

🌐 Bypass-2FA tokens with direct-publish access are being deprecated. The ability to publish new package versions directly with a granular access token will be removed in January 2027. To prepare, switch automation that publishes new versions to a Read and write (stage only) token together with the staging workflow described above. See also "Account-identity actions require an interactive 2FA challenge" for related changes to bypass-2FA tokens.

账户身份操作需要进行交互式双因素认证

🌐 Account-identity actions require an interactive 2FA challenge

从2026年8月开始,启用了绕过双重验证的令牌将无法再用于执行账户身份或账户管理操作。这些操作始终需要进行互动式双重验证挑战:

🌐 Starting August 2026, tokens with Bypass 2FA enabled can no longer be used to perform account-identity or account-governance actions. These actions always require an interactive 2FA challenge:

  • 更改邮箱或密码
  • 修改或关闭双重验证设置
  • 创建、升级或管理访问令牌
  • 添加或移除软件包维护者
  • 组织和团队治理行动

目前,绕过双因素认证的令牌仍然可以用于直接发布。对于 CI/CD 发布,建议考虑采用受信任的发布方式。

🌐 At the moment, bypass-2FA tokens can still be used for direct publishing. For CI/CD publishing, consider adopting trusted publishing instead.