2026 年六国远程 Mac 存储不够怎么办？1TB/2TB 扩容 vs 缓存治理 vs 加第二台的 FinOps 三选一决策矩阵

约 11 分钟阅读 · MACCOME

如果你在新加坡、日本、韩国、香港、美东、美西的独占远程 Mac（M4 / M4 Pro）上反复遇到「盘快满了、构建却越来越慢」，本文给出可签字结论：在扩 1TB/2TB、做缓存治理、加第二台峰值机之间用三选一决策矩阵 + 六步 Runbook + 三条水位阈值选型，并把选择与日租/月租/季租挂钩。全文不与「纯选区延迟」或 POC 全流程重复，而是承接上线前稳定性验收之后最常见的下一问：磁盘到底该花钱扩，还是该改用法。📊

远程 Mac 满盘时，最容易误判的六类痛点

  1. 把「能清出来的膨胀」当成「结构性缺盘」：DerivedData、旧 Simulator runtime、Docker 层与 Gradle 缓存往往占 40–70% 可释放空间；若每周清一次仍 7 日内跌破 15% 可用空间，才进入扩盘/加机讨论。
  2. 只看 df 百分比，不看目录归因：APFS 快照、Time Machine 本地快照与「其它用户」目录会把根分区显示为红，但真正拖慢 Xcode 的常常是单一大目录线性增长，需要 du 分层采样而不是一次性 rm -rf。
  3. 扩盘当成万能药，忽略 CPU/内存队列：当 iostat 显示磁盘利用率长期 <40% 而编译仍慢，瓶颈在并行度或链接器内存；此时升 M4 Pro 或加第二台比 2TB 更有效。
  4. Monorepo + 多 Simulator 却坚持 256GB 基线：partial clone 能减拉仓体积，但本地中间产物与模拟器镜像仍随分支与 OS 版本累积；应与Monorepo 瘦身清单联读，而不是重复造轮子。
  5. 六国节点「同机扛一切」：构建、UI 测试、签名上传若共盘，峰值周会把水位同时打满；与多机构建池 FinOps的分工是：本篇先判定单机磁盘策略，再决定是否值得第二台。
  6. 短项目用月租扩盘，长基线却只靠日清：FinOps 上，可预期的常驻膨胀适合锁 1TB/2TB + 月租/季租；两周冲刺更适合清理 + 日租峰值机，避免为 14 天锁全年档位。

六国远程 Mac 的工程优势是独占物理盘边界清晰，但边界清晰不等于容量自动匹配 workload。苹果硅统一内存架构下，磁盘压力与内存压力常同相出现：Simulator 并行、Swift 增量编译与容器层缓存会同时推高 IO 与 RAM。若不做三选一决策，团队往往在「再清一次盘」与「再加一台机」之间来回横跳，既浪费租期又拖慢发布节奏。💾

本篇与多地区节点租赁与成本指南的关系是：那边回答「选哪国、选什么租期」；这里回答在同一节点上，磁盘瓶颈的第一性处置顺序。也与CocoaPods/SPM 源站与磁盘清单互补——依赖下载优化能减少「假性满盘」，但不能替代对 DerivedData 与模拟器资产的治理。

场景信号 优先：缓存治理 优先：1TB/2TB 扩盘 优先：加第二台 / 升 Pro
清盘后 7 日可用空间仍 <15% 仅当 du 显示可释放 >30% 且未执行过标准清理 默认：结构性增长（多分支 DerivedData） 若 CPU 队列 p95 同时饱和
单仓 <8GB，但 3+ 套 Simulator OS 卸载未用 runtime + 设备集 常驻 2+ 大版本 OS 镜像 并行 UI 测试 worker >2
Monorepo + affected 已启用仍周周满 检查 blobless 与缓存路径 默认：中间产物目录隔离失败 构建与测试必须分盘/分机
发版周仅 10–14 天峰值 默认：清理 + 快照导出 不推荐锁季租仅为两周 日租/周租第二台更优
扩 2TB 后 iowait 仍 <8% 且慢 非磁盘主因，停止继续扩盘 一票否决：勿再加盘 默认：算力/并发瓶颈
storage

