Xcode Archives 可以删吗？安全清理旧构建，保留 dSYM

为什么 Archives 不能当成 DerivedData 来删

归档是执行 Product > Archive 的结果：一份用于分发的构建，保存为 .xcarchive 包。Xcode 默认把这些包存放在 ~/Library/Developer/Xcode/Archives，按日期分文件夹，并在 Organizer 中显示。一个长期维护的 App，经过多轮候选版本、TestFlight 上传和正式发布后，很容易积累一大批归档。

DerivedData 只是加速构建的缓存，归档却不是。它可能保存着那一次构建的精确二进制文件、构建元数据和 dSYM 文件。Apple 说明，dSYM 通过 UUID 与某个二进制文件一一对应。以后即使用同一份源代码重新构建，新的二进制文件也会得到不同的标识，生成的符号文件无法替代原来那份。

这一区别决定了清理规则。删除 DerivedData，代价只是下一次构建更慢；删错归档，那一版可能再也无法原样重建。如果之后收到该二进制文件的崩溃报告，而你手里已经没有与之匹配的符号，调用栈就只剩内存地址，看不到有用的函数名和源代码位置。

删除前，先做一份保留清单

先从 Xcode 入手，而不是访达。打开 Window > Organizer，选择 Archives，再选中对应的 App，逐份查看版本号、构建号、创建日期和分发状态。Organizer 提供的这些上下文，是一个带日期的文件夹名给不了的。

先列保留清单，再列删除清单。当前仍向用户提供的每个版本、仍在使用的每个 TestFlight 构建、仍有设备安装着的企业或 Ad Hoc 构建，以及崩溃报告可能还要调查的每个版本，其归档都要保留。如果团队依赖某个已验证正式版的导出安装包、公证记录或签名凭证，也要把它留下。

不要以为上传成功了，本地归档就没用了。视平台和上传设置而定，Apple 可能已经收到了符号文件，但 Apple 的调试文档仍建议为分发的每一个构建保留归档。本地归档也是把二进制文件、dSYM、版本号、构建号和导出记录对应起来的最清楚的凭据。

1. 打开 Window > Organizer，选择 Archives。
2. 选中 App，记下仍在使用的每个正式版、TestFlight、企业或 Ad Hoc 构建的版本号和构建号。
3. 确认需要上传的符号已经上传；如果团队的保留制度有要求，把不可替代的归档复制到有备份的存储位置。
4. 只把已被取代的候选构建、已放弃的内部构建，以及超出崩溃调查期限的退役版本标记为删除候选。
5. 在 Organizer 中逐个删除候选项，确认应保留的条目都还在之后，再清倒废纸篓。

只看日期不是安全的保留策略。新版本上线很久之后，旧的正式版仍可能安装在部分用户的设备上。

先测量归档文件夹，不做任何改动

如果目标是腾出磁盘空间，先测量。在访达中按 Command-Shift-G，打开 ~/Library/Developer/Xcode/Archives，切换到列表视图，在“显示选项”中勾选“计算所有大小”，再按大小排序。整个过程只读，体积异常大的归档会一目了然。

习惯用终端的话，可以运行 du -sh ~/Library/Developer/Xcode/Archives 查看总量；想查看各个日期文件夹，就运行 du -sh ~/Library/Developer/Xcode/Archives/*，再自行排序输出。这些命令只测量文件，不会删除任何内容。

归档是一个包，访达通常把它显示为单个项目。排查体积时，可以对复制出来的归档右键选择“显示包内容”，但不要改动正式归档包里的文件。删掉其中某些文件后，归档看起来还在，却可能已经无法正常导出或进行符号化。

最稳妥的删除流程

首选在 Organizer 中删除，因为执行操作时，App 身份、版本号和构建号都摆在眼前。选中已确认退役的归档，使用 Delete。Xcode 会移除这个归档包；视 macOS 和 Xcode 的行为而定，可能会要求你确认这一操作。

只有当 Organizer 打不开某个很旧或已损坏的包时，才改用访达。进入 Archives 目录，核对 .xcarchive 中 Info.plist 的元数据与你的审核记录是否一致，确认无误后，只把这一个包移到废纸篓。不要因为某个日期文件夹的名字很旧，就把整个文件夹删掉。

先别清倒废纸篓：重新打开 Organizer，导出工作流程仍然需要的构建；如果符号对业务至关重要，再拿一份有代表性的崩溃报告做一次符号化验证。移到废纸篓会留下一段短暂的恢复窗口；在终端里永久删除只会去掉这层保险，并不会让清理变得更正确。

建立不会无限增长的归档保留策略

实用的保留策略以发布状态为依据，而不是随意规定一个文件年龄（比如“超过 90 天就删”）。当前仍在分发的构建全部保留；最近被新版本取代、但仍在接收崩溃报告期限内的正式版，在这段期间内保留；企业构建保留到其安装失效为止；法律、客户支持或事故响应制度要求的里程碑版本，按制度保存。

对团队来说，最好把保留规则明确写进发布清单：归档存放在哪里、dSYM 是否已经上传、谁能取回、什么时候进入可删除状态。如果把归档迁到外置存储或云端备份，要实际测试一次恢复，不能想当然地认为复制过去的包就能用。

每个大版本周期结束后回头检查一次。每季度花十分钟审核，比启动磁盘告急时仓促删除安全得多。急需空间、又想把风险降到最低时，先清理 DerivedData 和过时的模拟器数据；等 Mac 有了足够的工作空间，再从容地审核归档。

AskClean 如何处理 Xcode Archives

AskClean 有意不把 Xcode Archives 标为普通的可重建缓存。它会扫描 Archives 目录，逐个列出 .xcarchive 包，并标注“删除后不可恢复”的代价警告，让你能逐份审核旧构建，而不是面对“整个文件夹要么全删、要么全留”的选择。

最终决定权在你。AskClean 能告诉你哪份归档占了空间，也能把你批准删除的归档永久删除，但它不知道你的线上支持期有多长，也补不回丢失的 dSYM。这条边界是刻意划定的：存储清理工具应该把发布产物摆到你面前，而不是擅自认定它们已经没用了。

删除归档的边界

先按恢复代价给产物分类，再看它的年龄和体积。

常见问题