iOS 打包服务器磁盘不够？2026 Xcode 27 清理还是扩容

这篇文章面向维护远程 iOS 打包服务器的独立开发者和小型团队。你将按构建缓存、模拟器组件、依赖缓存与发布产物分层排查磁盘压力，并根据单 App、多项目和持续测试场景决定清理、扩容还是拆分远程 Mac。

远程 Mac 正在执行 Archive，突然提示磁盘空间不足；源码、证书和账号都没有异常，任务却在构建中途失败。

最快的处理方式不是立刻扩容，也不是执行一条命令全盘删除，而是先把占用分成构建缓存、模拟器组件、依赖缓存和发布产物，再决定清理、保留或增加独立主机。

这篇文章适合只有一台远程 Mac、近期频繁收到磁盘告警的独立开发者；也适合需要同时维护 Xcode 27、多个 Simulator Runtime 和历史 Archive 的小团队。如果你还要运行持续 UI 测试或多个 App 的自动化发布，可以直接看后面的场景决策部分。

本周建议动作：先定位对象，再执行回收

本周时间表	你要做什么	停止条件
第一步	确认当前没有 Build、Test、Archive、导出或上传任务	任务仍在运行时不删除任何构建目录
第二步	记录磁盘总量、可用空间，以及各类目录的归属	无法确认目录属于哪个项目时先保留
第三步	优先处理可再生的 DerivedData、临时构建输出和不再使用的组件	删除后无法说明如何重新生成时停止
第四步	复核依赖能否从锁定文件和可靠来源恢复	私有依赖或离线依赖无法恢复时不清理
第五步	对 xcarchive、dSYM、xcresult 和 IPA 做替代来源验收	没有备份或重新构建链路时不删除发布证据

Xcode 的构建系统会根据项目文件、目标、Scheme 和构建设置组织编译任务；它不是简单地把所有输出都当作缓存处理。你需要先知道某个目录是中间产物、最终产物，还是后续故障排查所需的证据。Apple 的 Xcode Build System 文档对此有明确说明。

两种打包服务器的清理容忍度不同

使用方式	可以优先检查的对象	不应直接删除的对象	建议
只做 Release Archive 和上传	旧 DerivedData、已验收的临时输出、不再使用的 Simulator Runtime	当前发布所需的 xcarchive、dSYM、签名资产	先建立发布产物归档，再做定向清理
需要增量编译、调试和 SwiftUI Preview	项目级旧缓存、已废弃的测试结果、明确不用的模拟设备数据	正在使用的 DerivedData、当前 Scheme 依赖、测试证据	低风险分批清理，保留回退路径
多 App、多 Xcode 版本并行	已确认归属的项目缓存、停用版本对应的组件	仍被其他项目引用的工具链和依赖	按项目与 Xcode 版本建立归属
持续 UI 测试和多系统回归	不在测试矩阵中的运行时和设备	测试矩阵要求的 Runtime、设备数据和结果	先精简测试矩阵，再考虑扩容或拆机

第一种场景：Xcode 27 打包机磁盘满了，先清理什么

如果失败发生在 Archive、导出或上传前，第一步不是看目录名称，而是确认任务状态。通过终端、CI 日志或远程控制台确认没有 xcodebuild、测试进程、导出任务和上传任务仍在写入目标目录；否则即使删除的是缓存，也可能造成当前任务无法完成，甚至留下不完整的发布产物。

DerivedData 可以定期清理，但不能把它当成所有输出

DerivedData 用来放置由 Xcode 构建过程产生的派生文件。Apple 的构建设置文档还区分了配置相关的构建目录、临时目录、派生文件目录和构建产品路径，因此你不能看到一个目录很大，就推断里面全部都可以删除。Apple Build Settings Reference提供了这些路径和设置的定义。

远程打包服务器可以采用以下边界：

✅ 可优先处理：已经确认不再使用、并且能够通过源码和构建设置重新生成的旧 DerivedData。
✅ 可分批处理：项目已经完成一次冷构建和 Archive 验收后，再处理该项目的历史中间输出。
⚠️ 先确认归属：通过 xcodebuild -derivedDataPath 指定过独立输出目录的项目，不一定使用默认 DerivedData 位置。
❌ 不要直接处理：正在运行的 Build、Test、Archive 或导出任务所使用的目录。
❌ 不要粗暴处理：整个用户目录、Keychain、所有 Xcode 版本或无法确认用途的隐藏目录。

Apple 的命令行示例说明，指定 -derivedDataPath 可以让自动化脚本更容易识别构建输出；同时，构建过程会在该路径中产生多个文件。Apple 的 xcodebuild 派生数据示例可以作为你设计项目级输出目录的参考。

如果你需要执行清理命令，先把作用范围写进脚本注释，并保留项目名称、Xcode 版本、Scheme 和执行时间。不要把“清理 DerivedData”写成没有项目边界的全局删除任务。

