如何安全删除旧 Xcode Archives，又不丢失崩溃符号
AskClean 团队 · 更新于 2026-07-31
只有在确认某份 Xcode Archive 对应的 App 版本已停止分发、以后也不再需要它的 dSYM 分析崩溃时，才应该删除。最稳妥的办法是在 Xcode Organizer 中逐个检查，保留所有仍在线的 App Store、TestFlight、企业或 Ad Hoc 构建，仅把确定退役的归档移到废纸篓。
为什么 Archives 不能当成 DerivedData 来删
每次执行 Product > Archive，Xcode 都会生成一份用于分发的构建，并保存为 .xcarchive 包。它们默认位于 ~/Library/Developer/Xcode/Archives，按日期分组，同时出现在 Organizer 中。一个长期维护的 App，经过多轮候选版本、TestFlight 和正式发布后，很容易积累几十份归档。
DerivedData 是从源代码重新生成的构建缓存，Archive 却可能保存着那一次发布的精确二进制、构建元数据和 dSYM。Apple 说明，dSYM 通过 UUID 与某个二进制一一对应。以后即使拿同一个 commit 重新构建，新产物也会拥有不同的标识，无法替代原来的符号文件。
所以二者的删除代价完全不同。删 DerivedData，代价只是下次完整编译和重新索引；删错 Archive，则可能永远无法恢复那一版的调试信息。等线上崩溃报告到来时，调用栈里只剩内存地址，无法还原成函数名和源码位置。
删除前，先做一份保留清单
先从 Xcode 入手，不要只看访达里的日期文件夹。打开 Window > Organizer，选择 Archives，再选中对应 App。逐份查看版本号、Build 号、创建时间和分发状态；这些上下文比一个看起来很旧的文件夹名称可靠得多。
先决定什么必须保留，再决定什么可以删除。仍在 App Store 面向用户的版本、仍在测试的 TestFlight 构建、尚未过期的企业或 Ad Hoc 构建，以及仍处于崩溃分析窗口内的历史正式版，都应该保留。如果团队还会重新导出安装包、核对签名或依赖某份已验证的发布产物，也要把它列入保留清单。
不要因为上传成功就默认本地 Archive 没用了。根据平台和上传设置，Apple 可能已经收到符号文件，但 Apple 的调试文档仍建议保留每一份已分发构建的归档。本地 Archive 也是把二进制、dSYM、版本号、Build 号和导出记录连在一起的最清晰凭证。
- 打开 Window > Organizer，进入 Archives。
- 按 App 整理当前正式版、TestFlight、企业和 Ad Hoc 构建的版本号与 Build 号。
- 确认需要上传的符号已经上传；如果团队有归档制度，把不可替代的版本复制到有备份的存储。
- 只把被正式版取代的候选构建、已放弃的内部版本，以及超出崩溃分析周期的退役版本标记为候选。
- 在 Organizer 中逐个删除，重新核对保留项无误后，再考虑清空废纸篓。
不能只按日期决定去留。旧正式版可能在新版本上线很久后，仍安装在部分用户设备上。
先测量，不要一上来就删
如果目标是回收磁盘空间，先量出 Archives 到底占了多少。在访达按 Command-Shift-G，打开 ~/Library/Developer/Xcode/Archives，切到列表视图，在「显示选项」中启用「计算所有大小」，再按大小排序。整个过程只读，不会修改任何文件。
习惯终端的话，可以运行 du -sh ~/Library/Developer/Xcode/Archives 查看总量；用 du -sh ~/Library/Developer/Xcode/Archives/* 查看各日期目录。它们只负责测量，不会删除内容。
.xcarchive 在访达里是一个包。排查体积时，可以对复制出来的归档使用「显示包内容」，但不要从正式归档内部随意抽走文件。一个残缺的 Archive 可能还显示在那里，却已经无法正常导出或进行符号化。
最稳妥的删除流程
首选 Organizer，因为执行删除时，版本号、Build 号和 App 身份都摆在眼前。选中已经确认退役的归档，再使用 Delete。相比在访达里辨认日期文件夹，这一步更不容易删错对象。
只有在 Organizer 无法读取某个很老或已经损坏的包时，才退回访达。找到具体的 .xcarchive，核对 Info.plist 中的版本和构建信息与审核记录一致，然后只把这一份移到废纸篓。不要因为某个日期很早，就整个日期目录删除。
先别急着清空废纸篓。重新打开 Organizer，确认需要的版本仍在；如果符号化对业务很关键，再拿一份代表性崩溃报告做验证。移到废纸篓至少留下了一段恢复窗口，而终端永久删除并不会让判断变得更正确。
建立不会无限增长的归档策略
好的保留规则以发布状态为核心，而不是简单规定「超过 90 天就删」。仍在分发的全部保留；已经下架但仍接收崩溃报告的正式版，在支持周期内保留；企业构建至少保留到安装失效；法律、审计、重大事故复盘要求的里程碑版本按制度长期保存。
团队最好把它写进发布清单：Archive 存在哪里、dSYM 是否已上传、谁有权限取回、什么时候进入可删除状态。如果把归档迁到外置盘或云存储，必须真正测试一次恢复和导出，不能只确认文件「看起来复制成功」。
每个大版本发布结束后做一次十分钟审核，比启动盘爆满时仓促扫荡安全得多。急需空间时，先清 DerivedData 和失效模拟器；等 Mac 恢复足够工作空间，再冷静审查 Archives。
AskClean 如何处理 Xcode Archives
AskClean 不会把 Archives 标成普通的可重建缓存。它会扫描归档目录，逐个列出 .xcarchive，并显示「不可恢复」的代价提示，让你审核某一份旧构建，而不是面对「整个文件夹全删或全留」的粗暴选择。
最终判断仍然属于你。AskClean 可以告诉你哪份归档占空间、把你批准的项目移到废纸篓，但它不可能替你知道产品的线上支持周期，也无法补回已经丢失的 dSYM。这条边界是刻意设计的：清理工具应该揭示发布产物，而不是擅自宣布它已经没用了。
删除边界：哪些能重建，哪些不能
先判断恢复代价，再考虑文件年龄和体积。
| 项目 | 默认位置 | 删除后果 |
|---|---|---|
| DerivedData | ~/Library/Developer/Xcode/DerivedData | 可以从源码重建；下次构建和索引会更慢。 |
| Xcode Archive | ~/Library/Developer/Xcode/Archives | 可能一并删除已保存的二进制、元数据和匹配 dSYM。 |
| 单独导出的 dSYM | 团队的发布产物存储 | 可能是某个已分发二进制仅存的符号文件。 |
| 已退役内部构建 | ~/Library/Developer/Xcode/Archives | 确认不再安装、不再支持后，才适合进入删除候选。 |
常见问题
可以把 ~/Library/Developer/Xcode/Archives 整个删掉吗？
不能把它当成安全的批量操作。归档可能包含线上构建对应的精确二进制和 dSYM。仍在分发、仍在测试或仍可能收到崩溃报告的版本都要保留。
删除本地 Archive 会把 App 从 App Store 下架吗？
不会。删除本地 .xcarchive 不会影响已经上传到 App Store Connect 的版本，也不会删除用户设备上的 App；它删除的是你自己的发布产物和潜在调试依据。
重新构建同一个 commit，能生成一样的 dSYM 吗？
不能把它当成可靠替代。dSYM 必须匹配已分发二进制的 UUID，新构建会产生不同的二进制身份，所以应该保存原始归档或对应符号。
需要空间时，应该先删 Archive 还是 DerivedData？
通常先删 DerivedData。它可以从源代码重建，风险更低；Archive 必须按发布版本逐个审核，删错后可能失去不可恢复的调试证据。
参考来源