企业 Mac CI 构建产物保留多久？2026 策略指南
如果发布归档和日志都跟着 Mac Runner 工作区一起清理，崩溃诊断和审计追溯就可能失去关键证据。本文按故障风险划分 Xcode archive、dSYM、报告、日志、缓存与临时文件，并提供留存责任矩阵和可执行验收清单。
目录
发布后发现崩溃日志无法符号化，或构建记录已被清空？
本周先把数据分成“发布证据”和“可重建数据”：已发布版本的 Xcode archive 与匹配的 dSYM 按诊断和审计需求留存，日志、报告、缓存和临时文件分别设置期限，并把长期资料移出 CI 工作区。
负责 iOS 发布与崩溃诊断的工程负责人，可据此制定 archive 和 dSYM 保存规则。
负责 Mac Runner 存储、缓存和日志治理的平台工程师，可区分必须留存与可以清理的数据。
负责发布审计和数据生命周期的 IT、安全或合规负责人，可将规则落实到责任人、证据位置和恢复验证。
企业 Mac CI 构建产物保留策略，先按丢失后的影响分类
“一刀切”保留期限的问题不只是占用空间：保留太短，可能失去发布后的诊断依据；保留太长，缓存和临时目录会持续积累；把所有内容留在单台 Mac 上，则主机故障、误删或租用周期结束时都可能造成资料断链。另一个常见误区，是把“能从源码重新构建”当成“能还原当时发布的内容”。
Apple 说明，发布归档包含应用二进制和调试信息，并要求保留每个已分发构建对应的 Xcode archive。可参考其关于分发应用与创建 archive 的文档和构建调试信息、保留 archive 的说明。这并不等于所有 CI 文件都要长期留存，而是要求你区分不可替代的发布证据与能够重新生成的数据。
| 产物类别 | 丢失后的主要影响 | 建议治理方向 | 定性评分：留存优先级 |
|---|---|---|---|
| 已发布版本的 Xcode archive | 难以还原当时归档的发布构建，影响诊断与审计 | 与版本、构建标识关联，移出工作区保存 | 高 |
| 匹配的 dSYM | 自有二进制的崩溃栈可能无法充分符号化 | 与对应 archive 或二进制核验 UUID 后一并归档 | 高 |
| 导出文件、签名与发布记录 | 交付内容和审批过程难以追溯 | 按组织流程关联保存，控制访问权限 | 高 |
| 测试报告、构建日志 | 失败原因、测试结果或发布过程证据缺失 | 依据排障、复核和组织政策设置期限 | 中 |
| 依赖缓存、中间产物 | 缓存未命中后需要重新下载或生成 | 验证可重建后设置清理规则 | 低 |
| 临时工作区 | 任务结束后残留文件增加占用与泄露风险 | 明确工作区边界，任务结束后清理 | 低 |
表中的评分是按丢失影响、可重建性和审计作用作出的治理判断，不代表存储平台性能测试。你的团队若承担特定发布审计责任，应先确认适用的内部政策和合同要求；不要把任何 CI 平台的默认期限直接当作通用标准。
archive 与 dSYM 的匹配关系决定崩溃诊断能力
单独保存匹配的 dSYM，在部分场景中仍可用于符号化；但它不能完整替代 Xcode archive。 Apple 指出，二进制和对应 dSYM 必须具有相同的 build UUID；源码相同并不能证明它们相互匹配。不同 Xcode 版本或构建设置也可能生成 UUID 不同的二进制。可查看Apple 关于 dSYM 与 build UUID 的说明和崩溃报告符号化方法。
如果你单独保存了与崩溃版本匹配的 dSYM，且手上有符号化所需的崩溃报告与二进制信息，某些诊断场景仍可能完成符号化；但 Apple 的文档以保留对应 archive 作为可靠做法，缺少 archive 时也可能无法符号化该版本。因而，dSYM 不能被视为 archive 的完整替代品。
核验时，至少要把版本号、构建标识、发布渠道、二进制 UUID、dSYM UUID 和归档位置关联起来。Apple 提供的 dwarfdump --uuid 可用于查看文件 UUID；对照报告中的二进制信息，确认 UUID 一致后，再将核验结果记入发布记录。
发布证据离开 Mac 工作区，责任链才算完整
只把文件从 Runner 目录复制走，还不等于建立了可恢复的归档。你还需要明确文件去哪里、谁能读取或删除、谁负责恢复演练，以及什么事件会触发复核。具体存储系统可以不同，关键是不能让唯一副本只留在一台可能重装、损坏或退出服务的 Mac 上。
建议把发布关联资料整理成一个逻辑记录，而不是把所有内容强行塞进同一文件夹：归档标识与版本信息指向 Xcode archive、匹配的 dSYM、交付文件和必要发布记录；测试报告与日志则按流水线运行标识关联。这样发生故障时，你可以先找回目标版本的证据，而不是依赖某位工程师记得当时把文件放在哪里。
如果构建节点需要临时扩容或交接，你也可以先了解 VPSMAC 的 Mac 节点选择信息，再核实所需资料如何转移和恢复。节点可用性并不能替代独立的归档、权限记录或恢复验证。
日志、报告和缓存不要共用一条清理规则
测试报告用于确认测试结果，构建日志用于排查失败，缓存用于减少重复下载或重建；用途不同，留存理由就不同。GitHub 的官方文档将缓存和 workflow artifacts 区分为不同用途：缓存是为了复用可重新生成的文件，artifacts 则用于保存构建输出或日志等任务产物。你可以查看缓存与产物的用途区别；清缓存后工作流应能重新构建或下载依赖，发布证据则不能仅凭“重新跑一次”保证完全复原。
平台提供的过期设置也有适用范围。以官方文档为例，GitHub Actions 支持在仓库、组织等层级调整日志与产物留存，且单项产物可配置自己的留存期限；私有仓库可设的范围为 1 至 400 天，公开仓库为 1 至 90 天。这些是特定平台设置，不是企业应该采用的保留时长；设置调整也不一定会追溯修改既有对象。具体边界见组织层级的日志与产物留存文档及单项 workflow artifact 的留存设置。
另一个容易忽略的细节是：不同 CI 平台对于默认过期、单项设置和“保留最新成功构建”的行为并不相同。例如，相关平台文档说明，产物过期规则可能受实例默认设置影响，最新成功流水线的产物也可能被额外保留；另有平台提供项目层级的留存策略，并将日志、二进制、测试结果等一起纳入运行清理。查看产物过期与最新流水线保留规则和流水线运行及测试数据留存设置，上线清理任务前先验证当前配置的生效范围。
⚠️ 缓存不是发布证据的廉价备份。若清理后无法从锁定版本和可信来源重新取得依赖，先记录这个恢复依赖并验证替代路径，再启用自动过期。
缓存治理也不只是定期删文件：按目录或缓存键标明归属，记录最后使用情况，并验证删除后构建能够正常重新下载或生成。平台官方资料还说明，缓存可能依据未使用时间和存储限额被清理；可参考缓存的命中、限制与清理机制。因此，缓存策略应关注重建成本和清理可追溯性，而不是把缓存与 archive 放入同一个保留组。
按恢复风险确定期限，并指定责任人
你不必先拍板一个全公司通用的天数。先分别回答：崩溃诊断需要追溯到什么范围，发布复核需要哪些材料，资料是否受合同或内部数据政策约束，文件删除后是否能从可信来源重新生成。再将答案转成规则，并检查平台实际设置与规则是否一致。
| 资料 | 决策依据 | 责任人 | 必须留下的证据 |
|---|---|---|---|
| 已发布 archive 与匹配 dSYM | 崩溃诊断、版本恢复及发布审计需求 | iOS 发布负责人 | 版本与构建标识、UUID 核验结果、保存位置 |
| 导出文件与发布记录 | 交付复核和审批追溯需求 | 发布或平台负责人 | 关联的发布记录、访问与删除责任 |
| 日志与测试报告 | 故障复盘、质量追溯和组织政策 | CI 平台负责人 | 适用期限、过期配置、生效范围 |
| 缓存与临时工作区 | 重建成本、最近使用情况与存储治理 | Mac Runner 管理者 | 归属规则、清理记录、重建验证 |
| 需要长期保存的资料 | 组织的诊断、审计、合同和数据治理要求 | IT、安全或合规负责人 | 政策依据、复核条件、恢复验证记录 |
用验收清单验证误删后的恢复能力
先选取一个已发布版本做抽查，再检查权限、过期行为和独立恢复。以下清单应由资料所有者与 CI 管理者共同确认，而不是只由执行清理脚本的人自证。
- [ ] 抽查一个已发布版本，找回对应的 Xcode archive，并核对版本、构建标识和匹配 dSYM。
- [ ] 使用
dwarfdump --uuid对照对应二进制与 dSYM；不匹配时，不把这组文件标记为可用于该版本诊断。 - [ ] 记录 archive、dSYM、导出文件和必要发布记录的保存位置、读取权限、删除权限及责任人。
- [ ] 分别核对日志、测试报告、缓存和临时工作区的过期规则，确认平台默认值、单项配置与组织要求没有冲突。
- [ ] 从独立于临时工作区的保存位置恢复必要发布文件，并记录恢复结果和失败项。
- [ ] 验证清理操作留下审计记录；若发布资料仍只有 Mac 工作区内的单一副本，暂停自动清理并先补齐恢复路径。
VPSMAC 提供的远程 Mac 可作为按需补充的构建节点，但租用节点本身不会自动替你保存发布证据。若当前方案依赖单台自购 Mac 的本地目录，可能受硬件故障、人员交接和单点存储约束；若依赖 CI 工作区自动过期，可能把可清理的日志、缓存与不可替代的发布资料一并删掉。先用清单核对交接与恢复路径；只有当你需要弹性 Mac 构建资源时，再评估 VPSMAC 的远程 Mac 方案是否适合你的节点规划。