第二种场景：模拟器运行时和设备数据要分开处理

模拟器占用空间时，最容易出现的误判是把 Simulator Runtime、已创建的模拟设备、应用数据、截图和测试结果全部称为“模拟器缓存”。这些对象的恢复方式和保留理由并不相同。

Apple 允许你在 Xcode 的 Components 设置中管理平台支持、可选组件和不同系统版本的 Simulator Runtime，并显示删除组件后可以回收的空间。Apple 的组件管理文档说明了如何安装、停用和删除这些组件。

只做 Archive 的远程 Mac，可以不承担完整模拟器职责

如果这台 Mac 的唯一任务是 Release Archive、签名和上传，那么你可以把模拟器职责移到另一套开发或测试环境。保留完整测试矩阵会增加工具链维护复杂度；但删除前必须确认没有 UI 测试、截图生成、启动验证或回归任务依赖这些 Runtime。

如果项目需要多系统回归，建议按测试矩阵建立清单：

记录每个测试任务使用的系统版本和设备型号。
标记只用于历史回归、近期没有任务调用的 Runtime。
先在非生产任务上验证删除后的测试命令。
保留能覆盖当前发布阻塞问题的必要 Runtime。
删除后重新运行一条代表性 UI 测试，再决定是否继续回收。

模拟器不能替代实体设备。Apple 明确提醒，模拟器不完全复制真实设备的性能和硬件特性；涉及真实硬件能力时，仍需要在实体设备上验证。Apple 的模拟器与实体设备说明是你制定保留边界时应引用的依据。

因此，“只保留模拟器、不做实体设备验证”不是可靠的磁盘治理方案。它可能暂时释放空间，却把发布风险转移到了测试阶段。

第三种场景：多项目依赖缓存不能一键全删

当一台远程 Mac 同时服务多个 App 时，磁盘压力往往不只来自 Xcode。Swift Package Manager、CocoaPods、私有依赖、多个工作区以及不同 Xcode 版本，可能分别生成自己的解析结果和构建输出。

这时你需要为每个项目建立最小归属信息：

项目或仓库名称；
使用的 Xcode 版本；
Scheme 和构建配置；
Swift Package 或 CocoaPods 的锁定文件；
私有依赖的恢复地址或内部镜像；
最近一次成功 Archive 的时间和产物位置。

清理依赖缓存必须通过冷构建验收

不要把“重新解析依赖成功”当作“项目可以发布”。依赖能够下载，只代表解析阶段通过；它并不证明编译、签名、Archive 和导出链路都能恢复。

建议按下面的连续证据链操作：

在清理前保存当前项目的锁定文件和构建日志。
对目标项目单独执行依赖解析，不要同时改动其他项目。
完成一次冷构建，确认所有目标和私有依赖都能编译。
执行一次 Release Archive，检查签名和嵌入内容。
用项目原有的导出配置完成导出，必要时再验证上传。

Xcode 的 Scheme 决定 Build、Run、Test 和 Archive 使用哪些目标、配置和环境；因此，同一个工作区中不同 Scheme 不能共用一套没有归属的清理规则。Apple 的 Scheme 配置文档对此有具体说明。

第四种场景：xcarchive、IPA、dSYM 和 xcresult 的保留边界

发布产物不应该和缓存放进同一条删除规则。它们分别服务于重新导出、上传追溯、崩溃符号化和测试排查。

文件或目录	主要用途	清理前必须确认	可回退来源
`xcarchive`	保存 Archive 内的应用二进制和相关发布信息	是否仍需重新导出、追溯某次发布或排查崩溃	可靠的归档存储，或可重复生成的完整 Archive
IPA	已导出的分发包	是否仍用于审核追溯、内部测试或重新上传	已验证的 Archive 和导出配置
`dSYM`	将崩溃地址还原为符号和代码位置	是否对应已分发版本	与该构建 UUID 匹配的 Archive 或独立符号备份
`xcresult`	保存测试会话、日志、覆盖率和其他测试结果	是否仍在处理测试失败或审计回归	CI 产物存储或可重新执行的测试任务
上传日志	记录上传、签名或服务器返回信息	是否需要追踪发布失败	CI 日志、App Store Connect 记录或本地归档
临时构建输出	服务于当前构建过程	是否有任务正在使用	重新构建

Apple 明确说明，Archive 会收集应用二进制和 dSYM 文件；对于已经分发的构建，应保留对应 Archive，否则后续崩溃排查可能缺少必要信息。Apple 的调试符号文档是保留 dSYM 和 xcarchive 的直接依据。

测试结果也不能简单当成日志垃圾。使用 xcodebuild test 时，Xcode 会生成 .xcresult，其中可以包含测试会话、覆盖率和日志；正在排查某次失败时，删除它会减少可复核证据。Apple 的测试结果文档说明了 .xcresult 的内容和用途。

