Xcode 模拟器占用 Mac 大量空间？应该优先清理什么

如果 Xcode 模拟器正在占用 Mac 大量空间，请在删除任何内容之前先区分模拟器运行时和模拟器设备数据。首先审查什么是不可用的、什么是非活跃的、以及你仍然需要用于测试的内容，因为模拟器清理在将每个 Apple 侧文件夹都当作可丢弃缓存处理时会变得有风险。

这是开发者在学到一条清理规则后就到处套用时犯的错误。DerivedData 是一回事。模拟器运行时和模拟器设备状态是另一回事。

存储是可以回收的。只是后果不那么统一。

快速回答

Xcode 模拟器存储了什么以及为什么会累积

模拟器存储不是一样东西。它是多个层级一起累积的结果。

从高层级来看，Xcode 模拟器存储通常包括：

• 不同 iOS 平台版本的运行时镜像；
• 为不同 iPhone 和 iPad 型号创建的模拟器设备；
• 这些模拟器内每个设备的应用数据、设置和状态；
• 在你切换 SDK、设备类型和 Xcode 版本时增长的 Apple 侧开发开销。

这就是为什么开发者经常对 CoreSimulator 感到困惑的原因。很容易看到文件夹大小就假设整个东西只是缓存。实际上，其中一部分更像是一次性的测试状态，而另一部分是你仍然依赖的运行时支持。

增长模式是正常的：

• 你安装了新的 Xcode 或 SDK；
• 新的运行时出现；
• 创建了新的模拟器设备；
• 应用、测试数据和设置在其中累积；
• 旧设备在 SDK 更改或 Xcode 升级后变为不可用；
• 数月没有被审查，因为机器仍有足够的可用空间。

然后某一天模拟器存储成为主要问题，而不再是一个细节。

模拟器运行时 vs 模拟器数据：有什么区别？

这是最重要的区分。

Apple 的 simctl 工具将运行时操作与设备操作分开处理。这本身就告诉你清理模型是分层的：设备与运行时不是同一回事，擦除设备与删除运行时镜像也不是同一回事。

这就是为什么像”直接清掉 CoreSimulator”这样笼统的说法是不好的建议。它们将不同的清理后果压缩成一个情绪化的操作。

DerivedData 在哪里适用

DerivedData 是相关的，但不是同一个问题。

DerivedData 通常是生成的构建输出。模拟器存储更复杂。它可以包含你仍然需要的运行时、你不再需要的已创建设备、以及设备内你可能关心也可能不关心的状态。

如果压力主要来自生成的构建输出，正确的指南是 Xcode DerivedData 占用过多空间？应该优先清理什么。如果压力主要来自运行时镜像和模拟器状态，继续使用模拟器工作流。

如何检查模拟器占用了多少空间

第一步是检查，而不是删除。

使用 Apple 自己的工具查看实际存在哪些设备和运行时：

xcrun simctl list devices
xcrun simctl list runtimes

如果你想直接检查磁盘上更广泛的 Apple 侧存储占用，也可以直接比较主要文件夹：

du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

这很重要，因为最大的 Apple 侧文件夹并不总是你假设的那个。有时 DerivedData 是主要问题。有时 CoreSimulator 悄悄超过了它。

首先要找什么

• 列在 Unavailable 下的设备；
• 你不再测试的操作系统版本的运行时；
• 跨多个运行时世代创建的大量设备；
• 自多次 Xcode 更新以来未清理过的机器上模拟器密集的状态；
• 与你当前测试需求不匹配的大型 CoreSimulator 文件夹。

那就是清理从反应式变为理性式的起点。

在 Mac 上删除模拟器运行时安全吗？

有时可以，但这不是最安全的第一步。

Apple 的 simctl runtime 帮助明确指出运行时镜像是独立管理的对象。删除运行时与清除模拟器内容不同，也与删除不可用设备不同。

这意味着运行时删除最适合以下情况：

