GitHub Actions 自托管 macOS Runner | 弹性池与常驻节点决策矩阵

2026 年不少 macOS/iOS 流水线呈「短周期、尖峰并发」：发版前几小时多分支同时构建，队列在托管与自托管池之间抖动。自托管 Runner 若「一台常驻扛全部」，峰值常被排队与冷缓存拉高 P95。下文用延迟、缓存与队列三轴对比云 Mac 弹性池与常驻节点，并附可写进仓库的参数片段。现金与租购节奏见 2026年突发构建与应急提审：自购 Mac 还是按天/按周租云 Mac？买 vs 租决策矩阵与清单。

决策轴：延迟 · 缓存 · 队列

Runner 形态：弹性池 / 常驻

目标：压低 P95 排队时间

短周期峰值长什么样？

峰值是提交簇、合并与提审叠加的突发队列：多 job 争用同一组标签时，检出与依赖解析会放大 RTT，wall time 常半在排队与 IO。观测拆成「排队」「检出」「编译」三段，比只看总时长更能判断扩池还是修缓存。

弹性池与常驻节点：决策矩阵

弹性池适合吞吐随日历波动、可接受偶发冷启动的团队；常驻节点适合强一致基线、签名与钥匙串状态要长期保持的流水线。下表按三条轴归纳典型取舍。

维度	云 Mac 弹性池	常驻节点
延迟（排队 + 冷启动）	峰值可横向扩容，但新实例首跑可能多一次镜像与缓存预热	几乎无排队时 P95 最低；容量上限固定，峰值易堵
缓存（DerivedData / 依赖）	需外置缓存（对象存储或共享卷），否则每轮弹性易「冷」	本地盘命中率高，但要治理磁盘膨胀与权限漂移
队列（并发策略）	配合 `concurrency` 与多标签分池，削峰明显	适合串行敏感任务（签名、公证），用 `runs-on` 细标签隔离

实操提示

弹性池与常驻并非二选一：常见做法是「常驻 1～2 台保底线 + 弹性池吃尖峰」，用不同 runs-on 标签区分「必须热缓存」与「可冷启动」两类 job。

可执行参数清单（workflow + Runner）

下列片段可直接粘进仓库做起点，再按团队标签命名习惯微调。Runner 进程若以 launchd 托管，可参考 2026在云Mac上部署OpenClaw：与Linux云主机不同的环境校验、launchd后台常驻与可复现排障FAQ 中的常驻与排障思路，把崩溃自拉起与日志轮转一并纳入。

workflow：并发、队列与单 Runner 独占

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  ios-build:
    runs-on: [self-hosted, macOS, cloud-pool]
    timeout-minutes: 90
# 需要串行公证/上传时改用常驻标签，例如 [self-hosted, macOS, notary]

actions/cache 关键输入（示例键）

- uses: actions/cache@v4
  with:
    path: |
      ~/Library/Developer/Xcode/DerivedData
      ~/Library/Caches/CocoaPods
    key: ${{ runner.os }}-xcode-${{ hashFiles('**/Podfile.lock') }}-${{ github.sha }}
    restore-keys: |
      ${{ runner.os }}-xcode-${{ hashFiles('**/Podfile.lock') }}-

Runner 注册与钩子（摘录）

# 注册时打齐标签，便于 workflow 分池
./config.sh --url https://github.com/ORG --token REG_TOKEN \
  --labels self-hosted,macOS,cloud-pool --replace

# 可选：job 开始时清理工作区或挂载缓存
export ACTIONS_RUNNER_HOOK_JOB_STARTED=/usr/local/bin/ci-job-started.sh

建议为弹性池与常驻分建 Runner Group，并用仓库级 concurrency 限制同 ref 重复构建，避免尖峰抢占公证通道。缓存键须含 Xcode 与锁文件版本，防「错缓存」比冷启动更难查。

短周期峰值长什么样？

弹性池与常驻节点：决策矩阵

可执行参数清单（workflow + Runner）

在云端 Mac mini 上，峰值更可控

峰值构建不排队：用统一云 Mac 画像接住队列