GitHub Actions 怎么下载某次运行的构建产物：Artifacts、保留期与文件核对

CI 跑完以后，真正需要交给测试或发布同事的通常不是整段日志，而是某次运行生成的 ZIP、测试报告或覆盖率文件。GitHub Actions 把这类文件放在 Artifacts 区域；从仓库的 Actions 进入目标运行，再点击对应产物名称即可下载。下面只完成一个任务：下载某次运行的构建产物，并在本地做一次最小核对。

先确认下载对象：Artifacts 不是日志，也不是缓存

GitHub 官方把 artifact 定义为工作流运行产生、需要在 job 结束后继续保存或共享的文件，常见内容包括构建包、测试结果、失败截图和覆盖率报告。日志用于查看执行过程，缓存用于复用不经常变化的依赖，它们都不能替代本次运行的构建产物。本文使用公开的 GitHub Docs 界面说明路径，登录后的仓库页面可能因权限和视图宽度略有差异。

第 1 步：从仓库进入 Actions 运行列表

打开目标仓库，在顶部导航点击 Actions。如果仓库没有启用工作流，页面会先显示工作流启用或创建提示；已有记录时，左侧会列出 workflow，右侧显示最近的运行状态。

可见成功状态：页面出现工作流名称、分支或事件、运行状态以及一串运行记录。这里不要直接点某个 job 的日志下载，构建产物要在具体运行详情里找。

第 2 步：打开包含构建结果的那一次运行

在运行列表中按分支、提交说明和状态找到目标记录，点击运行标题或运行编号进入详情。选择标准很简单：要下载哪个提交产生的包，就打开哪个提交对应的 run；不要只按“最近一次成功”判断。

可见成功状态：页面标题已经切换到具体的一次运行，能看到提交、分支和完成状态。若状态仍为进行中，先等 job 完成；没有完成的运行通常还不会有最终构建产物。

第 3 步：在 Artifacts 区域下载 ZIP

停留在运行详情的总结区域，向下找到 Artifacts。点击与构建任务对应的产物名称，浏览器会下载一个 ZIP 文件；如果同一次运行上传了多个产物，要按名称区分安装包、测试报告或截图包。

可见成功状态：下载列表出现一个以产物名称命名的 ZIP，页面仍能看到该运行的提交和状态。若没有 Artifacts，常见原因是工作流没有使用上传产物的步骤、打开了错误的 run，或文件已经超过保留期。

下载后用三项信息做验收

下载完成后不要只看浏览器提示“已完成”。先记录 ZIP 文件名，再解压查看顶层目录和关键文件；最后回到运行详情核对提交 SHA、运行时间和 Artifacts 名称。三者对不上时，最常见的错误是下载了另一条分支的同名产物。

# macOS / Linux 示例：只做本地内容核对
unzip -l build-artifact.zip
shasum -a 256 build-artifact.zip

这里的命令只读取本地 ZIP，不会改变 GitHub 运行记录。对于发布包，可以把 SHA-256 记录在交接单里；对于测试报告，重点检查报告文件是否存在、时间是否对应目标 run。

常见问题

为什么在 job 日志页面看不到 Artifacts？

Artifacts 属于整个 workflow run 的结果集合，不一定显示在单个 job 的日志页里。返回该次运行的总结页面，在 Artifacts 区域查找。

下载按钮为什么没有了？

先确认运行没有被删除，再检查产物保留期。官方说明日志和产物按保留期保存，超过期限后可能无法继续下载。

Artifacts 和缓存可以互相替代吗？

不能。Artifacts 面向本次运行产生并要交付或查看的文件，缓存面向依赖等可复用内容；两者的生命周期和使用目的不同。

最后确认

完成这项操作的判断标准是：进入了正确仓库和正确 run，Artifacts 区域显示了目标产物，浏览器下载到了 ZIP，并且解压后的关键文件与提交和运行时间相符。少了任何一项，都先回到第 2 步核对运行记录，不要把“能下载”当成“下载对了”。