平台组开迁移评审会，老板只问一句：「从 GitHub Actions 换到自建 Mac 节点，开发效率到底能提升多少？」——如果回答「构建快了一点」，会议通常开不下去。2026 年我们帮几支 iOS / Flutter / React Native 团队做过对照实验：迁到自托管 Mac 节点（办公室 Mac mini、机房裸金属、或 Cloud Mac 挂 Runner）之后，最大收益往往不是编译本身，而是排队与等待归零。下文用可复现的四类指标、三套真实量级对照表，回答「提升了多少」；并附两周可落地的迁移清单与 ROI 粗算。
Quick Answer：效率提升多少？
| 你关心的 | 托管 macOS runner（迁移前） | 自建 Mac 节点（迁移后） | 典型提升幅度 |
|---|---|---|---|
| PR 推到绿勾（端到端） | 42–68 分钟 | 9–16 分钟 | 约 70%–80% 缩短 |
| 排队等待（queue time） | 15–45 分钟/次 | 0–2 分钟 | 接近归零 |
| 单次 Archive 构建 | 11–14 分钟 | 8–11 分钟 | 约 15%–25%（缓存命中后） |
| 发版夜可出 TestFlight 版次 | 1–2 版 | 3–5 版 | 吞吐约 2–3 倍 |
| 开发者周被动等待 | 3–6 人时/人 | 0.5–1.2 人时/人 | 约 75% 减少 |
一句话：开发效率提升的主项是「等待」，不是「编译器变快」。自建节点把稀缺 macOS 池从共享队列里摘出来，再叠持久化 DerivedData，才出现上表的量级。
先量什么，再谈「提升了多少」
很多团队迁移后觉得「没快多少」，是因为只看了 GitHub Actions 里的 Job duration，忽略了 queue time 和人在 Slack 里干等的时间。建议迁移前后各采两周，至少记四类数：
- 排队等待：
job queued到job started的秒数，按 P50 / P95 汇报 - PR 反馈环：最后一次 push 到 required checks 全绿的时间
- 发版窗口吞吐：固定 4 小时窗口内成功上传 TestFlight 的次数
- 被动等待人时：抽样问开发者「今天等 CI 多久」或从 PR 评论时间戳推算
导出方式：GitHub API 的 run_started_at 与 created_at 相减；或在 workflow 里加一步把 queue 秒数写入 artifact。没有基线就迁，事后很难向管理层证明 ROI。
| 指标 | 怎么采 | 迁移成功信号 |
|---|---|---|
| Queue P95 | Actions API / 自定义 step | 从 >20min 降到 <3min |
| PR 反馈 P50 | PR 事件时间戳 | 下降 >50% |
| 缓存命中率 | DerivedData 目录体积 + 构建日志 | 从 <20% 升到 >60% |
| 并发失败率 | 同机多 Job 失败占比 | 隔离目录后 <2% |
三套团队对照：迁移前 vs 迁移后
下面三组数据均来自真实迁移项目（团队名匿名化），条件已对齐：同一仓库、同一 Xcode 大版本、采样两周工作日。
案例 A：12 人 iOS 团队，单 App + 扩展
迁移前全部跑 macos-14 托管 runner；迁移后 2 台 M4 16GB Cloud Mac 自托管 Runner，DerivedData 挂本地 NVMe 路径。PR 日均 18 次。
| 指标 | 迁移前 | 迁移后 | 变化 |
|---|---|---|---|
| PR 反馈 P50 | 52 分钟 | 11 分钟 | −79% |
| Queue P95 | 38 分钟 | 0.8 分钟 | −98% |
| Archive 单次 | 12.4 分钟 | 9.1 分钟 | −27% |
| 发版夜 TestFlight 版次 | 1.5 版/夜 | 4 版/夜 | +167% |
Tech Lead 原话：「以前下午五点 push，六点半才能知道能不能合；现在去倒杯水回来就绿了。」
案例 B：28 人 KMP + Android 主仓，Mac 只做 iOS 壳
迁移前 macOS Job 与 Android Job 抢同一发版窗口；迁移后 1 台常驻 M4 Pro + 发版周加 2 台 burst Cloud Mac（见 发版 burst 玩法）。
| 指标 | 迁移前 | 迁移后 | 变化 |
|---|---|---|---|
| 双端 PR 全绿 P50 | 71 分钟 | 24 分钟 | −66% |
| 发版周 Queue 总时长/日 | 6.2 小时 | 0.4 小时 | −94% |
| 开发者周等待（问卷均值） | 4.8 人时 | 1.1 人时 | −77% |
案例 C：8 人 indie，月发版 2 次
反例对照：他们迁移后几乎没提升——因为 PR 少、无排队，自建机反而多了钥匙串维护。Archive 仅从 10.2 分钟降到 9.4 分钟（−8%），Queue 本就接近 0。这说明「提升多少」高度依赖负载形态，不能照搬大厂数据。
提升从哪来：排队、缓存、并发
把总等待时间拆开，更容易向非技术负责人解释：
PR 总耗时 ≈ 排队等待 + 环境准备 + 编译测试 + 上传制品1. 排队（最大头）：GitHub 托管 macOS runner 是共享池，发版周、Xcode 大版本升级周后 P95 排队 30+ 分钟不罕见。自建节点 = 独占执行器，queue 项几乎消失。
2. 冷启动与缓存：托管 Job 结束即销毁，DerivedData、Pods、SwiftPM 缓存每次重来。自建机把热目录挂持久卷，二次构建常见快 20% 左右；细节见 自托管 Runner 缓存与磁盘 FAQ。
3. 并发：2–3 台 Mac 并行接矩阵 Job，发版夜不再「一串糖葫芦」排队。注意多 Job 同机要写目录隔离，否则随机失败会把效率增益吃回去。
| 阶段 | 托管 runner 典型占比 | 自建节点后 |
|---|---|---|
| 排队 | 45%–70% | <5% |
| 依赖解压 / 索引 | 15%–25% | 5%–10%（有持久缓存） |
| 纯编译测试 | 20%–35% | 15%–30% |
两周迁移路径：先对照，再切流量
不建议周五下班「一把梭」切生产。可复现的节奏如下：
- 第 1–2 天：从 Actions 导出两周 queue / duration 基线；选 1 台 Cloud Mac（约 5 分钟开通）装 Runner，
runs-on: [self-hosted, macos, canary]仅手动触发 - 第 3–5 天：持久化
~/ci/DerivedData与 SwiftPM 缓存；同一 main commit 跑 A/B 各 5 次，记 P50 - 第 6–8 天：Release / nightly workflow 切 50% 流量到自建 label；托管 runner 保留作 fallback
- 第 9–10 天：PR required checks 全切自建；写磁盘 80% 水位与产物清理 cron
- 第 11–14 天：对照表复盘，向管理层报 ROI；决定常驻 1 台还是继续按天租 burst
编排层仍用 GitHub Actions——YAML、权限、环境保护规则都不用换平台，只改 runs-on。这与 企业 Mac CI 资源池选型 里的「编排与执行分离」是同一思路。
最小 Workflow 改动示例
jobs:
ios-build:
# 迁移前：runs-on: macos-14
ios-build:
runs-on: [self-hosted, macos, ios-pool]
steps:
- uses: actions/checkout@v4
- name: Log queue metrics
run: echo "QUEUE_SEC=${QUEUE_SEC:-0}" >> $GITHUB_STEP_SUMMARY若你尚未决定买不买机器，按天租 M4 Cloud Mac 做两周对照，成本通常低于「全组人多等一小时」的人力账。
ROI 粗算：效率账能不能盖住机器账？
用案例 A 的数字举个可套用的公式（时薪按 blended $55 估，仅示意）：
- 12 人 × 每周少等 3.7 人时 ≈ 44 人时/月 ≈ $2,420/月 等价产出（或更早合 PR 减少冲突返工）
- 2 台 M4 16GB Cloud Mac 月租约 $206（$103/台 × 2，以定价页为准）
- 平台兼职运维约 4–8 人时/月（磁盘、证书、Runner 升级）
粗算净收益仍为正——但小团队低频构建（案例 C）可能算不过来。决策前用你自己团队的 queue P95 代入：
月收益 ≈ 开发者数 × 每周少等人时 × 4 × 时薪 − 机器月租 − 运维人时 × 时薪发版周还可临时加第三台机做 burst，平峰退租，避免全年为峰值买单。买 vs 租的长期 TCO 对照见 买 Mac mini 还是租 Cloud Mac。
什么时候别迁？——避免为迁移而迁移
下列情况我会明确建议先别动，或只租一周做验证：
- 月 macOS Job <30 次，且 Queue P95 长期 <5 分钟——提升天花板很低（案例 C）
- 无人能 on-call 维护 Runner——磁盘打满比排队更搞心态
- 安全合规要求机器必须在自有 VPC——先解决网络与密钥方案，再上自建池
- 以为迁完就不用 GitHub Actions 了——编排、审计、权限仍值得留在平台上
迁移是手段，目标是可测量的等待时间下降。两周对照实验做不出 >30% 的 PR 反馈改善，就该先优化 workflow（拆 Job、减 Archive 频率），而不是先买三台 Mac。
常见问题 FAQ
从 GitHub Actions 迁到自建 Mac，开发效率一般能提升多少？
高频 iOS 团队常见 PR 反馈缩短 70% 左右、排队接近归零；纯编译快 15%–25%。低频团队可能只有个位数百分比——务必先采基线。
只加一台 Mac 够吗？
对 10 人以内、串行发版通常够；若矩阵测试或多 App 并行，建议 2 台起，并设并发上限避免互踩缓存。
自建后 Actions 账单会降多少？
macOS 分钟数往往可降 60%–90%（视你把多少 Job 迁走）；但会增加机器租购与运维。总账要用上文 ROI 公式一起看。
Cloud Mac 和办公室 Mac mini 效率有差吗？
同芯片同内存下，编译性能接近；差别在网络 RTT（拉依赖、上传制品）与磁盘是否 NVMe。选离代码托管与制品库近的节点。
迁移会影响签名与公证吗？
不会 magically 变好，但环境稳定后钥匙串与描述文件漂移减少，间接少了很多「只在 CI 复现」的半夜救火。
要多长时间才能看见提升？
Runner 接好且缓存目录生效后，第一个工作日就能在 queue 指标上看到变化；PR 反馈环建议采满两周再汇报。
总结与延伸阅读
从 GitHub Actions 迁移至自建 Mac 节点，开发效率提升的答案不是模糊的「快很多」——在典型 iOS 团队里，PR 反馈缩短约七成、发版吞吐翻倍是常见量级，其中大头是排队消失，其次才是持久缓存。用两周对照实验、四类指标和 ROI 公式，你可以给出老板能听懂的数字；若对照不明显，先优化 workflow 比先买机器更划算。
