GitHub Actions 怎样让工作流按锁定提交运行

GitHub Actions 工作流里如果写的是 owner/action@v3 或 owner/action@main，标签和分支以后都可能移动，下一次运行的实际代码就未必还是审查过的版本。GitHub 在 2026 年 10 月 14 日宣布工作流依赖锁文件进入公开预览，目标就是把这些引用固定到已经确认的提交。

官方工具地址：https://github.com/github/gh-actions-lock

想让工作流按审查过的提交运行，可以使用 GitHub CLI 的 gh actions-lock 生成 .github/workflows/actions.lock，再把锁文件变化放进 Pull Request 审查。它能覆盖 action 及部分传递依赖，但仍处于公开预览，不能替代对容器镜像和例外依赖的单独检查。

• 锁文件解决的是 tag 或 branch 漂移，不是“依赖天然安全”。
• 锁定结果应和工作流一起提交，变更由 Pull Request 审查。
• 生成、验证、自动更新和限制边界要分开理解。

为什么工作流需要锁定提交

直接写版本标签便于阅读，但标签背后的提交可以改变；直接写完整 SHA 虽然稳定，却要在每个工作流里手工维护，而且不容易表达传递依赖。工作流锁文件把“工作流里写的引用”和“本次真正运行的提交”分开记录，读者仍能看到 v3 这样的语义版本，运行时则按锁文件中的提交执行。

官方说明中，锁文件位于 .github/workflows/actions.lock，除了工作流直接使用的 action，还会记录可解析的传递依赖。工作流接入锁定后，依赖必须有对应条目，运行时使用记录的提交；因此锁文件本身也应该进入代码评审。

怎样生成第一份 actions.lock

官方仓库提供了 GitHub CLI 扩展。下面的命令展示最小准备和生成路径；命令没有在本文环境中执行，实际使用时应先确认当前目录是目标仓库，并检查登录账号具备读取依赖仓库的权限。

# 安装 GitHub Actions 依赖锁文件扩展
gh extension install github/gh-actions-lock

# 在仓库根目录生成或修复 actions.lock
gh actions-lock

# 把工作流和机器生成的锁文件一并交给 Pull Request 审查
git add .github/workflows/
git diff --cached -- .github/workflows/

工具生成的是机器维护文件，不建议直接编辑 actions.lock。新增工作流、修改 uses: 引用或升级依赖后，再运行一次 gh actions-lock，让工作流引用和锁定提交保持对应。

生成、验证与更新怎样接入仓库流程

锁文件真正有价值的地方是进入日常变更流程。生成命令负责写入或修复锁文件，--verify 适合在 CI 中检查锁定状态和来源，--verify-local 则做不访问网络的覆盖检查。两者的职责不同，不能把本地覆盖检查当成提交来源证明。

# 远程检查锁定提交和依赖来源，适合接入 CI
gh actions-lock --verify

# 不访问网络，只检查每个 uses 是否有锁文件覆盖
gh actions-lock --verify-local

# 只查看报告，不改写文件
gh actions-lock --no-fix

官方仓库还说明，Dependabot 更新 action 版本时可以同步更新对应锁文件。团队应把锁文件 diff 当成依赖升级的一部分来审查：先确认引用变化，再确认提交变化，最后确认工作流权限和运行范围没有被顺带扩大。

公开预览阶段要注意哪些边界

这项能力仍是公开预览，锁文件格式、命令参数和行为可能变化。它解决的是工作流依赖在标签或分支移动后的可重复性，不代表被锁定的依赖一定安全；异常更新、权限扩大和被攻陷的来源仍然需要人工审查。

常见问题

已经使用完整 SHA，还需要锁文件吗？

不一定。完整 SHA 已经能固定直接引用，但锁文件还能统一记录传递依赖，并减少工作流 YAML 中的重复长字符串；是否迁移要结合仓库覆盖范围和公开预览的接受程度决定。

为什么生成锁文件后还要看 Pull Request？

锁文件只记录解析结果，不替你判断依赖是否值得信任。升级时应同时查看工作流、锁文件和权限变化，确认更新来自预期仓库并且没有扩大执行能力。

锁文件能锁定所有工作流依赖吗？

不能直接这样理解。官方文档对可复用工作流、本地 action 和容器镜像都有覆盖边界，接入前应按实际依赖类型阅读限制，并为未覆盖对象保留独立的固定策略。