GitHub Actions 怎么在界面里查看某次工作流的 artifact

GitHub Actions 的 artifact 不在仓库文件列表里，而是挂在某一次 workflow run 的结果页上。要查看它，先进入仓库的 Actions，选中对应 workflow，再打开具体 run，最后在 Artifacts 区域点击产物名称下载。找不到时，优先检查是不是打开了错误的 run、产物已经过期，或当前账号没有仓库读取权限。

从 Actions 进入某次 workflow run

先打开目标仓库主页，点击顶部的 Actions。左侧会列出仓库中的 workflow，例如持续集成、发布或安全检查流程。先选 workflow，再看右侧运行列表，不要直接凭标题猜最近一次记录，因为同名 workflow 可能由不同分支、提交或事件触发。

1. 在左侧选择要查看的 workflow。
2. 在运行列表中核对 Success、分支名、提交短标识和时间。
3. 点击与需求对应的那一行，进入这次运行的 Summary 页面。

如果你要找的是某次失败构建生成的诊断包，状态不一定是成功；关键是分支、提交和触发时间要与问题现场一致。Artifact 属于这次 run，换到另一行即使名称相同，下载内容也可能完全不同。

在 Artifacts 区域查看并下载

打开具体 run 后，先看页面顶部的运行名称和状态，再向下找到 Artifacts 区域。这里列出的名称来自 workflow 中上传 artifact 时设置的名字；一个 run 可以同时有构建包、测试报告和覆盖率报告等多个产物。

1. 确认页面标题是目标 run，而不是 workflow 总览。
2. 在 Artifacts 区域核对产物名称、大小和可用状态。
3. 点击需要的 artifact 名称，浏览器会下载对应的压缩包。

下载前建议先记下 artifact 名称。需要多个产物时逐项核对，避免把 test-report 当成发布包。GitHub 文档也说明，artifact 是 workflow 运行完成后保存的数据，适合用于调试失败测试、查看覆盖率或交给后续部署环节。

用保留期和权限解释“看不到 artifact”

Artifacts 区域为空，不等于页面坏了。按下面的顺序判断，通常几分钟就能缩小范围：

GitHub 文档给出的默认日志和 artifact 保留期是 90 天，但实际可用时间还受仓库、组织或企业的保留设置影响。workflow 也可以为单个 artifact 设置 retention-days，这个值不能超过上层配置允许的最大值，所以不能仅凭“默认 90 天”判断所有仓库都一样。

常见问题

为什么 Actions 页面有运行记录，却没有 artifact？

运行记录和 artifact 是两件事。只有 workflow 实际执行上传动作并成功写入产物，run summary 才会出现可下载项目；先看上传 job 的日志和路径匹配结果。

artifact 能不能从另一个 workflow run 里直接找？

网页端应先打开 artifact 所属的那次 run。若是工作流内部要跨 run 下载，则需要使用对应的下载动作、run 标识和令牌，不能把当前 run 的名称当作跨 run 定位条件。

下载按钮消失了怎么办？

先确认账号已登录并有仓库读取权限，再检查 artifact 是否已过期。若两项都正常，回到运行列表核对分支、提交和触发时间，很多“消失”其实是打开了另一条运行记录。