面向维护 GitHub Actions 与 Mac CI 的企业 IT、平台工程和安全负责人，本文评估 workflow lockfile 能固定哪些依赖、与完整 SHA 的差异，以及它无法替代的 Runner 与凭证控制。文章还给出渐进试点步骤、定性对比评分和启用 Require lockfile 策略前应收集的证据。
面向维护 GitHub Actions 与 Mac CI 的企业 IT、平台工程和安全负责人，本文评估 workflow lockfile 能固定哪些依赖、与完整 SHA 的差异，以及它无法替代的 Runner 与凭证控制。文章还给出渐进试点步骤、定性对比评分和启用 Require lockfile 策略前应收集的证据。
Mac CI 的 Action 标签或分支移动后，构建可能运行与审查时不同的提交。
最快解法：对符合条件的仓库先试点 GitHub Actions workflow lockfiles，再用影子验证和小范围策略评估确认更新闭环；它不代表依赖已安全，也不代表 Runner 已隔离。
谁该看：企业 IT 或 GitHub Enterprise 管理者，评估 lockfile 策略的适用范围和启用门槛。
谁该看：维护 Mac CI、共享 Action 与 Dependabot 更新流程的平台工程负责人。
谁该看：需要降低依赖引用漂移，同时明确控制边界的安全负责人。
最后更新于 2026 年 10 月 15 日；功能状态、适用范围与操作边界核实自 GitHub 公开预览公告。截至该日期，GitHub Actions workflow lockfiles 与 Require lockfile 策略处于公开预览；不能将预览写成正式 GA，也不能据此推断所有企业账户均有资格使用。
GitHub Actions workflow dependency lockfiles 将已接入工作流引用的 Action 绑定到记录的提交，也覆盖 Action 的传递依赖和可复用工作流依赖。它不是整个 CI 系统的总锁：Xcode、构建脚本、Runner 镜像、主机工具链和签名凭证不因此自动得到版本锁定或安全证明。(GitHub 官方工作流依赖锁文件文档)
依赖归属也有边界。锁文件位于仓库的 .github/workflows/actions.lock，覆盖该仓库接入的工作流；可复用工作流的依赖，则由定义该可复用工作流的仓库负责锁定。团队维护共享工作流时，应把共享工作流仓库纳入接入和审查，而不能只检查调用方仓库。
本地 Action 需要单独核对。接入时，本地引用会改写为指向当前运行提交的引用；如果本地路径没有解析到有效 Action 文件，工具可能跳过相应工作流。生成前应检查路径和完整差异，不能只确认锁文件已经出现。(GitHub 官方锁定 Action 依赖操作指南)
工作流引用 @v3 或 @main 时，运行时解析到的提交可能随标签或分支移动而改变。GitHub 的 lockfile 规则让已接入工作流使用锁文件记录的提交；每个依赖条目记录引用、提交、源仓库所有者 ID 和仓库 ID。仓库身份变化或提交变化都应进入审查，而非被当作普通格式更新。
与完整 commit SHA 固定相比，lockfile 把固定结果放在集中管理文件里，workflow 中可以保留较易读的引用，也能覆盖传递依赖；完整 SHA 则在每条 uses 引用中直接展示固定值，但维护者需要自行管理引用和依赖更新。GitHub 仍建议把完整 SHA 视为不可变 Action 发布的固定方式；采用 lockfile 后，代码信任审查依然不能省略。(GitHub 关于选择和自定义 Actions 的文档)
我们会把“提交固定”和“审核通过”分开判断：固定只能回答运行哪份代码，不能回答这份代码是否可信、是否含漏洞，或更新是否符合发布风险要求。源仓库身份异常、提交变化或上游引用发生移动，都应作为依赖变更重新审查。
lockfile 的主要价值，是降低标签或分支移动造成的意外依赖变更，让提交变化可以进入审查流程。它不能证明 Action 本身安全，也不能隔离已经被攻陷的 Runner、阻止不可信任务访问本机文件或网络，更不会自动保护可被任务读取的凭证。GitHub 对自托管 Runner 的安全说明明确提醒，不可信工作流代码可能影响 Runner 环境和可访问的秘密。(GitHub Actions 安全使用参考)
Mac CI 应把控制拆成多层，而不是把“已锁定”当成安全验收通过：
GITHUB_TOKEN 限制到任务必需权限；构建、测试与发布工作流分别授权。因此，回答“用了 workflow lockfile 还需不需要 Runner 隔离”，在生产 Mac CI 中应当是肯定的：lockfile 管依赖引用确定性，Runner 隔离和凭证治理管执行环境与访问边界，两者不能互相替代。
lockfile 只有持续更新才有用。Dependabot 为已经接入的工作流更新 Action 版本时，会在同一拉取请求中更新匹配的锁文件条目；但它不会自动为尚未接入的工作流补齐覆盖。具体操作还应核对官方说明，包括如何验证锁文件，以及怎样处理工作流或本地 Action 的变化。(GitHub 官方锁文件维护与强制策略指南)
我们建议按以下步骤做小范围试点：
gh actions-lock 扩展，按单个工作流或仓库生成锁文件，不要手工改文件。.github/workflows/actions.lock 加入 CODEOWNERS 审查范围。审查重点包括提交 SHA 变化，以及源仓库所有者或仓库身份变化。gh actions-lock --verify 检查锁文件是否过期，适合作为拉取请求检查。尤其要留意权限：自动更新任务可能需要 contents: write，并要求分支保护规则允许该任务提交。这个写权限不是可以默认授予所有构建任务的通用配置；应将更新任务与常规构建、签名发布任务分开，并按最小权限原则设置。
截至 2026 年 10 月 15 日，GitHub 于 10 月 14 日公布 workflow dependency lockfiles 与 Require lockfile 策略进入公开预览；公告列出的对象包括 GitHub Enterprise Cloud 和带数据驻留的 GitHub Enterprise Cloud。Require lockfile 的操作说明标注该功能处于公开预览；其中 Evaluate 模式仅适用于 GitHub Enterprise。实际资格和策略控制项应以账户当前可见的官方设置与文档为准。
强制策略的真实影响不是“提醒团队补文件”，而是可能阻止目标范围内未完成接入的工作流运行。官方建议先限定已接入的仓库和工作流，使用 Evaluate 模式检查策略评估结果，再决定是否将策略切换到 Active；因此，不要从全企业范围直接启用。
| 方案或控制 | 引用确定性评分 | 传递依赖覆盖 | 执行环境隔离 | 维护与治理判断 |
|---|---|---|---|---|
| 标签或分支引用 | 低：运行时可能解析到移动后的提交 | 无锁定保证 | 无 | 易读，但代码变更可能不明显 |
| 完整 commit SHA | 高：引用直接固定提交 | 需要逐项维护引用 | 无 | 差异可见，但更新需逐项审查 |
| Workflow lockfile | 高：已接入工作流使用记录提交 | 覆盖 Action 传递依赖；可复用工作流由其定义仓库负责 | 无 | 需持续生成、验证、审查 |
| Require lockfile 策略 | 以锁文件有效性为准 | 不扩大锁文件自身覆盖范围 | 无 | 强制前先看评估结果，避免拦截未接入工作流 |
| Runner 组与权限治理 | 不固定依赖版本 | 不解决依赖版本覆盖 | 有助于划定访问范围，仍需正确配置 | 与 lockfile 配套，不可由其替代 |
评分说明：表中“高／低”是按对应控制能否固定 Action 提交作出的定性判断，不是 GitHub 官方性能评分，也不表示依赖安全等级。Runner 组可以限制哪些仓库使用自托管 Runner，但单有分组仍不能证明具体工作流、主机和凭证已经完成隔离。
扩围前，企业至少应留存这些可复核证据：已接入依赖清单及覆盖范围、锁文件更新和验证记录、提交变化的审查记录、策略评估结果，以及真实 Mac CI 工作流的运行结果。缺少更新闭环时保留试点；依赖覆盖和审查记录完整、策略评估可接受后，再扩大仓库范围；若核心问题是 Runner 共用、凭证暴露或发布权限过宽，应先修复执行边界，而不是指望 lockfile 补上这些缺口。
它固定已接入工作流引用的 Action 提交，并覆盖 Action 的传递依赖和可复用工作流依赖。可复用工作流的依赖由定义该工作流的仓库负责锁定；因此，调用仓库的 lockfile 不能代表所有共享工作流及其依赖都已覆盖。
完整 SHA 直接写进 uses 引用，lockfile 则在独立文件中记录引用和提交，并覆盖传递依赖。两者都固定版本而不评判代码安全；选择时应比较团队的依赖审查能力、更新习惯和差异可读性。
需要。锁文件解决依赖引用可能移动的问题，不会隔离 Mac 主机、清理任务残留或限制任务可访问的签名凭证和网络资源。企业仍需限制 Runner 组可被哪些仓库使用，并将不可信工作流与持有发布凭证的任务分开。
先选已完成接入的仓库和工作流，检查更新、验证与审查是否形成闭环；符合资格时先运行 Evaluate 模式并查看策略评估结果，再考虑启用 Active。因为未接入的目标工作流可能被策略阻止运行，扩围前应确认新工作流也会进入更新和验证流程。
如果评估发现的主要问题是依赖漂移，先完善锁文件审查和更新检查；若仍有 Mac Runner 共用、凭证暴露或发布权限边界不清的问题，则需要另行规划主机与执行隔离。可结合团队 Mac CI 环境与远程 Mac 资源梳理构建节点需求，并按实际工作负载比较自购 Mac 方案与按需租赁：现有方案可能仍需自行承担设备采购与折旧、异地维护、扩容等待等成本。若只是短期试点或构建高峰，VNCMac 的远程 Mac 可作为额外构建资源选项；若工作负载长期稳定且重负载，或必须接入本地物理接口，应先评估自购与本地托管的适配性，再决定是否租赁。
它记录已接入工作流所用 Action 的引用及其对应提交，并覆盖 Action 的传递依赖和被调用的可复用工作流。依赖定义属于相应仓库：可复用工作流自身的依赖由定义该工作流的仓库负责锁定；因此不能把单个仓库的锁文件理解为整个组织所有 CI 依赖的完整清单。
完整 SHA 写在 workflow 的 uses 引用中，单个引用直观且固定；lockfile 保留较易读的版本引用，同时记录提交和源仓库身份，并能覆盖传递依赖。两种方式都只能确定运行代码的版本，不能证明代码安全。试点时应审查生成的提交变化，再决定采用何种更新与审核流程。
需要。lockfile 固定的是工作流 Action 依赖，不会清理或隔离执行任务的 Mac 主机，也不会阻止不可信代码读取 Runner 可访问的凭证或网络资源。企业仍需按仓库与工作负载划分 Runner 访问范围，限制 GITHUB_TOKEN 权限，并避免在共用节点上混跑不可信拉取请求与签名发布任务。
先选已完成接入的仓库和工作流，生成并审查锁文件，再验证新建工作流、Action 变更和依赖更新都能触发更新或校验。符合资格时先用 Evaluate 模式查看策略评估结果；确认目标工作流已覆盖、更新审查闭环能持续运行后，才考虑 Active。公开预览的资格与策略能力应以 GitHub 当前文档为准。