给 GitHub Actions 提速前，我会先把缓存和产物保留策略分开
很多个人项目的 CI 变慢，常见原因是重复下载依赖、重复生成中间文件，还把构建包、覆盖率报告和调试日志长期堆在产物里。GitHub Actions 已经给了两套官方能力：actions/cache 负责跨运行复用依赖或构建缓存，upload-artifact 负责在本次运行结束后保存结果。把边界分清楚，CI 才会更快，也更容易排查。
原创示意图：从锁文件指纹、缓存恢复、依赖补装、构建测试到短周期产物保留的 CI 数据流。 来源：Codex image generation
先定缓存边界
GitHub 的依赖缓存文档说明，cache action 会先按 key 查找精确匹配，找不到时再查部分匹配和 restore-keys。如果缓存未命中，且任务最后成功完成，新的缓存会按当前 key 创建。这里有两个工程结论：缓存内容不能原地修改，依赖变化时要生成新 key；key 应该绑定操作系统、包管理器和锁文件 hash，避免不同环境误用同一份缓存。
我通常会把 npm、pnpm、pip、Gradle 这类包管理器缓存放进 cache，把 dist、覆盖率 HTML、截图和测试报告交给 artifact。缓存路径里不要放 token、登录态或内部配置。官方文档也提醒，能读仓库的人可能通过 Pull Request 访问基础分支缓存，所以缓存只适合放可再生成、低敏感度的文件。
再收紧产物保留
产物的目标是留证据和传递结果。GitHub 的 artifact 教程说明，upload-artifact 可以上传单个文件、目录、多个路径，也可以用通配符排除文件；每个产物可以设置 retention-days，但不能超过仓库、组织或企业配置的上限。对日常 CI，我会把覆盖率报告、失败截图和构建包分开命名，普通分支保留 3 到 7 天，发布分支再按团队合规要求延长。
更细一点，upload-artifact 会返回 digest。后续下载时，下载动作会校验摘要，不一致会在 UI 和日志里显示警告。这个细节适合多 job 工作流：构建 job 产出包，测试或部署 job 下载同名产物，结果可以追溯。
我会采用的默认规则
第一，缓存 key 用锁文件 hash 做主键，并带上 runner OS 与包管理器名称。第二，只缓存依赖下载目录或编译缓存，不缓存最终发布物。第三，产物按用途拆分命名，例如 coverage-report、e2e-screenshots、web-dist。第四，给临时调试产物设置较短 retention-days。第五，把 cache hit、安装耗时和产物大小写进 job summary，下一次优化时能直接看数据。
这套规则的收益来自更清楚的 CI 数据生命周期，和 workflow 复杂度无关。缓存服务于下一次运行，产物服务于本次运行后的下载、审查和传递。边界清晰以后，个人项目能更快得到反馈，小团队也能少花时间清理无用产物和解释缓存误命中。
主要来源
GitHub Docs: Dependency caching reference