GitHub Actions lockfile预览：固定提交仍需代码审查
Dev
浏览 4
审查过的workflow后来执行不同代码，团队究竟批准了什么？GitHub于10月14日发布workflow lockfile公开预览。关键是指定谁审查固定提交，以及谁批准下一次更新。
先确认开放范围
修订后的公告包括GitHub Enterprise Cloud、带数据驻留的Enterprise Cloud、Team和Free。它仍是预览。官方仓库说明不支持GHES，1.0之前格式和行为可能变化。请记录核实日期与扩展版本。
区分标签与批准的提交
扩展生成.github/workflows/actions.lock，记录已接入workflow的action、传递依赖和可复用workflow依赖的提交。它减少引用移动后代码静默变化的风险，但不保证固定代码安全。
从容易审查的小改动开始
以下是运维建议：选择没有生产密钥和部署权限的测试workflow，列出uses引用、维护者和用途。在同一PR审查workflow与lockfile差异，并关联实际运行记录，再扩大强制范围。
为更新指定负责人
官方README中的gh actions-lock --verify不写文件。--verify-local只是离线结构检查，不能替代可信性验证。分别记录CI结果与代码审查，确定负责人、停止条件和恢复办法。本文没有安装扩展。
公告说明，Dependabot更新已接入workflow的action版本时，会在同一PR重新生成对应lockfile条目。自动差异也需要批准。本文建议同时检查引用、提交、权限和新代码的外部通信变化。
可复现不等于安全结论。官方提及社区反馈，但不能据此推断事故减少率或所有环境兼容性。接入前阅读最新README，为审查、固定、更新分别确定责任人。
官方来源
2026年10月15日核实；产品行为与运维建议分开说明。