为什么 256GB 会先被「看不见」的目录吃满
大型 Xcode 工程在远程 Mac 上全量编译时，仓库体积往往只是冰山一角：~/Library/Developer/Xcode/DerivedData 存放索引、模块缓存与中间产物；Swift Package Manager 还会在 SourcePackages、全局制品缓存里保留解析后的依赖与二进制制品。多分支、多配置并行跑 CI 时，同一台机器上的缓存会按「工程 × Xcode 小版本 × 分支」倍增。若未提前做磁盘预算，最先报警的是系统盘剩余空间，而不是 CPU。
了解更多：Flutter 与 Xcode 同机争用时的节点与内存决策
磁盘预算：先分清「热缓存」与「可丢缓存」
DerivedData
删除 DerivedData 通常只损失增量编译加速，下次构建会重新生成；适合作为「低成本腾空间」的首选。若流水线依赖模块稳定性，可改为按 Job 隔离路径或定期清理过期 UUID 目录。
SPM 与制品缓存
SPM 缓存能显著缩短依赖解析与拉取时间，但体积随私有 Registry、二进制依赖而膨胀。清理前要确认是否与其他 Job 共享缓存；共享时能省带宽与磁盘，但单点清理会影响并发 Job。
档位与并联：清理还是加盘？
下面用决策矩阵概括常见做法（月费与单价为示意，以各云厂商当期报价为准）。核心规则是：16GB/256GB 优先「 aggressive 清理 + 单工程串行」；24GB/512GB 可保留少量共享 SPM 缓存；M4 Pro + 1TB/2TB 适合作为缓存母机或多仓库并行，减少反复解析带来的时间成本。
| 档位 | 典型策略 | 清理频率 | 适用场景 |
|---|---|---|---|
| M4 16GB / 256GB | 每 Job 独立 DerivedData；SPM 仅保留当前分支；禁止多巨型工程并行 | 每日或每构建后 | 单 App 夜间构建、个人开发者 |
| M4 24GB / 512GB | 共享只读 SPM 缓存 + 分目录 DerivedData；大版本升级后统一清扫 | 每周 + 发版后 | 小团队多分支、Flutter+iOS 混跑 |
| M4 Pro + 1TB/2TB | 一台缓存母机 + 多台计算 Runner；保留多 Xcode 小版本缓存 | 按月归档 + 监控阈值 | 单体大仓、多产品线公证与构建 |
并联扩容的本质是用「多付一台短租机」换「少一次全量解析」。当单次清理导致的构建时间损失折算成人时高于增量租金时，就应增加带大盘的 Pro 档位，而不是无限压缩单机磁盘。 了解更多：远程 Mac 公证流水线与 M4 并联选型
五地节点与同步成本
东京、首尔、香港、新加坡与美西之间同步巨型缓存并不划算：RTT 与跨境带宽会吃掉「保留缓存」带来的收益。更务实的做法是选定 1～2 个「构建主区域」（例如离代码托管与签名钥匙串最近），其余区域 Runner 只拉取构建产物或最小镜像，避免五地各一份完整 DerivedData。
常见问题
在 Mac mini 上把磁盘与算力一次对齐
远程跑大型 Xcode 工程时，Apple Silicon 的统一内存带宽与高能效让长时间全量编译不易因散热触顶而降频；macOS 与 Xcode 同源优化使 SPM、模块缓存行为可预期，配合 Gatekeeper、SIP 与 FileVault，多租户 CI 环境的面貌也更清晰。Mac mini M4 待机功耗仅约 4W 量级，适合作为 7×24 构建节点长期在线，总拥有成本低于同性能 x86 工作站加机房空调的组合。
若你希望把「清理决策」落在更稳的硬件与托管环境上，而不是每天手工删目录，Mac mini M4 是当前最具性价比的起点——从带盘 Pro 并联到轻量 16GB 前置任务，都可以按团队节奏逐步扩容。