Visual Studio 扩展改用 Trusted Publishing：从 GitHub Actions 发布时怎么去掉长期密钥

可以去掉。Visual Studio Marketplace 的 Trusted Publishing 让 CI/CD 系统用联邦身份向 Marketplace 证明“这次发布来自这条工作流”，从而换取临时凭据完成发布，CI 里不再需要保存长期 Azure DevOps 个人访问令牌（PAT，Personal Access Token）。但它不是“删掉 secret 就完事”：GitHub Actions 侧必须先建一条绑定仓库与工作流的策略，工作流要显式申请 OIDC 令牌，并且建议在第一次 OIDC 发布验证成功之后再删旧 PAT。以下内容依据微软 2026 年 10 月 28 日的发布说明（devblogs.microsoft.com），具体命令与参数以官方文档为准。

它替换掉的到底是什么#

传统做法是把一个 Marketplace PAT 存成仓库 secret，流水线每次发布时读取它。问题不在于 PAT 本身能不能用，而在于它是一个长期有效、可被复制到任意位置的凭据：只要它留在 secret 里，任何能读到该 secret 的工作流步骤、分支或协作者都具备发布能力，轮换也就变成一件靠人记的事情。

Trusted Publishing 的思路是把“持有一个密码”换成“证明我是谁”。按发布说明，它带来三点变化：

• 没有长期发布凭据：CI 系统里不再存放需要轮换的发布 secret。
• 短期访问：GitHub Actions 场景下，Marketplace 签发的临时凭据 15 分钟后过期。
• 联邦身份：Marketplace 信任的是一条已配置的 GitHub 工作流，或一个 Azure Pipelines 的工作负载身份，而不是一段字符串。

发布说明同时明确：基于 PAT 的既有发布方式继续可用，所以这是一次可以按自己节奏推进的迁移，而不是强制切换。

流程：三次校验，一次发布#

1. CI/CD 系统把自己的联邦身份出示给 Visual Studio Marketplace。
2. Marketplace 校验 GitHub 侧的 Trusted Publishing 策略，或 Azure Pipelines 侧的工作负载身份。
3. 发布工具带着这个已验证身份发布扩展，全程没有 PAT 参与。

发布说明的描述是：用 OIDC 发布时这个过程是自动的，没有 PAT 需要读取或管理。换句话说，配置成本集中在“策略”和“工作流权限”两处，而不是每次发布都要手工干预。

GitHub Actions：先建策略，再改工作流#

策略是整套机制里唯一的授权来源，字段不多，但必须逐字匹配。在 Visual Studio Marketplace 登录后打开拥有该扩展的 publisher，进入 Trusted Publishing，展开 Create：

表中“常见错法”是按字段语义归纳的排查方向，不是官方给出的错误清单；实际报错信息需以文档和控制台提示为准。

私有仓库的 48 小时窗口

这是最容易踩的一处：如果仓库是私有的，新建策略后需要在 48 小时内运行一次已配置的工作流。首次成功的令牌交换会把策略永久激活；若这段时间内没有使用，策略会过期，可以重新打开以获得又一个 48 小时。公开仓库没有这条限制。策略的状态和最近使用时间都能在 Trusted Publishing 页面查看——迁移卡住时，先看这里比看日志快。

工作流需要显式申请令牌

OIDC 不是默认开启的，发布 job 必须拿到 id-token: write 权限。下面是一个结构示意，未实际执行，其中的 action 版本、Node 版本和发布命令都应按你仓库当前情况替换：

name: publish
on:
  workflow_dispatch:

permissions:
  contents: read
  id-token: write        # 换取联邦身份所必需

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: production   # 若策略里填了 Environment，名称必须一致
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      # 发布命令的 OIDC 参数请以 VS Code 官方文档为准，此处不代填
      - run: npx vsce publish

注意示例中最后一行只是占位：发布说明写的是“把发布命令更新为使用 OIDC”，但并未在该文中给出具体参数形式。VS Code 扩展应参照 VS Code 文档的《Secure automated publishing to Visual Studio Marketplace》，Visual Studio 扩展则参照《Publish a Visual Studio extension via command line》。参数拼错时通常表现为身份校验失败而非语法错误，因此不要凭记忆补全。

Azure Pipelines：另一条路，不要建 Marketplace 策略#

Azure Pipelines 不走 GitHub 策略，而是一个由 Microsoft Entra 支持的工作负载身份联合（WIF，Workload Identity Federation）服务连接。发布说明对此有明确提醒：不要为 Azure Pipelines 在 Marketplace 的 Trusted Publishing 页面创建策略。需要做的是：

1. 配置一个使用 WIF 的 Azure Pipelines 服务连接，底层可以是 Entra 应用注册加服务主体，也可以是托管标识。
2. 把该身份加入 Visual Studio Marketplace publisher，并授予 Contributor 角色。
3. 让发布步骤使用这个 WIF 服务连接。

之后流水线同样可以在不存 Marketplace PAT 的情况下发布 VS Code 或 Visual Studio 扩展。

迁移顺序：先并存，后删除#

发布说明给出的 GitHub 侧迁移路径是四步：为仓库和工作流建策略；给发布 job 加 id-token: write；把发布命令改成 OIDC；运行并确认 OIDC 发布成功。成功之后，才从工作流和仓库 secret 中移除 Marketplace PAT。

这里有一条值得照做的建议：在首次 Trusted Publishing 运行验证通过前保留 PAT。删除动作本身不可逆，而失败原因可能来自策略字段、environment 名称或令牌权限中的任意一处；保留 PAT 期间可以把发布步骤临时切回旧路径，先恢复发版再排查。迁移成功后再删掉那个已无用的 secret，避免它被别的步骤误引用。这是操作建议，不是发布说明中的强制要求。

顺序反过来——先删 PAT 再调策略——会让一次配置失误直接变成“发不出版”，而私有仓库还有 48 小时窗口在倒计时。

边界与需要自行核实的地方#

• 具体命令参数：本文未执行任何发布命令，vsce 的 OIDC 参数形式、是否需要额外插件或版本下限，均以官方文档为准，本文不作断言。
• 适用对象：发布说明覆盖 Visual Studio Code 与 Visual Studio 扩展两类；其他 Marketplace 品类是否适用，材料未提及，待核实。
• 回滚成本：策略可重新打开、PAT 可重建，但两者都需要 publisher 权限，团队里应确认谁有这个权限。
• 故障排查：发布说明提到官方文档包含完整安装与排查指引，但没有列出具体错误码；遇到校验失败时，建议按“策略字段是否逐字一致 → 工作流是否声明 environment → 是否申请 id-token → 仓库可见性与 48 小时窗口”的顺序自查。

总体判断：这项机制把发布凭据从“长期持有的秘密”改成“可验证的短期身份”，代价是一次性的策略配置和一次迁移验证。对已经在 GitHub Actions 上自动发版、且 secret 由多人共管的团队，收益比较直接；对仍在本机手工发布的流程，它不解决任何问题，因为整个机制的前提是发布动作发生在一个可被 Marketplace 识别的 CI/CD 工作流里。