GitHub Actions cache-mode 怎么配？2026 企业 Mac CI 防投毒指南

症状：不可信任务可能把缓存内容带入可信构建；持久化的 Mac Runner 还可能留下工作区状态和凭证。
最快解法：不可信任务优先设为 read 或 none，由可信工作流维护缓存；只有输入可信且确需写入时，才开放 write 或 write-only。cache-mode 只控制缓存访问，不会清理或隔离 Mac 主机。

适合负责企业 GitHub Actions 策略的 IT 与平台工程负责人，用来明确缓存读写权限和审批边界。
负责 iOS/macOS CI 的工程负责人，可据此检查缓存与真实 Mac 构建任务之间的风险传递。
安全负责人可用文中的检查点复核非可信代码是否可能影响可信流水线。

最后更新于 2026 年 9 月 24 日；权限模式与默认行为核实自 GitHub 的 cache-mode 公告。公告于 2026 年 9 月 10 日发布。发布或调整配置前，仍应复核官方文档中的有效权限与触发器分类；本文不提供 MacDate Runner 隔离、清理或交付能力的实测数据。

权限模式：缓存读写边界，不是代码执行隔离

GitHub 的 cache-mode 可在工作流或单个 job 上控制缓存恢复与保存；job 级设置会覆盖工作流级设置。缓存服务按所授模式执行访问控制，该模式也会传递到可复用工作流。

评分是策略层面的风险判断，不是实测结果。实际选择还要看工作流执行的代码、凭证范围以及 Runner 是否与其他任务共享。

read、write、none 和 write-only 的区别是什么？ read 只恢复，write 可恢复也可保存，none 禁止两者；write-only 只保存、不恢复。省略 cache-mode 时，GitHub 根据触发器应用相应默认值：可信触发器通常为 write，低信任触发器通常为 read。在低信任触发器上显式设为 write 或 write-only，会覆盖只读默认限制并重新引入缓存投毒风险。具体语法与默认行为以官方工作流语法为准。

示例：PR 构建只读缓存，可信主分支构建负责更新缓存：

jobs:
  pr_build:
    cache-mode: read
    # 执行 pull_request 构建

  trusted_build:
    cache-mode: write
    # 仅在可信 push 工作流中维护缓存

这只是权限配置示例，不能替代完整的工作流授权审查。工作流的 permissions 控制 GITHUB_TOKEN 能做什么，cache-mode 控制缓存访问，两者是不同的权限面，需要分别核对。

触发器信任：PR 只读与可信写入分开

pull_request 工作流应使用哪种缓存权限？ 如果构建会执行 PR 提交者控制的代码，明确使用 read；若任务不需要缓存，或缓存内容也不应暴露给该任务，则使用 none。把缓存写入交给仅处理可信代码的 push 工作流，而不是让不可信构建承担缓存维护职责。

还要区分缓存权限和缓存作用域：GitHub 文档说明，pull_request 运行创建的缓存位于合并引用（merge ref）的作用域，不能写入默认分支的缓存作用域；这项范围限制不等于主机隔离，也不意味着恢复到的内容可以信任。相关边界见官方依赖缓存安全参考。

几个容易混淆的触发器需要单独审查：

• pull_request 用于构建 PR 代码。即使缓存作用域受限，self-hosted Mac Runner 仍可能复用本地环境；缓存隔离不能证明 Runner 干净。
• pull_request_target 使用基础仓库的工作流上下文，常用于标签、评论等自动化。它默认对默认分支作用域内的缓存只读；若显式授予写权限，可能重新引入投毒风险。不要为运行 PR 代码而检出并执行 fork 内容。详细风险见安全使用 pull_request_target 的官方说明。
• workflow_run 后续工作流可能获得 Secrets 和写入令牌，即使上游工作流没有这些权限。对上游上传的产物应按不可信数据处理，不要下载后直接执行。触发器权限边界见官方事件文档。
• 受信任的 push 可承担缓存维护，但触发器可信不代表所有依赖、构建脚本和输入都天然可信。

怎样阻止不可信 PR 把内容写进可信构建会读取的缓存？ 让处理 PR 代码的 job 显式使用 read，需要完全禁止缓存访问时改用 none；再由可信 push 工作流更新其可写入的缓存。使用可复用工作流时，在调用它的 job 上设定权限上限；否则调用与被调用工作流对缓存权限的预期可能不一致。若覆盖低信任触发器的只读默认值，之后恢复该缓存的工作流都应把内容视为不可信，尤其不能在带有高权限凭证的任务中盲目执行恢复结果。

缓存内容：分支范围不等于任务身份隔离

缓存按工作流运行使用的分支或标签共享，而不是按工作流或 job 身份隔离；恢复时，任务拿到的是缓存中的原始内容。GitHub 明确建议把恢复内容视为不可信输入，不要在缓存中存放密钥或其他敏感信息。相关概念和安全边界见官方缓存说明。