• 你不再需要该 iOS 版本进行测试；
• 你已经超越了旧的 Xcode 或 SDK 世代；
• 该运行时足够不常用，空间价值超过了便利性；
• 你已经先查看了运行时列表并确切知道你要移除什么。

以下情况是不好的选择：

• 一个活跃项目仍然面向该运行时系列；
• SwiftUI 预览、QA 复现步骤或回归测试仍然依赖它；
• 你即将在旧目标上演示或调试问题；
• 你仅根据大小而非实际测试需求在删除。

更好的第一步：移除明显的无用负担

最安全的模拟器清理通常从不可用设备开始。

Apple 在 simctl delete 中直接文档化了这一点：unavailable 别名删除当前 Xcode SDK 不支持的设备。

xcrun simctl delete unavailable

这不是通用答案，但它是其中一个最干净的首轮操作，因为它针对的是已经被当前 SDK 上下文标记为不支持的设备。

在不破坏开发环境的情况下清理模拟器数据

这是开发者经常用错工具的地方。

如果你的问题是模拟器内过期的应用数据或膨胀的设备状态，你可能根本不需要删除运行时。你可能只需要重置模拟器设备。

Apple 的 simctl erase 帮助将 erase 定义为擦除设备的内容和设置：

xcrun simctl erase <device>

这是一个重置操作，不是运行时移除操作。

erase 适合做什么

• 清除模拟器内的应用状态；
• 重置测试环境；
• 移除膨胀的设备级内容而不移除运行时镜像本身；
• 保留设备工作流同时丢弃其累积的状态。

erase 不是什么

• 不是运行时清理命令；
• 不是 DerivedData 清理命令；
• 不是审查你实际仍需要哪些设备和运行时的好替代方法。

这个区分就是整个模拟器清理的全部故事：擦除设备、删除设备和删除运行时是三个不同的决定。

如何持续管理模拟器存储

实际目标不是”永远不让模拟器增长”。实际目标是”阻止模拟器存储变成不可见的”。

使用这样的审查节奏：

1. 在重大 Xcode 或 SDK 更改之后列出设备和运行时。
2. 当不可用设备出现时删除它们。
3. 当问题是设备状态而非运行时清单时，重置过期的模拟器设备。
4. 在完全移除某个操作系统版本之前审查运行时使用情况。
5. 当 Apple 侧存储开始攀升时，一起比较 CoreSimulator、DerivedData 和 Archives。

这让清理决策与实际占用昂贵的层级保持一致。

Apple 侧存储的更好心智模型

• DerivedData 主要是生成的构建输出。
• Archives 保留交付物和构建历史。
• CoreSimulator 混合了运行时支持和模拟器设备状态。
• 最安全的清理取决于哪个层级大，而不仅仅是哪个文件夹可见。

一旦你按层级思考，模拟器清理就会变得不那么混乱。

为什么保持感知生态系统让开发者清理效果更好

如果你只使用 Finder，一个 20 GB 或 30 GB 的 Apple 侧文件夹看起来像是一个明显的清理目标。实际上不是。

文件浏览器可以告诉你 CoreSimulator 很大。它不能告诉你真正可回收的空间是：

• 不支持的设备；
• 可重置的模拟器内容；
• 你不再需要的运行时；
• 还是恰好住在附近的另一个 Xcode 配置文件。

这就是为什么模拟器清理属于开发者清理，而非通用文件清理。

如果你的实际问题是”模拟器加上 DerivedData 加上其他 Apple 开发者存储”，那种更全面的感知配置文件工作流比逐个追逐文件夹路径有用得多。

总结

如果 Xcode 模拟器正在占用 Mac 大量空间，不要把 CoreSimulator 当作一个可随意丢弃的缓存桶。

先审查设备和运行时。将删除不可用设备作为干净的第一轮操作，仅当你想重置模拟器内容和设置时使用 erase，并仅在你确实不再需要该操作系统版本时才移除运行时。

这是更安全的清理路径：将运行时镜像与设备状态分开，将模拟器存储与 DerivedData 分开，让 Apple 侧清理与实际测试需求关联，而不是盲目删除文件夹。