① merge queue 与标签路由：决策矩阵
merge queue解决的是“合并顺序与主干一致性”：把已审批的拉取请求按规则进入队列，在近似已合并的提交上重跑检查，再真正快进主干。Runner 标签解决的是“哪台 Mac 执行、是否与发布/重编译抢盘”。两者正交：队列再漂亮，标签写错仍会跑到错误工具链；标签再细，没有队列仍可能被并发的本地合并打乱主干节奏。
| 维度 | merge queue 侧重 | 共享 Runner 标签路由侧重 |
|---|---|---|
| 主要风险 | 合并组失败连锁、等待变长 | 盘与内存争用、签名串线、错池 |
| 典型信号 | 主干频繁回滚、合并竞态多 | 队列肉眼可见变深、失败与机器相关 |
| 小团队默认 | 主干分支开启；限制并行合并组数量 | 拆 merge 与 heavy-build 池；单机保守并发 |
与队列实现细节相关的运维协同，可对照 共享机构建队列与 flock 问答、占座锁与排队 FAQ；多节点时配合 部署与任务队列同步 统一命名与阈值。
② 参数清单（深度·标签·锁·超时·抢占）
下表给出可抄基线，请按仓库体量、签名步骤与磁盘规格上调或下调；原则是先让失败可解释，再谈提速。
| 项 | 建议起点 | 说明 |
|---|---|---|
| merge queue 并行度／深度 | 并行合并组 1；待处理上限约 5～10 | 共享单 Mac 时并行组保持 1；深度超阈评估加节点或拆分池。 |
| Runner 标签 | self-hosted + macOS + pool-<name> + lane-<merge|ci> |
merge queue 触发的检查工作流显式匹配 lane-merge，日常拉请求走 lane-ci，减少与发布抢键。 |
| 工作流 concurrency | 单仓库单环境一组：concurrency: group: ${{ github.workflow }}-${{ github.ref }}，cancel-in-progress: true（轻检）／false（重编） |
重编建议串行；轻检可取消过时提交节省队列。 |
flock 等待 |
30～120 秒；失败退避 2～5 分钟最多 3 次 | 包裹签名、公证、派生数据清理等单写区；与 Xcode 签名队列矩阵 对齐。 |
| Shell／步骤 timeout | 轻检 10～20 分；完整构建 45～90 分；公证链路单独放宽并拆分步骤 | timeout 过短会产生“假红”；过长会占满 merge 窗口。 |
| 抢占规则 | 发布／热修标签优先占用 lane-merge；必要时暂停接纳新的合并组或临时改标签路由 |
文档化“谁可打断谁”，避免口头约定；与稳定性基线见 延迟与重连清单。 |
③ 落地顺序与观测
- 画一张标签表：哪些工作流必须上共享 Mac，哪些可留在云端轻检。
- 为 merge queue 检查单独匹配 Runner 池，避免与交互式调试共用宽标签。
- 为并发组与 flock 文件路径写进 README，并在告警里附上队列深度与等待分位数。
- 用一次“故意失败”演练合并组回滚与重试，确认通知到人。
- 当等待分位数持续升高或深度长期大于阈值，优先横向扩容节点与套餐档位，而非单机堆进程。
④ 常见问题
问：merge queue 开了，还要不要在主干保护规则里限制并发？
答：要。队列解决合并语义；Runner 侧仍需 concurrency 与资源阈值，否则检查阶段仍会相互拖死。
问：只有一个共享 Mac，merge queue 会不会反而更慢？
答：可能。队列换来的是可预测的主干；若吞吐不足，应缩小并行合并组、缩短检查矩阵，或增加远程节点与更高套餐，而不是关掉队列回到隐性竞态。
小结与扩容
merge queue · Runner 池
把预合并检查与标签路由落在真实远程节点上
Meshmac 提供多台远程苹果机与访问方式，便于拆分 merge 检查池与重编译池、横向扩容。定价与文档可免登录浏览，再按需加节点或升级套餐。
merge queue 友好
多池标签
横向扩容