底层机制：APFS 的写时复制让「删除大目录」有时不能立刻回收「可用空间」显示，尤其是存在本地快照时。治理步骤必须包含快照列表核对，否则会出现「明明删了 200GB，df 只回来 20GB」的挫败感，进而误判为必须扩盘。🔍

六步 Runbook：从采样到三选一签字

  1. 冻结水位基线：记录总容量、可用百分比、主要挂载点；写入节点 ID、Xcode 版本与最近一次清理 commit（脚本版本）。
  2. 分层 du 采样（Top 12 目录）：对 ~/Library/Developer、DerivedData、CoreSimulator、~/.gradle、~/Library/Containers 等分层；输出 CSV 备查。
  3. 执行标准清理包：按顺序清理 DerivedData（可保留当前 scheme）、未用 Simulator runtime、Docker 悬空镜像、旧 Archives（需与发布负责人确认）。
  4. 复测 24h 斜率：若可用空间每日净减少 >3 个百分点且无可解释发布活动，标记为结构性增长。
  5. 对照矩阵选支路：缓存治理 / 扩 1TB·2TB / 加第二台；禁止「清盘 + 扩盘 + 加机」三件套无备注同时上。
  6. 写 FinOps 备注锁租期：结构性 → 月租/季租 + 扩盘；短峰值 → 日租/周租加机；并在台账注明复核日期。
bash
# 磁盘 Top 目录采样（在远程 Mac 上执行，请替换 WORK 路径）
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

三条应写进评审会的量化阈值（用团队基线替换常数）

  • 清理收益比：标准清理包应释放不低于当前已用空间的 18%；若低于 12%，说明膨胀已结构化，进入扩盘/加机矩阵而非重复清理。
  • 可用空间红线：生产构建机建议维持≥20% 可用；低于 15% 时禁止启动全量 Archive + 并行 UI 测试（可与POC 扩容 KPI共用门禁字段）。
  • 扩盘后的 IO 验证：扩 1TB/2TB 后 48h 内，若磁盘 busy% 中位数仍 <25% 而构建耗时无改善，应在评审中关闭「继续加盘」选项，转查 CPU/内存与制品链路 RTT。

收尾：别用「再加一块盘」掩盖架构分工

在六国远程 Mac 上，磁盘决策的本质是把不可压缩的工作集与可压缩的缓存分开。清得掉的，用治理；清不掉的，用扩盘或分机；清不掉且算力也满的，别再加盘——那只是在为队列瓶颈买安慰剂。

自建 Mac 托管或短期云实例常把「磁盘」和「运维」拆成两张账单，团队容易低估快照、模拟器资产与多人共盘的复利；而纯靠本地笔记本接力构建，则往往在发版周同时撞上磁盘与睡眠策略问题。对需要独占 Apple Silicon、可预期磁盘档位、六国就近节点的团队，把本篇矩阵写进采购附件后，用 MACCOME 的 Mac 云主机把 1TB/2TB 与租期组合一次性对齐，通常比反复临时加盘或盲目加机更省总拥有成本，也更利于 CI 与人工排障共用同一套水位语言。✅

下一步若你已锁定扩盘或加机，请把节点大区与租期条目一并带入评审；价格与周期对照见产品页，技术互链仍建议保留稳定性验收与 Monorepo 专文作为附件，避免发布周只讨论容量不讨论链路。🧭

常见问题

清完 DerivedData 还是满盘，下一步该扩盘还是加机？

若清后 7 日内可用空间仍反复跌破 15%，且 du 显示 Developer 子目录合计占比持续偏高，优先评估 1TB/2TB 与月租组合；若同时 CPU/内存队列饱和，参考多机构建池文加第二台。档位与价格见租赁价格说明。

扩到 2TB 后构建还是慢，是磁盘问题吗？

不一定。当 IO 不忙而编译仍慢，应回到稳定性验收与架构矩阵区分算力与网络；操作细节见帮助中心。