Mac mini M4 当构建节点时，磁盘先满往往比 CPU 先满：Xcode DerivedData、模拟器镜像、缓存的 Pods 与未上传的中间产物堆在一起，Runner 仍显示在线但 xcodebuild 以晦涩 I/O 错误失败。本文为 2026 年可执行矩阵：先定水位阈值与告警，再决定「本地删、远端存、还是缩短保留」，最后给六步清理与和队列 SLO 的联动方式。文内含两张结构不同的表与多处数值化参数。
队列与扩缩容背景见 队列深度与等待 SLO；维护排空见 Runner 排空与交接。需要临时加机吸收磁盘整理窗口可看 定价与区域；连接问题见 帮助文档。
三类典型痛点：不是「空间不足」四个字能概括的
- DerivedData 与索引爆炸：多分支并行时，单仓可在数周内涨到 40～90 GB，且增量编译依赖其存在——粗暴全删会让下一次构建像冷启动。
- 产物只落盘不上传：流水线把
.ipa或测试包留在/tmp，重跑与重试成倍放大。 - 监控只看 CPU：磁盘 95% 时队列仍接收任务，直到随机作业失败才暴露，p95 等待被误读为「需要加机」。
磁盘水位阈值与告警动作
| 根卷可用空间占比 | 建议动作 | 是否可继续接新作业 |
|---|---|---|
| > 20% | 常规监控 | 是 |
| 12～20% | 触发 DerivedData 按年龄 LRU 清理 | 是，附公告 |
| < 10% | 从默认标签摘除主机并排空 | 否，直至恢复 > 15% |
保留策略矩阵：删、传、还是缩 TTL
| 数据类型 | 首选 | 次选 | 避免 |
|---|---|---|---|
| 可再生的 DerivedData | 按最后访问时间删最旧 30% | 按分支保留白名单 | 无差别 rm -rf ~/Library/Developer |
| 需审计的构建产物 | 上传对象存储并设 14 天生命周期 | 同步到只读 NFS | 长期堆在 Runner 本地 |
| Pods / SPM 缓存 | 集中缓存服务器 + 本地上限 15 GB | 按 lock 文件哈希分片 | 每 job 全量重新解析不限制体积 |
与 SLO 挂钩：当磁盘清理导致冷编译使单作业墙钟上升超过 25% 时，在周报中单独披露「存储治理成本」，避免被误记为 Runner 性能退化。
模拟器与 XCTest 产物的特殊处理
iOS 模拟器在多次 UI 测试后会留下大量设备数据与截屏缓存，体积常达 20～50 GB。建议在非发布周设定「模拟器重置日」：先确认无正在运行的 UI 套件，再按设备型号批量卸载未使用 runtime。若团队依赖快照测试，务必备份黄金快照到对象存储而非留在 Runner 本地。否则清理脚本会误删基线，导致大规模假阳性。
对 Xcode 的 Archives 目录，可与发布工单绑定保留策略：关联已上架版本的归档保留 90 天，未关联发布的试验性归档 14 天即回收。把规则写进内部 wiki 并链接到 CI 模板变量，减少「谁删了我的包」类工单。
六步有序清理清单
- 基线快照：记录
df -h与最大目录duTop 10。 - 摘掉入站标签：防止清理中途有新作业写入。
- 删过期临时目录：按工单号或构建号匹配 > 72 h 的目录。
- 执行 DerivedData LRU：保留默认分支与最近 5 个活跃分支的缓存。
- 验证最小绿构建：跑一条标准流水线含签名步骤。
- 挂回标签并观察 60 分钟：对比 p95 等待与清理前基线。
自动化清理与人工门禁的平衡
完全自动化清理在凌晨执行省事，但容易在发布夜误伤热缓存。折中方案是：自动化只处理明确安全的目录（临时构建、超过 TTL 的下载缓存），DerivedData 的 LRU 需要白天值班二次确认或在低峰窗口执行。把 cron 与编排器维护窗写入同一日历，避免「无人知晓的 rm」与「计划内排空」叠乘导致队列真空。
指标上建议同时跟踪「清理节省的 GB」与「随后 24 小时内编译墙钟中位数」：若节省空间显著但墙钟上升超过约定阈值，应回滚策略或扩大白名单分支集合。单一 KPI 只看磁盘百分比会误导管理层以为运维「修好了」而研发感到「变慢了」。
独占物理机与云节点的组合思路
Apple Silicon M4 的统一内存与高速 SSD 适合作为「热」构建层，但仍需策略防止单盘写放大。NodeMac 在香港、日本、韩国、新加坡与美国提供带 SSH 与 VNC 的专用 Mac mini M4，可在主池清理时租用短期溢出机承接流量；按需付费避免为偶发磁盘峰值采购整机。把节点当可替换资源时，磁盘治理与 容量借调、并行构建分片 同一套标签语言描述，运维认知成本更低。
磁盘告警与容量预测
与其在 95% 满盘时才人工介入，不如在 75% 与 85% 设两级告警：前者触发「本周清理 backlog」工单，后者触发「禁止新大任务入队」的软闸门。结合近 14 天构建次数与平均产物大小做线性外推，可提前 48 小时预测是否会撞线。
APFS 快照与 Time Machine 本地备份在 CI 机上常是隐形占用源。若未使用，应在基线镜像中默认关闭；若需要，给快照单独配额并在周报告里列出 top 目录，避免「系统数据」黑盒化。NodeMac 客户在独占机上可要求运维在交付清单写明初始快照策略，减少首月踩坑。
常见反模式
无差别 rm -rf ~/Library/Developer/Xcode/DerivedData 会在高峰时段拖垮编译；把 CocoaPods 与 SwiftPM 缓存与构建产物混在同一卷却不设上限，会导致「删了 DerivedData 仍满盘」的假胜利；仅依赖云厂商磁盘扩容而不改保留矩阵，成本会线性上升而问题复发周期不变。
将本矩阵打印成一页纸贴在值班手册首页，并在季度回顾会上用真实节省的 GB 与构建耗时数据复盘，比口头强调「记得清盘」有效得多。与 队列等待 SLO 与 Runner 排空 联动时，可把磁盘软闸门作为编排器前置条件，形成闭环。