npm 发包配置还在却失效？48小时验证窗口与重建步骤

48小时不是所有 npm token 的统一期限

GitHub 2026年10月2日公告明确：尚未验证的 npm trusted publishing 配置，在创建48小时后失效。通过该配置首次成功发布后，它会获得验证并豁免过期；其他有效配置不受影响。

Trusted publishing 用发布工作流的短期身份凭据授权发包，避免为这一步保留长期写入 token。这里过期的是尚未验证的信任配置，不是所有 npm 账号、软件包或 token。官方说明，这项调整用于降低仓库或项目名称换主后的旧信任风险。

例如，假设周一上午创建连接，周四才准备第一次发布，而此前没有成功发布记录，就应先核对是否过期。这个例子说明创建时间的意义；普通编辑和重新保存不会重启截止时间。

先确认过期，别把 runner 排队当认证失败

先记录目标包、仓库、连接创建时间，以及是否曾通过它成功发布。检查原 workflow run：发布步骤已经执行并报认证错误，与 job 尚未获得 runner，是两条排查路径。仅凭排队时间，不应删除连接。

过期配置仍出现在 trusted publisher 设置中，但不再授权发布，也不占用每包配置额度。npm 文档进一步说明：过期配置不能继续使用或编辑，需要删除再创建。保存连接时不会验证字段是否正确，因此“设置保存成功”还不能证明身份校验通过。

步骤一：在目标包 Settings 找到准确连接

由具备该包设置权限的维护者进入 npmjs.com 的 Packages，选择目标包，再打开 Settings → Trusted publishing。用创建时间、所连仓库和真实发布历史确认目标；保留其他有效连接，不批量重置整个包。

GitHub Actions 的必填字段包括 Organization or user、Repository 和 Workflow filename，可选 Environment name。工作流只填文件名，带 .yml 或 .yaml 后缀，并确实存在于仓库 .github/workflows 目录；大小写和身份必须准确匹配。

步骤二：删除重建，并确认运行环境受支持

确认目标已过期后，删除该连接，再通过 Add trusted publisher 选择提供方并创建新连接。新连接有新的48小时窗口；仓库或项目身份变更也需要新信任关系。已有连接的提供方和必填字段固定，不能靠原位修改延长有效期。

当前文档要求 npm CLI 11.5.1及以上、Node 22.14.0及以上。支持 GitHub Actions 的 GitHub-hosted runner、GitLab.com shared runner 和 CircleCI cloud；self-hosted runner 尚不支持，未来计划不等于当前可用。更换配置不能解决运行环境不受支持的问题。

同时按原发布策略核对 Allowed actions。允许 npm stage publish，不自动允许直接 npm publish 或管理 dist-tags；这些权限各自独立。别为了赶在窗口内完成一次发布而扩大连接权限。

步骤三：以首次成功发布确认验证

在原有发布制度内安排首次发布，保留测试、构建、审阅及必要审批。GitHub Actions 需有 id-token: write，package.json 的 repository.url 应准确对应实际 GitHub 仓库；配置的调用工作流和包名也要匹配。不要临时发布无意义版本来抢窗口。

随后查看实际发布步骤和目标包记录，确认包名、版本、所用连接及成功结果。首次成功发布会验证配置，并绑定仓库不可变身份。保存设置、job 启动或进入 staged queue，都不等于某个版本已经公开可安装；分阶段发布还需遵循其维护者审批流程。

issue_comment 触发的发布也需要调整

同一公告新增拒绝 GitHub Actions issue_comment 事件的 trusted publishing token；已有 pull_request_target 限制仍然适用。这是 npm 对这类 token 来源事件的限制，不代表 GitHub 全面禁用这两个事件。

受影响的维护者可评审迁移到允许的 push、release 或 workflow_dispatch 等事件，保留原审批和标签保护。允许事件不会自动解决身份或权限不匹配；使用可复用工作流时，当前文档要求核对调用方工作流名称，以及父子工作流的 id-token: write 权限。

重建后还失败，按实际发布步骤缩小范围

按官方 troubleshooting 检查准确工作流文件名、字段大小写、repository.url、OIDC 权限和云托管 runner。OIDC 是工作流向 npm 证明身份的机制；不要把多次触发 run、关闭发布门禁或增加长期写入 token 当默认解法。

保留连接创建时间、首次成功发布版本和 run 链接；对外求助只提供脱敏状态。公告没有承诺统一错误码、精确上线时刻或恢复耗时，具体错误应按当前步骤日志核对。本文说明公开规则和操作边界，没有执行真实发包。