扩展发布不再存长期令牌：Trusted Publishing 的信任链怎么核对
据微软开发者博客文章摘要，Visual Studio Code 与 Visual Studio 扩展可从 GitHub Actions 或 Azure Pipelines 发布，发布过程不保存长期个人访问令牌。核对信任链的关键，是把“谁发起发布、市场凭什么接受、凭证有效期与作用范围、失败如何定位”拆成可判定的问题；具体配置字段与校验规则不在本次摘要范围内，需要回原文与官方文档确认。
结论先说清楚：可以确认的是发布方式变了，VS Code 与 Visual Studio 扩展可以从 GitHub Actions 或 Azure Pipelines 发布，并且不再需要保存长期个人访问令牌。至于“信任链怎么核对”，本次材料只有微软开发者博客的文章摘要，没有正文，因此配置入口、字段名、凭证有效期和失败提示都只能标为待核实；下面把能确认的事实和可执行的核对思路分开写。
摘要确认了哪几件事#
依据微软开发者博客 2026 年 10 月 28 日的文章摘要，可以确认三点：
- 发布通道：GitHub Actions、Azure Pipelines 两条 CI 通道。
- 发布对象：Visual Studio Code 扩展与 Visual Studio 扩展。
- 安全属性：不需要存储长期个人访问令牌（Personal Access Token，即 PAT）。
摘要没有覆盖的部分同样要说明：信任关系怎么建立、市场侧用什么标识识别流水线、凭证有效期多长、额度与并发限制、GitHub Enterprise 或自建 Azure DevOps Server 是否支持——这些在本次材料里没有依据，不作推断。
把信任链拆成四段来核对#
以下核对框架属于推断性整理，用于组织验证动作，不代表来源原文列出的步骤。
一、发起方：谁在要求发布
没有长期令牌之后，市场必须能确认请求来自你配置的那条流水线，而不是任何人拿到一个字符串。核对时要能回答：本次发布由哪个仓库、哪个分支或标签、哪条工作流或流水线触发；触发条件是否包含外部可写的入口（例如可被 fork 触发的 pull_request 事件）。如果流水线能被未审阅的代码触发，信任链的上游就是敞开的。
二、接受方：市场凭什么认这条流水线
需要核对的是“绑定关系”的建立与变更权限：谁可以在市场侧登记或修改这个发布来源，变更是否需要额外审批，登记错一个仓库名会发生什么。这一步决定的是信任边界，而不是凭证格式。
三、凭证：有效期与作用范围
短期凭证仍然存在，只是不作为长期秘密保存。要核对：单次凭证的有效时长是否覆盖一次完整发布（构建、打包、上传），过期后的失败表现是什么，凭证能否被重放到别的发布目标。发布失败后重试时，旧凭证是否立即失效。
四、失败路径：怎么定位是信任问题还是产物问题
上线前应准备一组已知会失败的场景并记录报错文本，例如分支不匹配、流水线未登记、凭证过期。没有这份记录，线上发布失败时无法区分“身份被拒”和“扩展包不合规”。
一份可判定的核对记录#
把每条写成能回答“是/否”并附证据的记录，比读一遍文档更有用：
| 核对项 | 要回答的问题 | 证据形式 |
|---|---|---|
| 触发面 | 哪些事件能启动发布流水线 | 工作流或流水线配置文件片段 |
| 绑定关系 | 市场侧登记的发布来源是否与本仓库一致 | 配置页截图或导出的配置 |
| 变更权限 | 谁能改绑定关系，是否有审批 | 权限清单与审批记录 |
| 凭证时效 | 单次凭证有效期是否覆盖完整发布 | 失败与成功的运行日志 |
| 失效路径 | 过期或错配时的报错是否可区分 | 预设故障场景的日志留存 |
不要把“没有长期令牌”读成“没有凭据”#
这是推断，不是来源结论：长期 PAT 的风险是“复制一次就能长期使用”，换成短期凭证后，风险重心转向“谁能触发流水线”和“谁能改绑定关系”。因此迁移时更该检查的是流水线的触发权限和仓库的合并权限，而不是令牌保管方式。
还剩什么必须回原文确认#
配置在哪里完成、需要填哪些字段、凭证有效期、审计日志是否记录每次发布、是否覆盖私有市场或组织级发布——本次只拿到摘要，这些都应回到原文与官方文档逐条核对，再写进你的发布手册。在核对完成前，把结论限定在“支持从 GitHub Actions 与 Azure Pipelines 免长期令牌发布”这一层，不要外推到其他 CI 平台或扩展类型。
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
