如果你每天都在 Mac 上构建应用，DerivedData 迟早会变成那种你知道很重要、但也希望有人已经帮你清理过的文件夹。
然后有一天文件夹变得巨大，磁盘空间紧张，Xcode 感觉比平时更沉重，清理的问题立刻变得迫切：能安全删除吗，还是你即将把整个工作日变成一场重建灾难？
简短的回答是，DerivedData 通常是 Xcode 清理目标中较安全的一个。更长的回答是，开发者经常过度关注 DerivedData，而忽略了就在旁边的 Apple 生态系统占用的其余空间。
快速回答
DerivedData是 Xcode 生成的构建和索引输出。- 它通常比许多其他开发者文件夹更安全删除，因为 Xcode 可以重新生成。
- 代价是时间：清理后构建更慢、重新索引以及更重的模拟器或预览启动。
DerivedData不是 Apple 开发者占用的全部。Archives、CoreSimulator和iOS DeviceSupport经常在旁边增长。- 如果只有几个过时项目很大，选择性清理通常比全量清理更好。
- 开发者清理应该是生态系统感知和风险感知的，而不是"删除你能找到的最大文件夹"。
哪些通常可以安全清理，哪些需要谨慎
通常首先安全
生成的输出DerivedData 和缓存类的 Apple 开发者产物通常是首先检查的目标，因为它们设计为可重新生成。
Caution 配置文件
状态和交付物Archives、CoreSimulator 和 iOS DeviceSupport 可能保存着你仍然需要的制品、运行时或模拟器状态。
预期的重建开销
主要代价清理后的正常开销是更慢的构建、重新索引和更重的模拟器或预览启动，而非永久的项目数据丢失。
Xcode DerivedData 实际上是什么
DerivedData 是 Xcode 为开发工作流程存储生成的构建输出和相关工作数据的位置。实际上，这通常意味着构建产物、索引、中间文件、与预览相关的输出和其他生成的制品，帮助 Xcode 在下次构建或打开项目时更快。
这就是为什么这个文件夹增长得如此容易。每个项目、目标、分支、SDK 组合和模拟器工作流程都会随时间添加更多生成状态。
这也解释了为什么开发者对待 DerivedData 的态度不同于普通项目文件：
- 它不是应用代码的真实来源；
- 它的存在是为了节省构建和索引时间；
- 它预期会在需要时重新生成。
这种重新生成行为是 DerivedData 通常被归类为比许多应用自有或系统自有路径更安全的清理目标的原因。
为什么 Xcode DerivedData 会变得这么大
最简单的答案是累积。
一个活跃的应用已经可以生成大量构建输出。多个应用、多个分支、预览、模拟器运行、测试构建和包解析历史可以将文件夹推到远超大多数开发者预期的水平。
DerivedData 膨胀的常见原因：
- 多个活跃项目共享同一台机器；
- 过时的每个项目的文件夹在项目不再重要后仍然长期保留；
- 预览、索引和模拟器密集型的工作产生额外的运转；
- 长期存在的 Xcode 环境比你想象的更久地保留旧构建输出；
- 你清理了其他东西但从未触及生成的 Apple 开发者产物。
重要的一点是，大型 DerivedData 在开发者 Mac 上并不罕见。只有当你假设正确的答案总是”现在删除一切”而不检查还有什么很大以及时机是否合适时，它才成为问题。
DerivedData 附近还有什么通常也会变得很大
开发者经常将矛头指向 DerivedData，因为它很熟悉，但它只是 Apple 生态系统占用空间中的一个配置文件。
StorageRadar 当前的 Apple 侧开发者配置文件将这些 Xcode 相邻区域分开，因为它们不共享相同的风险模型：
| 配置文件 | 典型路径 | 增长原因 | 风险配置 |
|---|---|---|---|
| Xcode DerivedData | ~/Library/Developer/Xcode/DerivedData | 构建产物、索引、中间文件、生成的项目输出 | Safe |
| Xcode Archives | ~/Library/Developer/Xcode/Archives | 分发归档和导出的构建历史 | Caution |
| CoreSimulator Data | ~/Library/Developer/CoreSimulator | 已安装的运行时、模拟器状态、模拟器内的应用数据 | Caution |
| iOS DeviceSupport | ~/Library/Developer/Xcode/iOS DeviceSupport | 已连接 iOS 版本的设备支持资产 | Caution |
| SwiftPM Cache | ~/Library/Caches/org.swift.swiftpm | 包管理器缓存数据 | Safe |
这就是为什么一个完整的 Developer Folder 扫描比只盯着一个目录更有用。如果 DerivedData 是 12 GB，但 CoreSimulator 是 35 GB，Archives 是 18 GB，清理计划就完全不同了。
经常与 DerivedData 一起增长的 Apple 开发者文件夹
Archives
Archives 不只是生成的临时空间。它们可能代表你可能确实想保留的交付物。这就是为什么它们属于与 DerivedData 不同的清理类别。
CoreSimulator
模拟器数据可能会悄悄超过 DerivedData，尤其是在你跨多个运行时测试或长期保留模拟器状态的情况下。它不只是一个可丢弃的缓存文件夹。它可能包含你仍然关心的模拟器环境。
如果模拟器存储才是真正的问题，专注的指南 Xcode 模拟器占用 Mac 空间？应该先清理什么 更深入地讨论了运行时、设备状态和清理权衡。
iOS DeviceSupport
这个区域随着不同物理设备版本和支持资产的累积而增长。它经常被忽视，因为它不如 DerivedData 那么出名，但仍然大到值得关注。
与包相关的缓存
这些可能比模拟器或归档数据更安全地清理，但它们仍然与 DerivedData 不同。如果你在认真追踪可回收空间，把每个配置文件当作独立的清理问题来处理。
什么时候选择性清理比全量删除更好
开发者的默认反射通常是全量清理：删除整个文件夹，让 Xcode 重建，继续前进。
这可以没问题，但不总是最好的选择。
选择性清理通常在以下情况更好：
- 只有几个旧项目占用了大部分空间；
- 你需要为当前活跃应用提供快速、可预测的构建；
- 你不想今天就强制对所有内容进行完整重建索引；
- 你怀疑过时的分支或已退役的工作空间才是真正的问题，而不是当前项目。
全量清理在以下情况更合理：
- 整个文件夹在许多旧项目中都膨胀了；
- 你想要一个干净的重置生成的输出；
- 当前的减速值得换一个可控的重建窗口；
- 你怀疑全局生成的状态是问题的一部分。
这实际上是一个披着存储决策外衣的时机决策。节省的空间可能相似，但工作流程成本不同。
开发者清理规则：先删除最确定的过期内容。如果几个过时的项目文件夹解释了大部分空间，选择性清理通常比全量重置更好。
如何清理 Xcode DerivedData 而不造成重建混乱
安全的目标不仅仅是”释放空间”。安全的目标是”释放正确的空间，同时让接下来几小时的开发保持可预测”。
1. 先检查整个开发者全貌
从 Developer Folder 开始（如果有的话），而不是孤立地从 DerivedData 开始。关键是看 Xcode 输出是否真的是主要问题，还是其他 Apple 开发者配置文件更大。
如果更广泛的开发者占用空间才是问题，只清理 DerivedData 回收的可能比你预期的少。
2. 将安全生成输出与 Caution 配置文件分开
这个区别很重要：
DerivedData和缓存通常是 Safe 类的清理目标，因为它们是生成的；Archives、CoreSimulator和iOS DeviceSupport需要更多谨慎，因为它们可能保存着你仍然需要的制品、运行时或状态。
一旦你把这些混在一起，“开发者清理”就变成了又一次危险的文件夹清除。
3. 有目的地在选择性清理和全量清理之间做决定
在删除任何内容之前，回答这些问题：
- 最大的
DerivedData目录是与过时项目还是活跃项目关联的？ - 你今天需要快速构建和索引吗？
- 相邻的配置文件实际上比
DerivedData更大吗？ - 完整重建窗口会损害你当前的冲刺、演示或发布工作吗？
这个简短的检查可以防止大多数不必要的全量清理。
4. 预期重建成本，而非数据丢失
对于 DerivedData，清理的正常成本通常是：
- 下一次构建更慢；
- 索引重建；
- 更重的预览或模拟器启动；
- 在生成输出恢复期间的临时摩擦。
这与删除你可能仍需要的应用支持数据、归档或你关心的模拟器状态非常不同。开发者清理只有在你保持这些类别分开时才保持安全。
5. 使用开发者清理工作流程，而非普通文件删除
普通文件浏览器可以告诉你某个东西很大。它无法告诉你该路径是否是已知的开发者配置文件、是否属于 Safe 或 Caution 类别、可能的后果是什么，或者在清理之前是否需要引导预检。
这种缺失的上下文就是为什么开发者清理不应该在风险上升时退化为普通的”最大文件”清理。
为什么 Xcode 清理不同于普通文件清理
普通文件清理问一个简单的问题：什么很大？
如果你需要跨 Xcode、Docker、SDK 密集型设置和开发者风险配置的更广泛指南，请阅读如何在 Mac 上安全清理开发者缓存。
开发者清理需要问更难的问题：
- 这是生成的还是用户编写的；
- 这个配置文件是
Safe、Caution还是Dangerous； - 在信任可回收空间之前是否需要
Dry Run； - 是否需要
Guided Preflight，因为该配置文件有工作流程风险； - 应该先检查哪些阻碍、警告或后果？
这个区别内置于 StorageRadar 的 Dev Cleanup 模型中。它不是任意删除。它基于已知的开发者配置文件和风险策略工作。
例如，当前的 Apple 开发者配置文件划分如下：
Xcode DerivedData为Safe；Xcode Archives为Caution；CoreSimulator Data为Caution；iOS DeviceSupport为Caution；SwiftPM Cache为Safe。
这是清理混乱的对立面。它是一个生态系统感知的工作流程，将生成的缓存与保留的制品和模拟器状态区别对待。
StorageRadar 适合在哪里
这改变了实际的工作流程：
- 当整个 Apple 开发者区域可能膨胀时，使用
Developer Folder； - 当你想要配置文件感知的清理而非普通文件删除时，使用
Dev Cleanup； - 将
Safe配置文件（如DerivedData）与Caution配置文件（如Archives和模拟器相关存储）分开。
这种区别是开发者机器的全部价值所在。产品不仅告诉你某个文件夹很大。它告诉你这是什么类型的开发者存储，以及它应该得到什么样的清理流程。
在删除错误的 Xcode 文件夹之前先检查开发者占用空间。
查看 Dev Cleanup不应该做的事情
避免以下常见错误：
- 不要假设
DerivedData是唯一值得检查的 Xcode 文件夹； - 不要把
Archives、CoreSimulator和iOS DeviceSupport当成具有相同风险配置来删除； - 不要在截止日期之前做全量重置，如果重建时间很重要；
- 不要仅用最大文件逻辑来处理需要生态系统上下文的开发者产物；
- 不要将生成的构建输出与项目数据、交付物或保留的模拟器状态混淆。
如果 Apple 开发者产物也让 System Data 看起来异常大，配套指南 Mac System Data 为什么这么大 是下一步应该阅读的内容。
总结
如果 DerivedData 在你的 Mac 上占用了太多空间，令人欣慰的是它通常是 Xcode 清理目标中较安全的一个，因为它是生成的输出。不太明显的是，DerivedData 很少是全部故事。
最好的清理决策来自于检查更广泛的开发者占用、将安全配置文件与谨慎配置文件分开，并根据你当前的工作流程而非恐慌来选择选择性清理还是全量清理。
常见问题
可以在 Mac 上删除 Xcode DerivedData 吗？
大多数情况下可以。DerivedData 是生成的构建和索引输出，Xcode 可以重新生成。代价是清理后会出现更慢的构建、重新索引以及更重的模拟器或预览启动。
为什么 Xcode DerivedData 会变得这么大？
它变大是因为 Xcode 在多个项目、分支、SDK 和模拟器组合中累积了构建产物、索引、中间文件、预览和项目特定的生成输出。
DerivedData 附近还有什么通常也会变得很大？
常见的相邻 Xcode 存储占用包括 Archives、CoreSimulator 数据、iOS DeviceSupport，以及有时与包相关的缓存。如果清理 DerivedData 后可用空间几乎没有变化，这些是接下来应该检查的地方。
应该删除所有 DerivedData 还是只删除部分项目？
取决于你的工作流程。如果只有几个旧项目是过时的，选择性清理通常更好，因为它保留了活跃工作的构建速度。当整个文件夹膨胀或损坏时，全量清理更有意义。
Dev Cleanup 与普通文件清理有什么区别？
Dev Cleanup 使用已知的生态系统配置文件、风险标签、Dry Run 和用于高风险路径的 Guided Preflight。普通文件清理只能告诉你文件很大，不提供开发者特定的上下文或工作流程检查。
DerivedData 与 Archives 或模拟器数据是一回事吗？
不是。DerivedData 通常是生成的构建输出，更安全地删除。Archives、CoreSimulator 数据和 iOS DeviceSupport 有不同的风险特征，因为它们可能保存着你仍然需要的交付物、设备支持资产或模拟器状态。