GitHub Actions工作流依赖锁文件正式发布：保留标签引用，运行锁定的确切提交

GitHub 于 2026 年 10 月 28 日宣布，GitHub Actions 工作流依赖锁文件正式发布（GA）。适用范围包括 GitHub Enterprise Cloud、带数据驻留的 GitHub Enterprise Cloud，以及 Team 和 Free 套餐。锁文件让工作流保留可读的标签和分支引用，同时运行被锁定的确切提交，即使这些引用之后发生移动。更新日志说，正式版带来了公开预览阶段引入的全部能力。

要解决的是可变引用的问题。工作流写明使用某个标签或分支上的动作，作业启动时就运行该名称当时指向的提交。如果名称被移动，作业就会悄悄运行另一份代码。例如，工作流写的是某个动作的 v4 标签，维护者把该标签移到新的提交，下一次运行就会执行新代码，而仓库里的工作流文件一个字都没有改。锁文件记录这些名称背后的提交，既包括动作本身，也包括它们的传递依赖，也就是这些动作所使用的其他动作。GitHub CLI 的 gh actions-lock 扩展会生成 .github/workflows/actions.lock 文件。工作流文件仍保留可读的引用，由锁文件决定实际运行什么。

采用可以循序渐进。团队逐个工作流启用。工作流一旦启用，GitHub Actions 要求它的每个依赖都出现在锁文件中，并运行其中记录的提交。因此不必一次覆盖所有工作流。想要硬性规则的团队，可由企业、组织和仓库管理员使用“要求锁文件”策略来强制。更新日志没有说明违反该策略的工作流会怎样，所以管理员应先在小范围试用，再大面积启用。

有两项功能让文件长期保持准确。当 Dependabot 为已启用工作流中的动作发起版本更新时，会在同一个拉取请求里重新生成对应的锁文件条目，无需额外配置。这省去了单独重新生成的步骤。团队还可以检查锁文件是否过期。该检查在不修改任何文件的情况下验证锁文件是否最新，因此可以作为 CI 检查运行，当有人改了工作流却忘了锁文件时让构建失败。

GitHub 明确说明了限度。锁文件有助于防范依赖的意外变化，但不判断依赖是否安全。锁定时就带恶意或漏洞的提交，锁定后仍然如此。GitHub 建议在锁定之前先审查依赖。因此，锁文件是把审查点提前到锁定时和每次 Dependabot 更新时，而不是取代审查。锁文件也不会让旧依赖自动变安全，不能代替对第三方动作来源的评估。更新日志也没有提到自托管运行器或 GitHub Enterprise Server，相关团队应查阅文档。

更新日志列出的能力共有五项：用 gh actions-lock 扩展为动作及其传递依赖生成锁文件；逐个工作流启用；Dependabot 版本更新时在同一拉取请求里重新生成对应条目；企业、组织和仓库管理员可用“要求锁文件”策略强制采用；以及在不修改文件的前提下检查锁文件是否过期，包括在 CI 中检查。其中“逐个启用”和“策略强制”决定了推广节奏：可以先在少数关键工作流上启用，再用策略扩大范围。常见的另一种做法是把动作固定到完整的提交哈希，但那会让工作流文件难以阅读和手工升级；锁文件把这种固定放进单独的文件，工作流本身仍保留可读的引用。更新日志还提醒要先审查再锁定，并给出社区讨论和扩展仓库的问题跟踪两个反馈渠道，文档中有设置说明。对已经把动作固定到哈希的团队，值得比较两种方式的维护成本。使用前提也要核对：该功能在 Enterprise Cloud、带数据驻留的 Enterprise Cloud、Team 和 Free 上可用，更新日志没有把其他部署形态列入。

开始使用时，先从 gh-actions-lock 仓库安装扩展，生成锁文件，再审查并提交锁文件和工作流的改动。GitHub 提供了工作流依赖锁文件的文档，以及用于反馈的社区讨论和问题跟踪。

对依赖第三方动作的团队来说，实际收益是得到一份可审查的记录，说明流水线究竟运行了哪些代码，并且让漂移在拉取请求中可见。团队还可以把过期检查加入合并门禁，让漂移成为需要评审的改动，而不是事后才发现的意外。