症狀：升級 Xcode 27 後，原本數秒完成的增量建置開始重編譯、索引不結束，CI 也出現等待。
最快解法：先分別記錄冷建置與增量建置的 Build Timing Summary，再按快取失效、依賴與指令碼、索引競爭、磁碟及記憶體壓力逐層取證；不要先清空全部 DerivedData，也不要直接購買更高規格主機。
誰適合閱讀這篇？
如果你是升級 Xcode 27 後發現本地或遠端建置時間改變的 Apple 平台開發者，本文可協助你判斷問題位置。
如果你維護長期在線的遠端 Mac、需要評估是否擴容，或要讓生產 CI 保留穩定版並驗證 Beta 工具鏈，也可以直接依照下列流程操作。
注意： 截至 2026 年 8 月 24 日，Apple 官方資料仍將 Xcode 27 列為 Beta；版本狀態、已知問題與修復內容可能隨後續 Beta、RC 或正式版更新，請以Apple Xcode Release Notes為準。
先把「變慢」拆成可比較的建置證據
「Xcode 27 編譯變慢」不是單一症狀。首次冷建置會受到模組、套件與 DerivedData 尚未建立的影響；日常增量建置則應主要重用未變更目標的結果。Archive、測試、編輯器索引和 SwiftUI Preview 也可能各自造成等待，不能只看一次總耗時就判定是 Mac 效能不足。
先固定以下條件，再做基線：
- 相同的專案提交版本與工作目錄。
- 相同 Scheme、目標平台、簽署設定與建置組態。
- 相同的 Xcode 版本，以及相同的模擬器或實機目標。
- 一次冷建置、連續增量建置，另外記錄 Archive 或測試任務。
- 將圖形介面建置與純命令列建置分開，不要混在同一筆結果。
在 Xcode 中使用 Build With Timing Summary，或在 xcodebuild 建置時啟用 -showBuildTimingSummary，取得目標與階段層級的時間資料；Apple 的增量建置計時說明也建議以可比較的計時結果，而不是資料夾大小判斷問題。
| 觀察結果 | 較可能的來源 | 第一個取證位置 | 不應立即採取的動作 |
|---|---|---|---|
| 冷建置和增量建置都變慢 | 依賴解析、指令碼、磁碟或工具鏈差異 | Timing Summary、建置日誌、資源監控 | 直接擴充節點 |
| 只有修改少量程式碼後仍大量重編譯 | 依賴圖或輸入檔案使快取失效 | 目標依賴、輸入輸出檔案、重建目標 | 清空所有 DerivedData |
| 命令列正常，圖形介面很慢 | 索引、Preview、Simulator 或 SourceKit 競爭 | CPU、記憶體壓力、磁碟 I/O | 長期停用索引 |
| 單一任務正常，並行 CI 才變慢 | 節點共享資源或工作目錄互相污染 | 並行任務監控、工作目錄及快取路徑 | 只比較單次冷建置 |
增量建置為何像全量編譯？
Xcode 27 為什麼每次修改程式碼都像全量編譯？
通常要先查依賴圖、建置輸入是否改變，以及 Run Script Phase 是否被視為每次都必須執行。若日誌顯示未修改的目標反覆出現，問題更接近專案的快取失效或依賴宣告，而不是單純 CPU 不夠。
請在 Timing Summary 和完整建置日誌中尋找這些證據：
- 每次建置是否重新產生依賴圖，或重新準備相同的套件。
- 沒有修改的 target 是否仍被重新編譯。
- Build Settings 是否因條件化組態、環境變數或產物路徑改變，導致輸入被視為不同。
- DerivedData 是否在每次 CI 任務前被換到新路徑，或多個任務錯誤共享同一路徑。
- 顯式模組依賴是否能讓建置系統更準確地判斷模組關係；可參考 Apple 的建置系統說明與顯式模組依賴診斷文件。
DerivedData 不應以資料夾容量作為刪除依據。只有在日誌指向模組快取或中間產物損壞，而且同一組條件下能重現時，才清理該專案的 DerivedData，接著重新執行一次冷建置，再以連續增量建置確認結果。
刪除 DerivedData 能不能解決編譯慢？
它只能處理特定的快取損壞或不一致，不能修復錯誤的 target 依賴、每次都執行的指令碼、套件下載等待或記憶體壓力。若刪除後第一次建置變慢，並不代表問題已解決；你仍要觀察後續增量建置是否恢復重用產物。
依賴解析與自訂指令碼要分開驗證
Swift Package、CocoaPods 或其他依賴準備階段，可能在建置開始前就消耗大量等待時間。比較第一次與後續建置日誌：若每次都出現解析、下載、產生檔案或重新整理套件的步驟，先檢查 CI 的套件快取位置、權限和工作目錄，而不是把整段時間算成「編譯效能」。
Apple 對 CI 中使用 Swift Package 的建議，可參考Swift Package 持續整合工作流程文件。在遠端 Mac 上，還要留意存取程式碼儲存庫或制品服務時的網路等待：Timing Summary 可能顯示建置階段不長，但前置日誌會暴露 DNS、驗證、下載或重試延遲。
Run Script Phase 是另一個常見來源。逐一檢查：
- 指令碼實際讀取的檔案是否列在 Input Files。
- 產生的檔案是否列在 Output Files。
- 指令碼是否無條件執行，即使輸入內容沒有改變。
- 產物是否寫入固定且可預期的路徑。
- CI 任務是否因不同環境變數，讓同一指令碼每次都被判定為需要重跑。
Apple 的自訂建置指令碼輸入與輸出設定說明可用來核對這些欄位。修正後不要只做一次建置，應連續執行多次增量建置，確認指令碼在輸入未變更時確實被跳過，並確認產物仍然正確。
| 階段 | 需要記錄的硬資料 | 判斷方向 | 修復後的驗收 |
|---|---|---|---|
| 套件準備 | 解析、下載、產生檔案的日誌時間點 | 網路或快取流程反覆執行 | 後續建置不再重複不必要的準備 |
| Run Script Phase | 每次執行與輸入輸出檔案清單 | 缺少依賴宣告或無條件執行 | 輸入不變時日誌顯示跳過 |
| 編譯目標 | 每次出現的 target 與 Timing Summary | 增量快取失效或依賴圖過寬 | 未修改目標不再反覆編譯 |
| Archive / 測試 | 與日常建置分離的階段耗時 | 封裝、簽署或測試專屬瓶頸 | 同一提交可重複取得相近階段分布 |
索引、Preview 與 Simulator 可能正在搶同一台 Mac
遠端 Mac 上 Xcode 索引一直不結束時，應該怎樣處理？
先在純命令列建置中重現一次，再與圖形工作階段比較。如果命令列的 Timing Summary 正常，而 Xcode 介面仍卡在索引、SourceKit、SwiftUI Preview 或 Simulator，優先處理並行負載與會話狀態，不要把它當成編譯器回歸。
你可以在 Activity Monitor 觀察：
- 編譯期間 CPU 是否長時間被索引、模擬器或 Preview 工作程序佔用。
- 記憶體壓力是否升高，並檢查交換活動是否持續增加。
- 建置目錄、DerivedData 與套件快取是否同時出現高磁碟 I/O。
- 遠端 VNC 工作階段是否留下不必要的 Simulator、Preview 或多個 Xcode 程序。
Apple 的Activity Monitor 記憶體壓力與交換活動說明可作為判讀依據。短暫關閉 Preview、停止不需要的模擬器工作，然後以命令列和圖形介面各復測一次；不要長期停用索引來掩蓋根因，否則程式碼導覽、跳轉和診斷能力會受到影響。
遠端 Mac 的資源瓶頸要用對照組確認
怎麼判斷是專案問題，還是 Mac 配置不足？
把同一專案、同一提交和同一工具鏈放在單任務與並行任務中比較：若單任務已在編譯階段反覆出現記憶體壓力或磁碟 I/O 飽和，才有理由評估節點擴容；若只有特定指令碼或依賴階段拉長，應先修專案。
在遠端 Mac 上可記錄以下資料：
sw_vers
xcodebuild -version
df -h
sysctl hw.memsize
vm_statsw_vers 和 xcodebuild -version 用來固定作業系統與 Xcode 工具鏈；df -h 檢查建置磁碟可用空間；sysctl hw.memsize 記錄記憶體參數；vm_stat 則可協助比對交換與虛擬記憶體活動。這些是環境證據，不是單獨的效能結論。
還要把 CI 工作目錄、DerivedData 和套件快取分開規劃。多個工作同時寫入同一個中間產物路徑，可能造成鎖定、檔案覆寫或快取失效；反過來，若每個任務都從空目錄開始，也會把原本可重用的成果全部丟掉。對共享節點，至少比較單一任務與並行任務兩組結果，並在重啟後重做一次，避免把長期執行累積的狀態誤判為 Xcode 27 本身的問題。
用這份清單決定修專案、回退或擴容
- [ ] 固定專案提交、Scheme、目標平台、建置組態與 Xcode 版本。
- [ ] 分別保存冷建置、連續增量建置、Archive 和測試的 Timing Summary。
- [ ] 在日誌中標記套件解析、下載、產物產生與 Run Script Phase 的開始及結束位置。
- [ ] 核對 target 依賴、條件化 Build Settings，以及指令碼 Input Files / Output Files。
- [ ] 僅在證據指向快取損壞時清理該專案 DerivedData，並重做冷建置與增量建置。
- [ ] 將命令列建置與 Xcode 圖形工作階段分開，觀察索引、Preview 和 Simulator 的資源佔用。
- [ ] 記錄磁碟可用空間、記憶體壓力、交換活動和建置目錄 I/O。
- [ ] 在單任務、並行任務及重啟後各保留可追溯的建置日誌。
- [ ] 若只有 Beta 工具鏈重現退化，保留 Xcode 26.6 生產鏈路，另設隔離節點進行雙軌驗證。
- [ ] 只有在建置階段正常、資源瓶頸仍可穩定重現時，才進入遠端 Mac 擴容評估。
決策可簡化為三條路徑：
- Timing Summary 集中在依賴或指令碼：先修正專案與輸入輸出宣告，再驗證連續增量建置。
- 同一專案只在 Xcode 27 Beta 節點退化：不要直接替換生產鏈路，保留 Xcode 26.6，使用隔離的遠端 Mac 做雙工具鏈比較。
- 編譯階段本身正常，但記憶體壓力或磁碟 I/O 在單任務也持續飽和：再評估更高資源節點；若只在並行任務發生，先調整工作隔離和併發數。
如果你需要在同一專案中保留多個 Xcode 版本，可先參考多版本工具鏈切換與遠端 Mac 開發環境方向；若目前節點沒有足夠隔離條件，再查看遠端 Mac 方案資訊，把它當成可控的驗證環境，而不是未取證前的效能升級。
最後更新於 2026 年 8 月 24 日；版本狀態核實自Apple Xcode 發布說明，計時與建置判斷核實自 Apple 的增量建置文件。Xcode 27 後續若推出新 Beta、RC 或正式版，應重新檢查發布說明，並以原始建置日誌和節點監控記錄反查任何效能結論。
如果你目前使用本地 Mac 或單一共享節點，常見缺點是工具鏈難以隔離、CI 與互動式索引互相爭用資源，而且升級前後缺少相同提交的對照環境；自行購買 Mac mini 則需要承擔一次性硬體成本、長期維護與遠端連線管理。對需要同時保留 Xcode 26.6、生產建置與 Xcode 27 驗證的人，租用 KVMFLUX 的獨立遠端 Mac，能先複製基線、完成雙版本復測，再決定回退或擴容，通常比在未確認瓶頸前改動整條 CI 鏈路更容易控制風險。