清完 DerivedData 還是滿盤，下一步該擴碟還是加機？

若清後 7 日內可用空間仍反覆跌破 15%，且 du 顯示 DerivedData、CoreSimulator 與容器快取合計占比持續偏高，優先評估 1TB/2TB 擴容或鎖更長租期；若同一時段 CPU/記憶體佇列也飽和，則加第二台或升 M4 Pro 更合適。

擴到 2TB 後建置還是慢，是磁碟問題嗎？

不一定。當 iowait 長期低於 8% 而編譯仍慢，瓶頸更可能在 CPU 並行、連結器記憶體或網路製品鏈路；應回到穩定性驗收與架構矩陣區分 IO 與算力。

2026 年六國遠端 Mac 儲存空間不足怎麼辦？1TB/2TB 擴容 vs 快取治理 vs 加第二台的 FinOps 三選一決策矩陣

若您在新加坡、日本、韓國、香港、美東、美西的獨佔遠端 Mac（M4 / M4 Pro）上反覆遇到「磁碟快滿了、建置卻越來越慢」，本文給出可簽字結論：在擴 1TB/2TB、做快取治理、加第二台峰值機之間，以三選一決策矩陣 + 六步 Runbook + 三條水位閾值選型，並把選擇與日租/月租/季租掛鉤。全文不與「純選區延遲」或 POC 全流程重複，而是承接上線前穩定性驗收之後最常見的下一問：磁碟到底該花錢擴，還是該改用法。

遠端 Mac 滿盤時，最容易誤判的六類痛點

把「能清出來的膨脹」當成「結構性缺碟」：DerivedData、舊 Simulator runtime、Docker 層與 Gradle 快取往往占 40–70% 可釋放空間；若每週清一次仍 7 日內跌破 15% 可用空間，才進入擴碟/加機討論。
只看 df 百分比，不看目錄歸因：APFS 快照、Time Machine 本機快照與「其他使用者」目錄會把根分割區顯示為紅，但真正拖慢 Xcode 的常常是單一大目錄線性成長，需要 du 分層取樣而不是一次性 rm -rf。
擴碟當成萬靈丹，忽略 CPU/記憶體佇列：當 iostat 顯示磁碟利用率長期 <40% 而編譯仍慢，瓶頸在並行度或連結器記憶體；此時升 M4 Pro 或加第二台比 2TB 更有效。
Monorepo + 多 Simulator 卻堅持 256GB 基線：partial clone 能減拉倉體積，但本機中間產物與模擬器映像仍隨分支與 OS 版本累積；應與Monorepo 瘦身清單聯讀，而不是重複造輪子。
六國節點「同機扛一切」：建置、UI 測試、簽章上傳若共碟，峰值週會把水位同時打滿；與多機建置池 FinOps的分工是：本篇先判定單機磁碟策略，再決定是否值得第二台。
短專案用月租擴碟，長基線卻只靠日清：FinOps 上，可預期的常駐膨脹適合鎖 1TB/2TB + 月租/季租；兩週衝刺更適合清理 + 日租峰值機，避免為 14 天鎖全年檔位。

六國遠端 Mac 的工程優勢是獨佔實體碟邊界清晰，但邊界清晰不等於容量自動匹配 workload。Apple 矽統一記憶體架構下，磁碟壓力與記憶體壓力常同相出現：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：從取樣到三選一簽字

凍結水位基線：記錄總容量、可用百分比、主要掛載點；寫入節點 ID、Xcode 版本與最近一次清理 commit（腳本版本）。
分層 du 取樣（Top 12 目錄）：對 ~/Library/Developer、DerivedData、CoreSimulator、~/.gradle、~/Library/Containers 等分層；輸出 CSV 備查。
執行標準清理包：依序清理 DerivedData（可保留目前 scheme）、未用 Simulator runtime、Docker 懸空映像、舊 Archives（需與發布負責人確認）。
複測 24h 斜率：若可用空間每日淨減少 >3 個百分點且無可解釋發布活動，標記為結構性成長。
對照矩陣選支路：快取治理 / 擴 1TB·2TB / 加第二台；禁止「清碟 + 擴碟 + 加機」三件套無備註同時上。
寫 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 專文作為附件，避免發版週只討論容量不討論鏈路。