2026年短週期峰值構建：GitHub Actions 自託管 macOS Runner 該用雲 Mac 彈性池還是常駐節點？延遲、快取與佇列的決策矩陣（可執行參數清單）

短週期、只在發版窗口出現的建置峰值，是把自託管 macOS Runner 接進 GitHub Actions 時最常卡住的地方：你不是缺機器，而是缺「剛好出現、又剛好不排隊」的時間片。2026 年實務上常見兩條路：雲 Mac 彈性池（依尖峰開關、按使用付費）與常駐節點（長開、獨佔憑證與快取）。兩者沒有道德優越性，只有在你團隊的佇列形態、快取命中率與合規邊界下，哪一邊的總時間與總帳單更便宜。若你同時在評估「買斷 vs 按週租」的應急路線，可先對照 2026年突發建置與應急提審：自購 Mac 還是按天／按週租雲端 Mac？買 vs 租決策矩陣與清單 裡的成本口徑。

彈性池 vs 常駐節點：先對齊假設

彈性池適合「Job 彼此獨立、可接受偶發冷啟動、希望把閒置成本壓到接近零」；常駐節點適合「需要預熱 DerivedData、固定鑰匙圈、把同一台 Runner 當成長期觀測基準」的流水線。若後台常駐服務與 launchd 行為也要一併穩定，可延伸閱讀 2026在雲Mac上部署OpenClaw：與Linux雲主機不同的環境校驗、launchd後台常駐與可復現排障FAQ 裡對常駐行程與可復現環境的整理。

延遲、快取與佇列：把體感變成指標

延遲

把 Runner 註冊、映像啟動、Git fetch、依賴還原與編譯分段計時；DNS 與 TLS 握手慢常被誤判成「Xcode 變慢」。對外網 Git 與制品庫，建議在報表裡拆出網路段與編譯段。

快取

DerivedData、SPM、CocoaPods 與工具鏈 tarball 可視為「會過期的資產」：在彈性池上給每個快取條目加版本鍵，避免 silent mismatch；常駐節點則要防止快取膨脹吃滿磁碟。

佇列

用 runner group、labels 與 workflow 的 runs-on 精準分流，避免「所有 macOS Job 搶同一個標籤」造成假性塞車。必要時把輕量檢查與重量編譯拆成兩條佇列。

# Workflow（節流與逾時）
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true   # 視分支策略開關
jobs:
  ios:
    runs-on: [self-hosted, macos-14, xcode-16]
    timeout-minutes: 90

# config.sh（自託管 Runner 註冊）
./config.sh --url https://github.com/ORG/REPO --token "***" \
  --labels "macos-14,xcode-16,apple-silicon" \
  --runnergroup "ios-ci" \
  --ephemeral   # 與彈性池回收策略搭配

# 快取策略鍵（版本化）
Xcode / CLT 版本 + lockfile 雜湊 + Swift 工具鏈版本