Xcode 占满磁盘怎么办：DerivedData、DeviceSupport 与模拟器清理清单

先画出 Xcode 的四层存储图

Xcode 空间问题难处理，通常不是因为某一个目录名字难懂，而是因为多个生命周期不同的目录都集中在 ~/Library/Developer 下。DerivedData 随项目和构建配置增长；DeviceSupport 随连接过的真实设备系统版本增长；CoreSimulator 随运行时、虚拟设备和 App 数据增长；Archives 与 dSYM 则可能承担发布、崩溃符号化和重新导出的责任。它们共享父目录，却不能共享风险等级。

示例电脑当前使用 Xcode 27.2，活动开发目录是 /Applications/Xcode.app/Contents/Developer。当前 simctl 列表中既有 iOS 27.0、watchOS 26.5 的已关闭（Shutdown）设备，也有来自 iOS 26.4、26.5 的 unavailable 设备。这说明“已关闭”和“不可用”是两回事：已关闭的设备可能仍保存着测试数据，不可用的设备通常是因为对应的运行时已经不在了。清理时必须区分这两种状态。

在访达中按 Command-Shift-G 输入 ~/Library/Developer/Xcode，可以看到主要目录；在终端中用 du -sh 只做测量，先不要删除。推荐把结果保存为一份文本记录，至少包括路径、大小、最近修改时间、最近使用的项目和预计恢复方式。对发布符号还要记录版本号、构建号、UUID 和远端上传状态。

