為什麼 256GB 會先被 DerivedData 與 SwiftPM「吃掉」
大型 Xcode 工程在遠端 Mac 會同時堆高 DerivedData（索引、模組快取、建置輸出）、SwiftPM 解析與 checkout，以及模擬器與測試附屬檔。日韓港新美西各一台 Runner 時，快取隨「分支 × 套件版本」相乘；256GB 機型常在數週內逼近 APFS 建議的15% 以上可用空間，引發 I/O 抖動與交換。
先做磁碟預算，再談清理腳本
建議把系統碟切成四欄靜態預算：系統＋Xcode 約 45–60GB；DerivedData 上限（例 80–120GB）；SwiftPM／SourcePackages 與快取目錄合計上限；其餘給日誌與緩衝。每欄設監控閾值（df -h＋目錄週報），觸線時先刪最舊非主線 DerivedData，再視情況全清 SPM。
五地節點與快取策略
日韓港新美西可採主構建＋區域快取：主節點保留完整 DerivedData，其餘僅留發版線與熱分支，並鎖定同一 Xcode 小版本以免快取鍵漂移。若同跑 Flutter 與原生 iOS，磁碟爭用更激烈，可參考 Gradle／Xcode 同機爭用與短租決策。
純 SSH 與遠端圖形化 Xcode 的延遲預算見 日韓港新美西遠端 Mac FAQ。
硬體檔位 × 清理／擴容決策矩陣（示意）
| 檔位 | 磁碟策略 | 建議清理節奏 | 何時考慮併聯擴容 |
|---|---|---|---|
| M4 16GB／256GB | DerivedData 嚴格配額；SPM 僅保留主分支 | 每週增量清＋每月深清 | 多產品線並行或單倉 DerivedData 常態 >90GB |
| M4 24GB／512GB | 可保留 2–3 條長生命週期分支快取 | 雙週深清；釋出前強制掃描 | 快取命中率仍低且 CI 排隊上升 |
| M4 Pro＋1TB／2TB | 可做區域「種子」節點；減少五地重複下載 | 按月維護＋依版本升級觸發 | 單機已滿足吞吐，改優化網路與權限治理 |
落地檢查清單
-
路徑一致：統一
xcodebuild -derivedDataPath與 Xcode「Locations」中的 DerivedData 設定，避免腳本與本機 GUI 各寫各的目錄。 - 分支治理：過期分支 DerivedData 自動刪除規則與管線掛鉤一併上線。
- 監控：空間低於 20% 時阻擋非緊急建置，先觸發清理或改派至大碟節點。
成本優化：清快取 vs 加一台併聯
若人力成本低、分支變動快，積極清理＋小碟短租往往總體更省；若團隊已跨五地且網路邊際成本高，一台 M4 Pro 大碟種子＋多台輕節點可把重複下載與解析攤薄。決策時請把「一次全清後的 CI 恢復時間」納入 SLO，而不只看月費帳面數字。
常見問題
在 Mac mini 上把預算表跑滿，而不是把磁碟跑滿
上述流程在 macOS 上最省事：Xcode 與 SwiftPM 路徑一致、無 x86 虛擬層；M4 記憶體頻寬利於編譯連結，Mac mini 待機約 4W 適合 7×24 Runner。Gatekeeper、SIP、FileVault 也降低長期暴露網路的風險。
若你要在穩定、低噪音、TCO 可控下跑遠端建置，Mac mini M4 仍是 2026 年彈性起點；預算表寫清楚後再依矩陣決定是否加一台大碟併聯。想把做法一次跑順，現在即可搭配下方 CTA 開通演練。