iOS 打包伺服器硬碟不夠？2026 Xcode 27 清理還是擴容
這篇文章寫給維護遠端 iOS 打包伺服器、近期反覆遇到硬碟告警的獨立開發者與小型團隊。你會按場景分辨可再生快取、模擬器元件、依賴資料與發布產物，再決定清理、擴容或拆分主機。
目錄
Apple 的 Xcode 文件以 derivedDataPath 示範指定建構資料位置，代表建構輸出並不是一個可以不加判斷、整個刪除的單一資料夾。官方 xcodebuild 文件與 Xcode Build System 說明都指向同一個維護原則：先確認占用來源，再決定回收邊界。
本週建議動作：先停止並記錄所有 Build、Test、Archive 與匯出任務，依「建構快取 → 模擬器 → 依賴快取 → 發布產物」四層盤點；低頻單 App 先建立清理規則，高頻多專案或反覆滿碟才考慮擴容或增加獨立遠端 Mac。 對於「iOS 打包伺服器硬碟不夠」的情況，這比直接全盤刪除更安全。
這篇文章適合哪一種維護者
只有一台遠端 Mac、近期經常收到硬碟告警的獨立開發者，可以用本文建立可回退的清理順序。
如果你同時保留 Xcode 27、多個 Simulator Runtime 和歷史 Archive，本文能協助你畫出保留界線；若你維護多個 App 或自動化發布任務，則可用場景判斷應繼續治理單機、擴容，還是拆分主機。
先按建構場景判斷：不是所有 Xcode 資料都能刪
只做 Release Archive 的打包機，通常不需要長期承擔完整 UI 測試與 SwiftUI Preview 的資料。相反地，必須進行增量編譯、除錯和多版本回歸的開發環境，清理 DerivedData 後會面對重新索引、重新編譯和重新解析依賴的成本。
| 占用對象 | 主要用途 | 清理前必須確認 | 建議處理 |
|---|---|---|---|
| DerivedData | 編譯中間資料、索引與建構結果 | 沒有進行中的 Build、Test、Archive | 可按專案或指定路徑清理，保留重新建構能力 |
| Build Products／臨時輸出 | Debug 或 Archive 過程產物 | 產物是否仍被驗收或匯出流程使用 | 先確認替代產物，再回收舊輸出 |
| Simulator Runtime | 指定系統版本的模擬器執行環境 | 測試矩陣是否仍需要該版本 | 只保留必要版本，不要把 Runtime 當普通快取 |
| 模擬裝置資料 | 模擬器中的 App 資料與狀態 | 是否需要重現測試案例 | 可按裝置與專案處理，不能一律全刪 |
| Package 快取 | Swift Package Manager、CocoaPods 或私有依賴資料 | 能否從鎖定版本與來源重新取得 | 先驗證冷建構，再刪除不再使用的快取 |
| xcarchive、IPA、dSYM、xcresult | 發布、除錯與測試證據 | 是否已有可驗證的備份或替代來源 | 先歸檔與驗收，再處理重複產物 |
Xcode 27 打包機磁碟滿了怎麼清理？
先取得當前任務狀態與占用排行，再以專案為單位處理 DerivedData 和舊的臨時輸出；不要先刪除 Keychain、整個使用者目錄或所有 Xcode 版本。Apple 的 Build Settings Reference說明了建構設定如何影響輸出位置，因此你應以目前 Scheme 和實際設定確認路徑，而不是套用網路上的固定路徑。
第一步：先凍結任務並留下可回復證據
在 SSH、VNC 或管理介面上確認沒有正在執行的 xcodebuild、測試程序、Archive、IPA 匯出或上傳工作。檢查 CI 工作狀態、終端機退出狀態和最近一次建構日誌，並把目前硬碟使用情況、專案名稱、Xcode 版本和分支記錄下來。
清理正在寫入的 DerivedData 或 Archive，可能讓本次建構失敗，也可能留下不完整產物。若無法確認工作是否已停止，先不要刪除，改等任務明確結束。
第二步：先處理可再生的 DerivedData
DerivedData 通常與索引、編譯中間檔和特定專案的建構狀態有關。對只做 Archive 的遠端打包機，你可以先按專案識別未使用的資料夾；對仍需要增量編譯或快速除錯的專案，則應保留最近使用的資料。
DerivedData 能不能在遠端 Mac 上定期清理？
可以，但條件是清理工作不能與 Build、Test 或 Archive 重疊，而且下一次冷建構必須能從原始碼、鎖定依賴和簽名設定重新完成。較穩妥的做法是先列出實際 derivedDataPath，只清理已停止任務所使用的專案路徑，再執行一次完整 Archive 作為驗收。Apple 的 Xcode 建構系統文件可用來核對建構流程與輸出關係。
不要使用「刪除整個 ~/Library/Developer」這種無差別做法；它可能同時影響模擬器、裝置資料、工具鏈和其他專案。
模擬器測試需要保留的不是一個資料夾
Simulator Runtime、已建立的模擬裝置、App 資料、測試結果和截圖，用途並不相同。只做 Archive 的伺服器，通常不必安裝完整測試矩陣；但若你的 CI 需要 UI 測試或多個系統版本回歸，就必須依測試案例保留相應 Runtime。
模擬器執行環境和 Archive 應該保留多久？
不要用固定天數作為唯一規則。Runtime 應保留到對應版本的測試矩陣不再使用；Archive 則保留到發布追溯、重新匯出或崩潰排查已有其他可驗證來源。Apple 明確提醒，模擬器與實體裝置的執行能力並不等同，詳見 模擬器與實體裝置測試說明。因此，刪除模擬器不能替代實體裝置驗證，也不能把通過模擬器測試當成發布保證。
當某個 Runtime 只被歷史測試使用時，先確認測試矩陣、CI 設定和團隊回歸需求，再透過 Xcode 元件管理移除；Apple 的 額外 Xcode 元件管理文件可作為操作依據。
多專案與依賴恢復：清快取之前先證明能重建
多個 App 共用一台伺服器時，Swift Package Manager、CocoaPods、私有套件和多個 Xcode 版本會形成交錯占用。問題不在於快取能否刪除，而在於刪除後是否還能取得相同版本、相同來源和相同建構設定。
| 場景 | 磁碟治理優先順序 | 清理後的最低驗收 |
|---|---|---|
| 單一 App、低頻發布 | DerivedData → 舊臨時輸出 → 不再使用的依賴快取 | 一次乾淨 Archive |
| 多 App、共用依賴 | 先建立專案與依賴歸屬，再處理重複快取 | 各主要 App 至少完成一次建構 |
| 多個 Xcode 版本 | 依工具鏈與測試矩陣保留元件 | 每個仍支援的版本完成指定 Scheme 驗證 |
| 持續 UI 測試 | 保留必要 Runtime、模擬裝置與測試結果 | 完成一次代表性 UI 測試並保存 xcresult |
iOS 打包伺服器哪些檔案可以刪除？
優先考慮已確認不再使用的 DerivedData、重複的 Build Products 和可由鎖定依賴重新取得的快取；不要把 xcarchive、IPA、dSYM、xcresult 和簽名資產視為同一類。Apple 的 調試資訊與符號文件說明指出，符號資料與崩潰分析有關；測試結果文件則說明測試結果是解讀測試狀態的重要證據。
提醒： 如果 Archive、dSYM 或 xcresult 只有遠端 Mac 上的一份，先複製到可驗證的儲存位置，並實際確認能讀取；「已經備份」不能只靠檔案名稱或同步工作顯示成功來判斷。
第三步至第五步：用連續驗收取代一鍵清理
- 第三步：按來源分類。 分開記錄 DerivedData、Simulator Runtime、模擬裝置資料、Package 快取、xcarchive、IPA、dSYM 和 xcresult，並為每項標上專案、Xcode 版本與最後使用情況。
- 第四步：先做小範圍回收。 只清理已停止任務使用的單一專案資料，保留原始碼、鎖定檔、簽名資產和可取得依賴的來源；不要以整個使用者目錄作為清理範圍。
- 第五步：執行冷建構與 Archive。 重新解析依賴、完成建構、產生 Archive，並核對 Scheme、簽名、輸出位置和退出狀態。Apple 的 Scheme 設定文件可協助你確認實際執行的建構動作。
- 第六步：驗收發布證據。 若要上傳或重新匯出，確認 Archive 可被開啟，IPA 可由預定流程產生，dSYM 和 xcresult 可供後續排查。
- 第七步：建立告警與停止條件。 當清理後空間仍快速下降、冷建構無法恢復，或清理已開始影響多個 App 的工作時，停止繼續刪除，轉入擴容或拆分評估。
清理、擴容還是拆分：用條件作最後判斷
- 若只有低頻單 App、占用主要來自可再生快取，選擇定期治理。 先固定盤點、清理和 Archive 驗收流程，不必因一次告警立即改主機。
- 若同時保留多個 Xcode 版本、Runtime 和歷史發布產物，且清理會破壞回溯能力，選擇擴容。 擴容前仍要先找出真正占用來源，否則更大的硬碟只會延後同一問題。
- 若多個 App 的建構、測試和發布互相爭用同一台 Mac，選擇拆分環境。 將持續 UI 測試、正式發布和臨時版本驗證分開，能降低清理一台唯一生產伺服器時的連鎖風險。
- 若空間壓力只出現在短期版本驗證或發版高峰，選擇增加獨立遠端 Mac。 這比直接改造唯一生產環境更容易回退，也方便保留原有簽名與發布鏈路。你可先查看 VPSMAC 的遠端 Mac 服務與環境說明，再按租期與工作階段評估。
什麼時候該替 iOS 打包機擴容？
當你已完成來源分類、移除不再需要的元件、驗證可回復的清理流程，硬碟仍因多版本工具鏈、測試矩陣或多 App 產物持續逼近告警線時，才適合擴容。若只是一次性舊快取堆積，擴容不是第一個答案；若高峰期反覆滿碟並中斷發布，則應把擴容或增加獨立主機列入本週決策。
如果你正在比較不同租期，也可以參考 M4 遠端 Mac 租用方案整理，但請先以你的 Archive、測試和產物保留需求核對環境，而不是只看硬碟容量。
結論：把唯一打包機留在可恢復狀態
本地 Mac、固定自建主機和遠端方案各有適用範圍。自建設備需要自行處理硬碟升級、電力、網路、遠端存取、故障替換和閒置成本；只有一台主機時，清理或維修還可能直接中斷發布。若你需要的是短期版本驗證、階段性發版高峰或額外的隔離建構環境，VPSMAC 的遠端 Mac 租用能讓你按階段增加環境，而不必先改動唯一的生產打包機。
反過來說，長期固定高負載、需要實體 USB 或連續依賴本地裝置的工作，仍應評估自購設備或專用主機。對大多數只在特定週期增加 Archive 需求的獨立開發者，先保留可驗證的發布產物，再用獨立遠端 Mac 承接高峰，通常比把原有伺服器清理到無法回復更穩妥。