1. 退出 Xcode、模拟器（Simulator）和正在运行的 xcodebuild，等待进行中的编译任务结束。
2. 执行 du -sh ~/Library/Developer/Xcode/* 和 du -sh ~/Library/Developer/CoreSimulator，记录每类大小。
3. 执行 xcrun simctl list devices，分别列出 unavailable 的设备、已关闭但仍有用途的设备，以及长期未使用的设备。
4. 先处理可重建产物，再处理可重新下载的支持文件，最后才讨论 Archives、dSYM 与符号备份。

不要因为某个目录名带有 Cache、Products 或 Support 就直接判定它可以删除。先确认它服务的是构建、调试、模拟器还是发布。

DerivedData：最适合按项目清理

DerivedData 通常是 Xcode 清理中最容易解释的一类。它包含构建中间文件、最终产物、索引、模块缓存和日志，内容可以由源码、项目设置、依赖与 SDK 重新生成。清理不会删除项目目录里的 Swift 源文件、资源、Package.swift 或 Git 历史，但会让相关项目下一次编译和索引耗时增加。

如果当前只是一个 scheme 的产物不一致，先用 Product > Clean Build Folder。它的范围窄，只处理正在使用的项目配置；如果现象是跳转到定义失灵、修复后的代码仍显示错误、模块缓存与当前 SDK 不匹配，才删除该项目在 DerivedData 下的文件夹。删除整个 DerivedData 根目录会影响机器上的所有项目，只有在多个项目都出现索引或模块缓存问题时才值得考虑。

示例电脑的 DerivedData 约 19 GB。空间紧张时，先按目录大小和修改时间排序，通常可以找到已经不再维护的旧分支、临时 demo 或一次性验收项目。活跃项目的缓存不一定应该删除：如果它每天都要完整构建，保留热索引可能比回收几百 MB 更有价值。用项目使用频率而非目录名称决定优先级。

在访达中移到废纸篓更便于复核。若使用终端，路径必须来自刚才的测量结果，并在执行删除前再打印确认一次；不要写带有通配符的 rm -rf ~/Library/Developer/Xcode/DerivedData/*。清理后打开主要项目，等待索引结束并运行一次相关测试，确认回收的空间没有换来新的工具链问题。

DeviceSupport：43 GB 不代表都能直接删

iOS DeviceSupport 让 Xcode 能够调试连接的真实 iPhone 或 iPad。它保存与操作系统版本和构建相关的支持文件，通常按版本或设备系统标识分目录。一个开发者如果多年连接不同测试设备，就可能保留当前测试矩阵以外的大量旧版本。它不是模拟器运行时，不是 App 的归档（Archive），也不是某个已分发 App 的 dSYM。

示例电脑的该目录约 43 GB，是 Xcode 空间中最大的单一类别。正确的处理方式是建立“当前设备和近期发布版本清单”：保留当前手上设备的系统版本、团队仍在回归的最低支持版本，以及正在调查崩溃的版本；对长时间没有连接过、也不在测试矩阵中的旧版本标记为候选。删除后重新连接相应系统的设备时，Xcode 可能再次准备或下载支持文件。

检查时不要只凭文件夹名字猜版本，先在 Xcode、访达或设备信息中查看当前连接设备的系统版本。若项目依赖某个旧系统复现问题，保留它；若只是因为过去短暂连接过一部测试机而留下，才考虑移到废纸篓。清理一批后重新测量，再决定是否继续。不要用 sudo 扩大权限，也不要删除整个 iOS DeviceSupport 根目录来追求“一次清完”。

macOS DeviceSupport、DeveloperDiskImages 和 CoreDevice 也可能出现在同一父目录附近。它们服务的设备类型和调试流程各不相同。相关指南可以互相参照，但清理方法不能混用；先判断目录的实际用途，再按当前 Xcode 版本的官方说明操作。

删除 DeviceSupport，本质上是用以后调试时的等待时间换取现在的本地空间。删除之前，先确认你能接受重新准备设备支持文件所需的网络和时间成本。

模拟器：区分运行时、设备和 App 数据

CoreSimulator 至少包含三种东西：系统运行时、由运行时创建的虚拟设备，以及设备内部的 App 数据。一个运行时可能占用好几个 GB，虚拟设备则包含安装的 App、数据库、截图、录屏和测试状态。删除某台设备不会自动卸载运行时；卸载运行时则可能让仍在使用它的设备变成 unavailable。

示例电脑的 CoreSimulator/Devices 约 5.1 GB，simctl 列表显示有 iOS 27.0 和 watchOS 26.5 的已关闭设备，以及运行时已缺失的 unavailable 设备。可以先运行 xcrun simctl delete unavailable，删除所有被标记为 unavailable 的设备——设备里的 App 和测试数据会一起删除，也不会进入废纸篓；执行前要确认其中没有需要的数据，也没有脚本、测试文档或团队协作流程依赖这些设备的 UUID。仍需用来复现问题的设备，不要因为状态是 Shutdown 就删除。

旧运行时应通过 Xcode 的 Settings > Components（Xcode 14–15 中叫 Platforms）检查和卸载，或使用当前 Xcode 支持的组件管理方式。不要手工删除 CoreSimulator 的系统目录来绕过组件管理，因为运行时索引可能残留，之后会出现设备创建失败或 Xcode 反复下载。测试矩阵只需要 iOS 27.0 时，不必长期保存每一个历史版本；但发布前仍要保留团队明确要求的最低系统版本。

如果模拟器数据本身比运行时还大，优先删除不再使用的虚拟设备或在设备内清理测试数据库和录屏。对于需要保留的测试状态，先导出数据或记录复现步骤。模拟器清理后，第一次启动会重新创建容器，慢一点是正常的；只要测试矩阵和 App 安装流程仍然可用，空间就回收到了正确的位置。

Archives、dSYM 与符号备份必须先保护

示例电脑的 Archives 约 405 MB，看起来不大，却可能包含重新导出、审查和崩溃分析需要的证据。符号备份目录约 3.9 GB，另一份符号备份约 731 MB，这些目录可能按构建 UUID 保存 dSYM、源码快照或上传记录。它们不是 DerivedData 的替代名，也不能因为最近没有打开就当成普通缓存。

删除前先回答三个问题：这个构建是否已经分发给用户？对应 dSYM 是否已经上传到崩溃监控平台？外部备份是否能按 UUID 找回完整的 dSYM？只有三个问题都有明确答案，才把旧符号移到加密外置盘或受控归档。对于正在调查的线上版本，宁可先压缩归档，也不要在磁盘告急时永久删除。

Xcode Organizer 中的 Archives 可以按版本、构建号和日期筛选。保留当前发布候选、仍在支持期内的版本和最近一次可重现问题的构建，其他归档先导出清单再处理。清理完后用实际的崩溃事件做一次符号化验证；“文件已上传”不等于上传内容完整，也不等于本地审计要求已经满足。

符号目录的命名可能包含产品名、团队名或工具名。不要因为某个 App 已经从这台 Mac 上卸载，就删除它的符号，因为已分发版本的崩溃报告将来仍可能出现。对空间预算而言，外置归档或对象存储通常比永久丢失符号更便宜。

可用空间低于 5 GB 时，按什么顺序清理

紧急状态下先退出 Xcode 和模拟器，暂时不要更新运行时，也不要执行 Archive。第一步处理已经确认可以重建的旧项目 DerivedData，第二步处理 unavailable 模拟器设备，第三步检查旧 DeviceSupport，第四步再看 npm、SwiftPM 或其他开发者缓存。每轮释放后立即运行 df -h，直到得到足够运行编译器和系统临时文件的余量。

不要优先删除 dSYM 来换取几个 GB，因为符号恢复成本无法用一次重新构建替代。也不要先删除当前项目全部 DerivedData 再马上重复构建：如果根因是代码、依赖或 SDK，重建只会让磁盘再次变满。空间问题和构建故障应该分别记录，清理一类后重新尝试原始操作，才知道哪个动作真正解决了问题。

在空间恢复到至少十几 GB 后，再安排长期整理。把旧 DeviceSupport 和运行时的保留理由写下来，把大型项目产物按版本归档，把符号备份移到有校验和的存储。这样下一次出现告警时，清理的是已知候选，而不是在最紧急的时刻临时猜测。

验证时同时看空间和工作流：用 df -h 确认可用容量，用 xcrun simctl list 确认测试设备仍在，用 Xcode 打开最常用的 scheme 并跑一项真实测试。若构建只在清理后短暂成功，随后又因为下载运行时或生成索引把空间吃回去，说明预算或保留策略还没有解决根因。把清理前后大小、构建时间和测试结果记在维护记录里，下一次可以直接复用，而不必重新试错。

把清理变成 Xcode 的维护清单

每两周检查一次 DerivedData 的最大项目，按月检查 DeviceSupport 是否仍覆盖当前设备矩阵，按季度审查模拟器运行时和 unavailable 设备。Archives 与 dSYM 采用版本生命周期管理，不要和缓存清理任务绑定。项目停止维护时，删除它的 DerivedData 和测试设备数据通常比清空所有活跃项目更合理。

团队可以把 df -h、du -sh、xcrun simctl list devices 和 Xcode 版本写进诊断记录。清理动作也要写明范围，例如“删除项目 A 的 DerivedData 12 GB”或“移除 iOS 17.2 DeviceSupport，重新连接该系统版本的设备时由 Xcode 重新准备”，不要只写“清理 Xcode 缓存”。具体记录能帮助下一个人判断恢复成本，也能解释为什么首次构建变慢。

AskClean 适合把这些类别放进同一张清晰的空间地图：它可以发现项目级 DerivedData、模拟器、DeviceSupport、开发者缓存和大型未知目录，但发布符号和审计样本仍应由团队自己的保留策略决定。工具负责划清范围、设置确认点；你确认的清理项会被永久删除，不会移到废纸篓，所以最终的删除动作应当与开发流程、备份和当前测试矩阵保持一致。

示例电脑 Xcode 存储实测

这组数据来自 2026-10-31 的只读检查，显示为什么应先处理 DeviceSupport 和旧 DerivedData。

这里的大小会随构建和设备连接变化；处理前请重新运行 du -sh，并保留当前设备与发布版本清单。

常见问题