Actions lockfile 正式发布：绿色检查不都代表同一种证据
PR 里的 uses 版本看起来没变，背后运行的代码却可能变化，因为标签可以移动到另一个提交。GitHub 在 10 月 28 日宣布 workflow lockfile 正式发布。预览版介绍的固定机制仍然适用，接下来值得关注的是每项检查究竟证明了什么。
保留易读引用，运行记录的提交
.github/workflows/actions.lock 把 action 引用与运行提交关联起来，通过 gh actions-lock 生成，支持 Free、Team、GitHub Enterprise Cloud 及其数据驻留环境。可以逐个工作流采用。应把生成文件和工作流修改一起审查，而不是手动拼装 lockfile。
假设 demo/build@v1 起初指向 A，后来移到 B。只解析引用，下次运行就可能选中不同代码；lockfile 选择记录的提交。下图是自制假想示例，并非真实仓库运行记录。若该提交已无法从记录的上游标签或分支到达，运行时仍可能拒绝它。
离线通过究竟确认了什么
官方工具区分 gh actions-lock --verify-local 和 gh actions-lock --verify。前者不联网，只检查 uses 是否具有对应条目，即 coverage，适合提交前快速检查，却不验证来源。后者在线检查 provenance，runner 也会在任务开始时再次检查。两个绿色结果的含义不同。
如果并行 PR 新增了 action 却没更新 lockfile，本地检查可以发现条目缺失。但条目齐全不代表来源或代码安全性已经得到证明。第二张图根据文档整理检查范围；本文没有安装或运行 CLI 来生成实际结果。
可复用工作流有自己的仓库边界
action 内部使用的传递依赖也在覆盖范围内，但 jobs.<job_id>.uses 调用的可复用工作流本身不会由 lockfile 固定，需要使用完整提交 SHA。其内部 action 由定义该工作流的仓库 lockfile 管理，而非调用方的文件。
例如应用仓库调用平台仓库的部署工作流，只审查应用的 actions.lock 无法看到平台 action 的固定情况。需要结合调用 SHA 与平台仓库的依赖变更。runner 镜像、输入和 secret 也是不同的构建输入，固定 action 提交并不会冻结整个环境。
更新 PR 里要把两个文件一起读
Dependabot 更新已采用机制的工作流中的 action 版本时，会在同一 PR 中重新生成对应 lockfile 条目，便于对照易读版本与实际提交。--relock 会推进已移动的引用并写入文件，与只读验证用途不同。代码变更本身仍需要审查。
Require lockfile 可以强制采用，却不会消除仓库边界。先在一个工作流中理解生成、审查和在线验证，再推广会更清楚。下次看到绿色检查时，不妨明确它提供的是条目覆盖、来源验证，还是对所选代码的实际审查。