在 Linux 上您習慣把依賴快取與建置輸出分卷；換到 macOS 共享節點，SwiftPM 的原始碼檢出目錄、Pods 目錄與 DerivedData 往往預設落在同一使用者家目錄樹下，若再疊加多個儲存庫並行，磁碟與 inode 會先於 CPU 成為瓶頸。下面七條用於審查前自檢。
Package.resolved 與分支策略不一致：同一儲存庫多分支並行建置時，若未把檢出路徑與解析結果綁定到「分支桶」，會出現解析成功但連結到錯誤產物的假陽性。
CocoaPods 的 Ruby 生態漂移：系統 Ruby、rbenv、Bundler 混用導致 pod 版本不一致，表現為「本機綠、CI 偶紅」且難以重現。
共享 DerivedData 根目錄：多個工作寫入同一 -derivedDataPath 時，模組快取與索引檔互踩，編譯錯誤看起來像依賴毀損。
Pods 與 SPM 雙棧重複拉取：同一第三方既以 Pod 又以 SPM 形式出現，體積與解析時間翻倍，卻未必被架構審查發現。
清理指令碼誤刪「仍在佇列中的快取」：排程依時間戳刪目錄，可能刪掉正在跑的工作之中間產物，引發連鎖失敗。
CDN／鏡像策略不統一：外網抖動時 pod repo update 與 SPM 解析走不同出口，排隊延遲被放大成「CI 不穩定」。
缺少磁碟水位與唯讀基線合約：未定義「低於百分之多少觸發唯讀降級或拒絕新工作」，共享機會在滿盤後才暴露，修復成本高於預防。
這些痛點的共同根因，是把 Linux VPS 上的「單儲存庫單管線」假設搬到了「多儲存庫共享 Mac」：您需要的不只是更大磁碟，而是命名空間化的快取與鎖檔治理。把它們寫進帳本後，再用下一張表決定：是否值得在工程上收斂為單棧，或接受混用但以分區目錄硬隔離。
從依賴管理模型看，SwiftPM 傾向把可重複解析寫進 Package.resolved，強調與編譯器同源的解析器；CocoaPods 則長期與 Ruby 工具鏈綁定，企業裡又常以 Bundler 釘死版本。兩者混用時，平台側最忌諱的是「讓 CI 使用者在互動式 shell 裡隨手改全域 gem」：那會把不確定性注入每一台共享節點。更穩妥的做法是：每個儲存庫自帶 Gemfile.lock，CI 只執行 bundle exec pod install，並把 vendor/bundle 或等價路徑放到可清理分割區。
與 可重現建置 篇聯動：指紋指令碼應同時記錄 swift package resolve 的校驗和與 pod --version，否則您只鎖了 Xcode，卻沒有鎖依賴解析層。與 Runner 篇聯動：若您把快取掛載到共享卷，必須規定「依儲存庫子目錄掛載」而不是「整盤共享一個 DerivedData」，否則並行度愈高，互踩機率愈大。
解析階段的網路與 CDN 策略見第 4 節。下面進入對照表，把架構取捨從爭論收斂成可執行的分區策略。
沒有銀彈：只 SPM 時目錄結構較統一，但遺留 ObjC 生態仍常依賴 Pods；只 Pods 時團隊熟悉，但 Ruby 與 CDN 維運成本更高。審查時把三條 SLA 寫清：解析可重複性、磁碟峰值、失敗可解釋性。
| 維度 | 以 SwiftPM 為主 | 以 CocoaPods 為主 | 混用（常見存量） |
|---|---|---|---|
| 鎖檔與可重複性 | Package.resolved 與解析器版本強相關 | Podfile.lock + Ruby／Bundler 版本必須釘死 | 兩套鎖檔與兩套快取目錄，需防重複依賴與路徑衝突 |
| 磁碟特徵 | 原始碼檢出 + SPM 快取，體積可預期 | Pods 體積大，Ruby 工具鏈額外占空間 | 峰值疊加，需分桶 DerivedData |
| 並發友善度 | 目錄隔離簡單，適合高平行 | pod install 可能長時間占鎖，需佇列化 | 必須拆分工作目錄，避免同路徑寫入 |
| 維運抓手 | 與 Xcode 工具鏈同源，易進指紋指令碼 | 需維護 gem 來源、CDN 與 Bundler 快取策略 | Runbook 最長，但存量業務最常遇到 |
| 與黃金映像關係 | 可把 SPM 快取預熱進映像層 | 常把 Ruby 與已知 Pods 打進基線 | 映像變大，需分層：工具鏈層／依賴層／可變層 |
「像買 VPS 一樣租 Mac」在依賴層意味著：您買的是可預期的目錄合約與水位線，而不是「和筆電一樣隨緣滿盤」。把 SPM 與 Pods 的快取都當成租戶，而不是背景雜訊。
若您正在實施 企業建置資源池，建議把「依賴解析工作」與「簽章發行工作」分區：前者可以容忍更激進的清理，後者必須避免與實驗性 Bundler 環境共享家目錄。與 快照與長期節點 篇聯動：混用雙棧時，長期節點更依賴「按週清理 + 水位警示」；快照基線則更依賴「把 Bundler 與 SPM 快取分層預熱」。
當審查結論是「短期無法去 Pod，只能混用」時，請把工程規則寫死：哪些三方只允許走 SPM、哪些必須留在 Pod（例如尚未 SPM 化的二進位閉源套件），並禁止同名模組雙通道引入。否則並行編譯會在連結階段才爆炸，排障成本最高。對平台來說，這意味著要在模板儲存庫裡提供最小可複製的 Gemfile 與 .bundle/config 片段，讓業務複製貼上而不是各自發明。
下列順序強調「先分區、再解析、最後才談命中快取」：與 可重現建置 的指紋指令碼對齊，避免依賴層引入第二套未記錄環境。
為每個儲存庫固定工作根與分支桶：例如 /ci/work/<repo>/<branch-hash>，所有 SPM 檢出、Pods、DerivedData 均落在該桶下，禁止回寫到 ~/Library 預設路徑。
釘死 Bundler 與 CocoaPods：在 CI 映像或啟動指令碼裡只使用 bundle exec，並把 BUNDLE_PATH 指到工作桶內的 vendor 目錄。
SwiftPM 解析與建置分離觀測：對解析階段單獨計時；解析失敗時保留 .build 相關日誌片段，避免與編譯錯誤混淆。
DerivedData 依工作隔離：xcodebuild 統一傳入明確 -derivedDataPath，並與上一步工作根組合。
定義清理策略：依水位觸發、依佇列空閒窗執行、依「最久未存取」淘汰；禁止無差別 rm -rf ~/Library。
與 Runner 標籤銜接：對「重 pod install」的工作使用獨立 label 限流，見 Runner 篇；避免與高頻編譯工作搶同一並發槽。
export CI_WORK_ROOT="/ci/work/${REPO_SLUG}/${BRANCH_KEY}"
export DERIVED_DATA="${CI_WORK_ROOT}/DerivedData"
export PODS_ROOT="${CI_WORK_ROOT}/Pods"
export BUNDLE_PATH="${CI_WORK_ROOT}/vendor/bundle"
mkdir -p "$DERIVED_DATA"
bundle config set path "$BUNDLE_PATH"
bundle exec pod install --deployment
swift package resolve
提示：若同一台機還承擔 Fastlane 發行，發行工作的工作桶應與 CI 解析桶分離，避免 Bundler 與 App Store Connect 工具鏈互相污染。
在 GitHub Actions 等平台上，建議把「依賴安裝」與「編譯測試」分層：快取鍵與鎖檔內容綁定，而不是只綁定分支名。若使用 Workspace 同時含 SPM 與 Pods，應固定 xcodebuild -workspace 參數，避免本機 GUI 與 CI 指令長期不一致。
與 XCTest／Simulator 篇聯動：測試工作若複用編譯階段 DerivedData，應明確宣告唯讀或可寫範圍；否則測試階段的清理指令碼可能誤傷編譯快取。把「誰能刪誰」寫進內部權限模型，和 Linux 上容器卷策略一樣嚴肅對待。
CocoaPods 在企業環境裡最典型的生產事故不是語法錯誤，而是解析階段外網失敗被誤判為程式問題。平台應為共享節點設定統一的 gem 鏡像與 Git 協定策略（HTTPS／SSH），並在防火牆層允許中繼資料主機名；同時把 pod install 的逾時與重試寫進 workflow，而不是依賴預設。
SwiftPM 側則要關注 Package.resolved 是否與解析器版本匹配：升級 Xcode 大版本後，優先在 canary 工作上跑一遍 swift package resolve 與最小建置，再放開全佇列。與 可重現建置 的「乾淨 clone → green build」清單對齊：任何鎖檔變更都應觸發一次全量解析快取失效的預警，而不是悄悄污染共享快取。
注意：不要在滿盤臨界點繼續接受新工作：應觸發唯讀降級（拒絕調度）並先跑清理；否則 Xcode 與 git 可能出現半寫入狀態，修復成本高於短暫停佇列。
若團隊同時維護多地區節點，建議把 CDN 命中與解析耗時納入監控面板：當 P95 明顯上升時，先懷疑網路與鏡像，而不是讓業務加「重試三次」式糊牆。與 SSH 接入清單 聯動：批量節點的 Bundler 與 pod 版本應透過組態管理下發，而不是手動 SSH 各自升級。
下列條目用於內部對齊；具體閾值以您們並行度與儲存庫體量為準。
swift package resolve 結束碼、bundle exec pod --version 與 Podfile.lock 校驗和，作為是否允許合併的門檻。個人筆電常因睡眠與本機工具鏈漂移讓依賴問題「看起來像玄學」；純 Linux 又無法承載官方 iOS 工具鏈。把解析與建置搬到獨佔、長期在線、可分割的遠端 Mac，才能把 SwiftPM 與 CocoaPods 的混用變成合約。相較自建零散機器或混用不穩定託管環境，NodeMini 的 Mac Mini 雲端租賃在固定 SSH、清晰磁碟檔位與可複製的節點畫像上更利於把依賴治理納入平台工程；需要對比規格與價格時，可先閱讀 雲端租賃價格，再結合 說明中心 完成接入。
落地時建議把本 Runbook 與內部「依賴變更等級」綁定：鎖檔修補、次與大版本升級對應不同簽核與快取失效策略。