GitHub Actions 工作流锁文件正式可用后依赖固定方式如何变化

GitHub 于2026年10月28日宣布 Actions 工作流依赖锁文件正式可用。采用锁文件的工作流可以保留易读的标签或分支引用，同时按锁文件记录的具体提交执行动作依赖。变化的重点，是把“读起来的版本名”和“实际执行的提交”分开管理，并覆盖支持范围内的间接动作依赖。

官方地址：https://github.com/

我关注这次变化，主要是因为依赖固定常有一个维护矛盾：写标签容易阅读，写完整提交便于明确执行内容。锁文件为这个矛盾提供了另一种管理方式。以下从一个假设的依赖漂移场景展开，属于公告解读和采用判断，不是一次实际事故复盘，也没有声称已经在生产仓库完成迁移。

同一份工作流为何可能执行不同依赖

设想团队没有修改工作流，却发现两次运行行为不同。排查时如果只对比工作流文件，很容易忽略动作引用背后的标签或分支已经移动。可读名称并不天然等于不可变提交。

这个场景涉及的影响面是依赖解析：仓库中的工作流看起来没变，解析到的远端动作代码却可能变了。这里不是在断言某个动作近期发生了异常，而是在解释锁文件所针对的漂移条件。我的判断是，依赖排查若只记录标签名称，就缺少了可直接比较的执行身份。

从公开预览到正式可用，改变了什么

10月28日的公告把此前公开预览的能力推进到正式可用，列出的适用计划包括 GitHub Enterprise Cloud、带数据驻留的 Enterprise Cloud、Team 和 Free。公告还明确，可以逐个工作流接入；已接入工作流的每个动作依赖都需要进入锁文件。管理员可以通过 Require lockfile 策略推动采用。GitHub 正式可用公告

“正式可用”不等于已有仓库都被自动改写。对于维护者，我更在意能否分批接入，因为构建、发布、文档任务通常有不同的依赖复杂度。先选依赖清楚的一条工作流，更容易把新增文件、引用变化和更新责任说明白。

锁住的是依赖提交，不是整个构建环境

官方文档给出的锁文件位置为 .github/workflows/actions.lock，由 GitHub CLI 扩展 gh actions-lock 生成，不应手工编辑。文件记录工作流依赖及其提交信息，还保存来源仓库的数字身份。对于已接入的工作流，运行时使用锁定提交，并检查它与所记录来源引用的关系。

容易误解的是“可复现”的范围。锁文件不控制输入参数、密钥或运行器镜像，也不替代所有构建依赖的固定。跨仓库可复用工作流调用本身不由这个锁文件固定，仍需以完整提交 SHA 引用；被调用工作流内部依赖则由其定义仓库自己的锁文件负责。工作流依赖锁文件概念文档

因此，若两次运行结果不一致，我会先分开比较动作提交、构建输入和运行环境。锁文件改善的是其中一个明确的解析环节，不能据此承诺整个构建逐位一致。

我会怎样分批迁移现有工作流

我的采用顺序是先盘点动作依赖，挑一条边界清楚的工作流生成锁文件，再把生成文件和工作流修改放进同一项代码审查。这是迁移建议，并非官方要求的唯一顺序。

官方扩展仓库说明，工具需要已认证的 gh，支持 github.com 与数据驻留的 Enterprise Cloud，不支持 GitHub Enterprise Server。工具可以按工作流路径限定处理范围；新增工作流或修改动作引用后，需要重新生成相应记录。gh-actions-lock 官方仓库

扩展目前对本地动作、跨仓库可复用工作流和容器镜像存在明确限制，不能把仓库内所有自动化依赖都当作已经被递归锁定。本地动作中的远端引用尤其需要按官方工具说明处理。我不会把忽略相关提示作为默认接入方案，因为那会让“已接入”的范围难以解释。

防止漂移，也要保留依赖审查

锁文件固定的是所选代码，不负责证明代码本身可信。我的取舍是把“更新了哪个动作”与“锁定提交改变了什么”一起审查，避免只看标签升级就批准。公告说明，Dependabot 为已接入工作流打开动作版本更新时，会在同一拉取请求内更新相应锁定记录；这减少机械维护，但仍需要团队判断变更是否合适。

已经固定完整SHA的仓库必须立刻切换吗？

不必从这次公告推导出强制立即迁移。是否采用取决于可读性、间接依赖管理与现有流程成本。我的建议是先明确收益，再安排逐条接入，而不是为了新增一个文件改动全部流水线。

锁定以后，上游更新还会自动生效吗？

不能把移动标签当成自动升级通道。已接入工作流执行的是记录提交，版本升级需要让锁定记录随变更更新，并接受正常代码审查。锁住旧代码也可能保留旧问题，因此固定与持续维护需要同时存在。

能否用锁文件代替所有依赖管理工具？

不能。包依赖、容器内容、运行环境和动作依赖各有管理边界。比较适合优先采用的，是希望保留可读动作引用、同时明确执行提交并管理间接动作依赖的团队。对于我来说，这次正式可用的价值在于让依赖身份更清楚，而不是让仓库维护从此无需判断。