GitHub Actions 大型构建存储优化需分三类资源管理：缓存（10 GB/仓库，90天自动过期，禁存dist等产物）、工件（共享50 GB配额，单个≤2 GB，支持跨作业传递）、自定义镜像（独立额度，精简构建以加速启动）；计费按GB-小时累加，须定期清理低效缓存与陈旧工件。
GitHub Actions 处理大型构建任务的存储，核心在于区分三类独立资源：缓存（cache）、工件（artifacts）和自定义镜像，并针对每类设定明确的配额、生命周期与优化策略。大型项目的关键不是“堆空间”，而是“分而治之+按需留存”。
缓存：10 GB/仓库，专用于加速重复构建
每个仓库独享 10 GB 缓存配额，不与工件或 Packages 共享。它只保存中间产物（如 node_modules、~/.m2、Docker 构建缓存），且仅在工作流中显式调用 actions/cache@v5 时才写入。
- 缓存自动过期：90 天未被访问即被系统清理，无需手动干预
- 避免大文件误入：不要把
dist/、build/等完整产物路径设为缓存路径，应拆分为依赖层 + 构建层分别缓存 - 跨平台复用：启用
enableCrossOsArchive: true可让 macOS/Linux 的 npm 缓存共享同一份压缩包，节省空间
工件：共享 50 GB 配额，用于跨作业传递与临时归档
工件（artifacts）与缓存是两套系统。它走的是 GitHub 的 Blob 存储，配额与 GitHub Packages 共享（例如企业版含 50 GB）。适合存放编译产出、测试报告、安装包等需保留数天至数周的成果。
- 上传后立即计入当前存储量，删除后当前值实时下降
- 单个工件上限 2 GB；超大文件建议先压缩再上传，或改用外部对象存储（如 S3）并只传 URL
- 可用
upload-artifact和download-artifact在 job 间高效传递，比反复构建快得多
自定义镜像与大型运行器：单独额度，面向高负载场景
若使用 GitHub 托管的大型运行器（如 large-runner），其预装环境镜像的存储不计入常规配额，而是按套餐提供独立额度。这类镜像适合需要 CUDA、大量内存或特定 SDK 的大型构建任务。
- 镜像构建一次，多工作流复用，避免每次重装工具链
- 镜像大小影响启动时间，建议精简基础层（例如移除调试符号、清理 apt cache）
- 镜像更新需主动触发，不会因缓存键变化而自动刷新
关键提醒：存储计费看“累计用量”，不是峰值
账单依据整月“GB-小时”累加计算。比如你某天用了 30 GB 工件+缓存，持续 2 小时，就记作 60 GB-小时。哪怕第二天全删了，这 60 仍会计入当月总账。因此：
- 定期用
gh cache list和gh run list --limit 10查看低效缓存和陈旧工件 - 对 PR 构建产生的临时工件，建议设置
retention-days: 1 - 用
gh cache delete --key "feature-*"批量清理分支专用缓存