GitHub Actions 缓存投毒会怎样影响可信流水线？ 一个常见风险链是：不可信代码或依赖影响了缓存目录；可信工作流随后恢复该缓存；构建又把其中被改动的文件作为脚本、依赖或可执行产物运行。风险因此不只取决于“谁能写”，也取决于“谁能读、恢复后执行什么”。

按依赖锁文件、工具链和构建条件区分缓存键及恢复键，但不要把缓存键当作完整性证明。把可重新生成的依赖与可执行构建产物分开管理；需要跨 job 传递构建输出或日志时，评估是否使用 workflow artifact，而不是把缓存当作可信交付通道。

⚠️ write-only 只表示任务不能恢复旧缓存、但可以保存新内容。如果写入内容受不可信 PR 影响，而可信任务之后会读取它，投毒风险仍然存在。

Mac Runner 隔离：缓存模式无法重置主机

缓存权限能保护持久化的 Mac Runner 吗？ 不能。cache-mode 控制 GitHub Actions 缓存访问，不会重置 Mac 上的工作区、用户目录、工具链状态、临时文件或凭证。GitHub 对 self-hosted Runner 的安全建议提醒：Runner 环境可能不会在每次运行后自动变为干净、临时的环境；运行不可信代码可能影响 Runner，并波及其可访问的内部资源和凭证。(GitHub self-hosted Runner 安全文档)

这对 Xcode CI 特别关键：如果不同信任级别的任务共用一台持久化 Mac，低信任任务留下的状态可能绕过缓存权限边界。PR 检查与生产签名若在同一主机上运行，代码信任问题也会扩展到签名材料和内部资源的暴露风险。

按信任边界安排节点，而不是只按仓库名称分组：

• 不可信 PR：优先放到不接触生产凭证的独立 Runner 组；无法确认环境隔离与任务后清理时，不要安排在承载可信构建的持久化主机上。
• 可信构建：限制 Runner 组可被哪些仓库使用，并把凭证、网络资源和工作目录控制在任务所需范围内。
• 生产签名：与低信任 PR 分离；按需提供凭证，并保留审批和审计证据。签名材料不应进入缓存。
• 自托管 Mac：明确任务结束后的清理和重建责任。若无法证明任务隔离与环境清洁，就不能把 read 或 none 当作主机安全证明。

Runner 组边界、清理方式、凭证隔离与网络访问必须分别核验；这些都不是 cache-mode 能完成的工作。

验收证据：用日志和主机记录决定是否放量

不要只检查工作流文件写了什么，还要核对运行时的有效模式、缓存日志和 Runner 状态。模式不允许某项缓存操作时，该操作会被跳过并记录信息；跳过恢复按缓存未命中处理，跳过保存也不会执行，任务本身可以继续。因此，工作流成功结束不代表缓存恢复或保存成功。

按清单做可信与不可信任务的对照验收，并留存工作流版本、触发器、运行日志或主机清理记录。以下是企业验收步骤，不是本站实测结论。

• [ ] 标记每个触发器和输入的信任级别，特别检查 fork PR、pull_request_target、workflow_run 与可信 push。
• [ ] 核对工作流级和 job 级 cache-mode，确认覆盖关系符合预期；检查可复用工作流的调用权限上限。
• [ ] 分别检查 GITHUB_TOKEN 的 permissions、Secrets 访问条件与缓存模式，确认没有把其中一项误当成另一项。
• [ ] 对照可信和不可信任务的恢复、保存日志，区分“权限模式跳过操作”和“缓存读写成功”。
• [ ] 检查缓存键、恢复键及缓存路径，确认没有凭证，也没有把未经验证的可执行产物作为可信输入。
• [ ] 复核 Runner 组、主机复用方式、任务后清理记录和签名凭证隔离；缓存配置不能代替这些证据。
• [ ] 验证缓存缺失、恢复被禁用或保存被跳过时，任务能否安全地重新获取依赖或失败；不要让降级路径自动转用高权限凭证。

将结论分为三档，交由平台、安全与研发共同确认：可试点，缓存授权和主机边界均有证据；先整改，缓存模式合理，但 Runner 清理、凭证或工作流权限尚未验证；暂缓放量，低信任任务仍可写入可信工作流会恢复的缓存，或能触达生产签名环境。结论必须基于你们的实际记录，不能仅凭配置文件推定。

如果团队需要新增 Mac CI 节点，先分别评估缓存治理与 Runner 隔离。自购 Mac 更适合长期固定负载、需要物理接口或必须由内部团队完全控制硬件的场景，但采购、维护和环境清理也由团队承担；远程 Mac 可以作为按需配置 CI 环境的候选方式，却不会自动解决缓存投毒或凭证分区。你可以先查阅 Mac mini M4 价格指南，核对自建节点的采购考量；若要评估按需使用的远程节点，再查看 MacDate 计算节点方案。在明确任务信任级别、主机清理责任和签名凭证边界后再决定是否租赁；若你需要长期固定负载、物理接口，或必须由内部团队完全控制硬件，租赁未必合适。