⚠️ 注意：如果你无法回答“删除后如何重新导出同一个版本、如何恢复对应 dSYM、如何重现这次失败”，就不要把该文件放进自动清理任务。

发布产物的最小恢复验收

在回收远程 Mac 磁盘前，至少逐项确认：

源码仓库可以在目标 Xcode 版本打开；
签名资产仍可用，且没有把私钥仅保留在待清理主机上；
目标版本的 xcarchive 或可验证的重新构建链路存在；
dSYM 与已分发二进制之间的对应关系可追溯；
导出配置、依赖锁定文件和上传流程能够复现；
至少完成一次不影响线上发布的恢复演练。

如果你需要从 Archive 重新导出，Apple 官方流程使用 xcodebuild -exportArchive，并要求指定 Archive、导出配置和输出路径。Apple 的 Archive 导出说明可以作为自动化脚本的参考。

第五步：用条件分支决定继续清理、扩容还是拆分

下面这组判断适合放进你的运维文档，而不是只靠临时经验做决定：

若满足： 主要是单个 App、发布频率不高，磁盘压力来自旧 DerivedData、无用 Runtime 或重复测试结果，则选 A：建立定期、定向清理策略。
若满足： 仍需保留多个 Xcode 版本和多个系统 Runtime，但任务之间没有明确归属，则先选 B：重组目录和测试矩阵，再判断是否扩容。
若满足： 多个 App 共享同一台 Mac，依赖缓存和 Archive 持续增长，清理后很快再次触发告警，则选 C：增加磁盘或增加独立构建环境。
若满足： UI 测试、发布、开发调试同时争用同一台主机，任何清理都会影响其他任务，则选 D：拆分测试、发布和开发环境。
若满足： 空间需求来自短期版本验证、阶段性发版高峰或临时兼容性测试，则优先考虑按阶段增加独立远程 Mac，而不是改造唯一生产主机。

场景评分	清理策略	扩容策略	拆分远程 Mac
低频单 App、主要做 Archive	★★★★☆	★★☆☆☆	★☆☆☆☆
多 Xcode 版本、少量手工测试	★★★☆☆	★★★★☆	★★★☆☆
多 App、持续自动化发布	★★☆☆☆	★★★★☆	★★★★★
高频 UI 测试和多系统回归	★★☆☆☆	★★★★☆	★★★★★
阶段性发版高峰	★★★☆☆	★★★☆☆	★★★★★

评分不是性能测试，而是维护复杂度判断：星级越高，说明该方案越符合对应场景。真正执行前，仍要以你的目录占用、任务并发方式、依赖恢复能力和发布证据为准。

扩容判断应放在哪个节点

当磁盘告警反复出现，并且占用对象已经被正确分类，说明问题可能已经从“缓存治理”变成“工作负载边界”。尤其是以下情况，不建议继续用删除文件来掩盖容量不足：

保留当前发布所需 Archive、dSYM 和测试证据后，剩余空间仍不足；
多个项目需要并行保留不同 Xcode 版本和 Simulator Runtime；
每次清理后，冷构建、重新解析依赖和恢复测试都要付出明显运维成本；
生产 Archive、自动化测试和开发调试无法错峰；
你已经无法为每个目录确认项目归属和回退来源。

扩容适合“同一套任务长期稳定运行，但现有空间边界不足”的情况。拆分更适合“不同任务需要不同工具链、权限、运行时或稳定性边界”的情况。若只在某个版本验证周期短期增加需求，增加一台独立远程 Mac 往往比在唯一生产打包机上反复安装、删除和迁移更容易回退。

你可以先查看 VPSMAC 的远程 Mac 方案，再根据项目所在地和访问链路选择合适的节点说明，例如 M4 远程 Mac 节点配置。决策重点应放在独立环境是否能隔离当前打包机、是否方便恢复，以及租期是否覆盖你的验证周期，而不是只看一项磁盘容量。

最后判断：清理是治理，扩容是边界，拆分是隔离

对低频单 App 来说，先把 DerivedData、模拟器组件、依赖缓存和发布产物分开，通常比直接增加空间更合理；但对多项目、持续测试和频繁发布环境，单纯清理会把维护风险推迟到下一次 Archive。

你当前方案如果把开发、测试、签名、Archive 和上传都放在唯一一台 Mac 上，通常会有几个真实缺点：清理时容易误伤正在运行的任务；多个 Xcode 版本会互相增加维护负担；历史产物和测试证据缺少独立保存边界；发版高峰还可能让所有项目同时争用同一台主机。

如果你的需求是阶段性的版本验证、临时发版高峰或需要额外的 iOS 打包服务器，租用 VPSMAC 的独立远程 Mac 会比继续压缩唯一生产主机的空间更容易控制风险。你可以保留原有环境不动，把新项目或短期任务放到独立主机上，完成一次 Archive、导出和恢复验收后，再决定是否长期扩容或拆分。