2026 年 Mac 云 CI「冷启动 vs 温节点」怎么选：队列退避、DerivedData 亲和与常驻基线的可执行配置
负责 iOS/macOS 流水线的同学常常已经会写 GitHub Actions，却仍被「第一次慢、第二次快、第三次又慢」的方差折磨：根因往往不是 Xcode 本身，而是冷启动缓存未命中与多 job 争用同一 DerivedData 根目录。本文面向 2026 年要把 Mac 云当成可控 VPS 的平台团队：先拆四类痛点，再给冷/温/常驻对照矩阵，接着落地 DerivedData 亲和与队列退避参数、三条可引用指标与 FAQ；读完你能用一张表向团队解释何时该为温节点付租金属性，何时该让冷启动吃掉分钟尖峰。
目录
1. 痛点拆解：冷启动方差、亲和缺失、退避缺失与观测盲区
当你把 Mac 云节点接入 CI，本质是在复用「像管 Linux VPS 一样」的心智：SSH、systemd/launchd、磁盘与出口都可控。但 Swift 大工程对 NVMe 与缓存局部性极其敏感，若仍沿用「每台 runner 一个共享 DerivedData」的坏习惯，冷启动与温启动的差异会被放大成 flaky。
- 冷启动尾延迟：首次 checkout 后解析 SPM/CocoaPods、预热索引、链接阶段会把 P95 拉长；若财务只看总分钟数，会误判为代码变重，而根因是缓存未命中。
- 亲和缺失导致的漂移：同一分支连续构建若落到不同物理机或不同磁盘分区，模块增量编译收益骤降；团队会误以为是编译器升级，实际是路径漂移。
- 无退避的并发闸门：多个 Archive job 同时触发时，若缺少 max parallel 与指数退避，NVMe 队列深度飙升会让失败表现为「偶发链接超时」，难以与业务缺陷区分。
- 观测只看 CPU：macOS CI 的第一性原理往往是 IO 与元数据；忽略磁盘可用空间百分比与链接阶段耗时分布，会让优化会议永远停在「再加两核」。
2. 决策矩阵：冷启动池、温节点、常驻基线三种形态怎么选
下列矩阵刻意与「弹性池 + 常驻基线」路由文章互补：那张表回答 PR/Nightly 走哪类 runner；本文回答同一台 Mac 云内部如何把冷/温/常驻参数写进可执行配置。延伸阅读：iOS CI 弹性池与 Mac 云基线分工、构建资源池容量决策矩阵。
| 维度 | 冷启动优先（按需短跑） | 温节点（半常驻缓存） | 常驻基线（独占槽位） |
|---|---|---|---|
| 典型负载 | lint、单测、轻量编译矩阵 | 中等多模块增量、频繁 PR | Archive、公证、长时 UI 矩阵 |
| 尾延迟敏感度 | 可接受分钟换弹性 | 需要稳定 P95，但可容忍偶发迁移 | 要求链接阶段方差极低 |
| 磁盘策略 | 每 job 独立子目录 + 夜间 gc | sticky 路径或短周期镜像快照 | 双分区：构建域与制品域隔离 |
| 队列策略 | 高并发 + 严格退避上限 | 中并发 + 队列深度阈值 | 低并发 + 人工变更窗口 |
3. DerivedData 亲和：路径设计、并发闸门与反 stampede
亲和的目标不是「永远同一台机器」，而是让编译器看到的模块缓存与索引在统计意义上可复用。实践上至少做到三点：为每个并发槽位分配独立 DERIVED_DATA_PATH；Archive 与轻量 job 分队列；在磁盘低于约百分之十五可用空间时禁止新 Archive 入队。
export DERIVED_DATA_PATH=/Volumes/ci/d12/$JOB_SLOT/dd
export COCOAPODS_CACHE_PATH=/Volumes/ci/d12/$JOB_SLOT/cocoapods
xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' build
队列退避建议与组织级重试策略对齐：对链接阶段失败使用较小最大重试次数并拉长间隔，避免在磁盘已红时形成 thundering herd；对源码编译失败则快速失败以节省队列占用。
4. 五步落地：从画像到验收
- job 画像：把流水线拆成冷/温/常驻三类，分别统计平均排队、编译、链接、上传占比；若链接占比异常升高，优先检查 DerivedData 争用而非加 CPU。
- 路径契约：写清
JOB_SLOT或自托管 label 与目录映射，禁止个人实验分支默认写入共享缓存根。 - 并发闸门：为 Archive 设全局 max parallel=1～2；为 PR 增量构建设更高上限但绑定退避曲线。
- 告警接线：把磁盘水位、队列深度、重试分钟占比接入与 CI 可观测性一致的面板，避免只在失败邮件里看到症状。
- 三次构建验收：固定同一 commit 连续跑三次，比较 P95 与失败类型聚类；若方差仍高，再评估增加第二台常驻基线而非盲目扩并发。
5. 三条可引用指标：排队、链接长尾、磁盘水位
- 排队占端到端比例：若持续高于约百分之十五且与提交频率强相关，说明池子策略与任务混部需要调整，而非单纯「机器不够快」。
- 链接阶段耗时方差：同一 commit 三次构建的链接 P95 差距若超过约百分之二十五，优先核查是否共享 DerivedData 根或磁盘水位过低。
- 重试分钟占比：当重试消耗分钟超过总量约四分之一时，多半是退避缺失或闸门过大导致的 IO stampede，应先降并发再扩容。
6. 与站内弹性池文章的衔接
若你已经在实践「PR 走托管弹性、Nightly 走 Mac 常驻」，本文把第二层的「Mac 云内部怎么配」补齐：冷启动负责吸收尖峰分钟，温节点负责稳住增量体验，常驻基线负责 Archive 与上架链路的可预测性。把两层策略叠在一起，财务与平台才能用同一套语言讨论成本与稳定性。
7. FAQ
问：只有一台 Mac 云也能做温节点吗？ 可以，用目录槽位与队列深度模拟「逻辑温区」；但要接受迁移窗口仍然存在，Archive 仍建议独占低并发队列。
问：亲和与安全性冲突怎么办？ 多租户隔离应优先于盲目 sticky：不同项目使用不同 Unix 用户与卷挂载点，避免密钥与缓存交叉污染。
问：是否需要自建分布式缓存集群？ 在团队规模未到前，先把本地 NVMe 分区与 job 级路径做对，通常比过早引入远端缓存更能降低方差。
8. 结论与下一步
冷启动不是敌人，无约束的混部才是；温节点与常驻基线的价值在于把尾延迟从「随机过程」变成「可配置参数」。当你已经能读队列与磁盘曲线，就能把 Mac 云真正当成可编程算力，而不是另一台会随机变慢的共享 Mac。
仅依赖托管池时，磁盘布局与并发闸门仍受平台策略约束，难以把 macOS 当成完全属于你的构建土地；纯冷启动堆叠在单台小磁盘节点上，又容易在 Archive 与 PR 增量之间互相踩踏。对要把 iOS 交付做成稳定产能、又希望继续用 SSH 与 launchd 延续 Linux VPS 运维习惯的团队，租赁 VPSMAC 的 Apple Silicon Mac 云节点，用独占或低并发基线承载重链路，把冷启动留给可接受方差的轻任务，通常比继续在「同一 DerivedData 根目录」上硬扛尖峰更接近问题本质。