一句话看懂：GitHub 为 Actions 缓存新增 cache-mode 控制能力，允许在 workflow 或 job 级别精确授予 read、write、write-only、none 四种缓存权限，并已在全平台正式可用。这让 CI/CD 流水线可以按最小权限原则访问缓存，降低缓存投毒风险。
事件核心：发生了什么
根据 GitHub Changelog 2026 年 9 月 10 日的公告，GitHub Actions 现在支持通过 cache-mode 参数，在工作流或作业级别控制缓存访问权限，共四种模式：read 允许恢复缓存但禁止写入，是 pull_request_target 等低信任事件的默认值；write 允许恢复和写入，是 push 等可信事件的默认值；write-only 只允许写入不允许恢复；none 则完全禁止缓存访问。作业级别设置会覆盖工作流级别设置，且该模式由缓存服务强制执行，并会沿可复用工作流传导——被调用工作流拿到的缓存权限不会超过调用方授予的范围。该功能已在 github.com 上对所有 GitHub 计划正式可用。
为什么重要
缓存投毒是 CI/CD 供应链攻击的常见入口：低信任事件若获得写入权，攻击者可能污染缓存，进而影响后续可信工作流的构建产物。cache-mode 把权限从“隐式默认”变成“显式声明”，让安全团队可以在流水线层面对缓存做最小权限约束。公告特别指出，显式声明 cache-mode 会覆盖低信任事件的只读默认值，若为这类事件声明 write 或 write-only，Actions 会附加警告注解，提示缓存投毒风险上升。这种“默认安全 + 显式提示”的设计，与近年软件供应链安全治理的方向一致，对依赖 GitHub Actions 的开源项目和 AI 工程团队都有实际价值。
对用户/开发者/创作者的影响
对普通开发者和 AI 应用团队来说，这项变更不需要立刻改动现有流水线——未设置 cache-mode 的工作流继续沿用现有安全默认值。但如果你的项目涉及 pull_request_target 触发器、外部贡献者提交，或使用可复用工作流，就可以主动在 job 级别声明权限，把只读或禁用缓存的策略固化下来。对于维护开源仓库、模型训练与推理流水线的团队，这意味着可以在不牺牲构建速度的前提下收紧缓存边界。企业 CI/CD 管理员也可借此把缓存权限纳入统一的安全基线检查。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是看 GitHub 是否会在 Actions 的 UI 或安全扫描中，对写入型 cache-mode 给出更显眼的默认告警；二是观察主流 CI 工具如 GitLab CI、CircleCI 是否跟进类似的缓存权限模型；三是留意社区在可复用工作流场景下对权限传导的实际反馈，尤其是多层调用时是否会出现配置复杂度上升的问题。
