谁会遇到问题：在新加坡、日韩、香港与美东美西已部署多组远程 Mac Runner，却仍看到白天空转、夜间排队，日租/月租账单与真实利用率对不上号。本文结论：用「UTC 窗 + 池标签 + 并发上限 + 租期水分摊」把接力写成可审计表，并与节点选择、Runner 并发、跨区制品链路文档交叉引用。结构：六类根因 → 六国窗口矩阵 → YAML 片段 → 六步 Runbook → 三 KPI → 选型收束。
当你在新加坡、东京、首尔、香港、弗吉尼亚或硅谷各放一组 自托管 Runner，却用单一「总部时区」的 cron 去触发重任务时，常见结果是：业务白天构建机在吃灰，而业务深夜所有合并请求挤在同一小时，队列深度把 P95 拉长到不可接受。根因通常不是机器不够，而是触发时钟与开发者协作时钟错位，再叠加「租期按自然日计费」带来的水分摊失败。下面六条是平台组在 2025–2026 周期最常忽略、却最伤利用率的因素。
workflow_dispatch、合并策略与「六国 UTC 偏移」写进同一张表，导致亚太白天的大量空档无法承接美西刚下班的构建洪峰。max-parallel 与「每仓库并发」写进策略，峰值时 Git 拉取与制品上传与《跨区 Git/Registry Runbook》中的长尾重试叠加，出现「CPU 不满但 job 全红」的假性容量不足。要把 Apple Silicon 远程机构建成可审计的 24 小时产能表，需要把「时区窗、Runner 池、租期档位」绑定在同一变更单；这与仅讨论 CPU 是 M4 还是 M4 Pro 的选型页互补，而不是替代关系。
下列窗口以 UTC 为基准，示例给出「亚太夜间批处理 ↔ 北美白天交互」的常见切分；请按你们真实 sprint 时区替换。若主仓库在美东，优先让编译与单测跟随仓库近端，UI/Simulator 跟随开发者密度更高的一端，避免无意义的跨太平洋制品往返。
| 区域（代表城市） | 相对 UTC 偏移（示例） | 典型接力角色 | 更适合的 job 类型 | 主要风险 |
|---|---|---|---|---|
| 新加坡 / SG | +8 | 亚太早班先行构建、为欧非留出缓冲 | 编译、单测、lint、依赖缓存预热 | 与欧美同日高峰重叠时需限并发，避免 Git 出口争用 |
| 日本 | +9 | 承接深夜批处理与「跟日区产品」联调 | 夜间全量回归、制品晋升前复检 | 与北美高峰同日叠加时需限并发与制品 handoff SLA |
| 韩国 | +9 | 与日区类似的批处理承接，可独立标签池 | 并行单测、依赖缓存预热、面向韩区合规审查的构建 | 若与日区共机，需在标签上区分「数据驻留」策略，避免混池 |
| 香港 | +8 | 华南协作与跨境链路的中继 | 中等并行构建、面向大陆出口优化 | 与主仓区域不一致时，制品同步窗口要写 SLA |
| 美国东部（弗吉尼亚） | −5/−4（DST） | 与 GitHub/GitLab 主区域常见对齐点 | 高频 PR 构建、合并队列、制品上传 | 白天高峰与亚太夜间 handoff 需明确缓存键 |
| 美国西部（硅谷） | −8/−7（DST） | 承接「美西下班前」交互式排错 | Simulator、录屏复现、设计师联调 | VNC/带宽成本上升；应与纯 SSH 池拆分标签 |
下列片段用于在内部 IaC 或 Runner 注册表里强制显式化地理/时段，避免「默认池吃一切」。占位符请替换为团队真实标签；与《自托管 Runner 清单》中的并发与密钥隔离条款一并评审。
# 例：GitHub Actions 选择 runner（概念示意；按组织实际 runner 名改写）
jobs:
compile_apac_night:
runs-on: [self-hosted, region-sg, pool-batch, window-utc18-utc06]
steps:
- run: echo "Heavy compile during APAC evening / US morning handoff"
ui_us_west_day:
runs-on: [self-hosted, region-usw, pool-interactive, window-utc16-utc01]
steps:
- run: echo "Simulator / VNC-heavy; do not steal batch pool concurrency"
# 关键：window-* 与 region-* 必须在变更单里同事写明，避免口头约定
注意：「接力」不是让签名证书在未审计的夜间池之间漂流。请把 signing、notary 类标签限制在白名单机，与《多地区公证与分发》系列保持一致。
下列步骤假设你已阅读《多地区节点与租期指南》并确定基线机型；若尚未拆分 Runner 标签，请先回到 Runner 清单补齐。
batch（纯 SSH、可高并发）、interactive（VNC/Simulator 上限低）、signing（白名单、低并发）；写清禁止项（例如 batch 池禁止挂载分发证书）。max-parallel 与每仓库并发；与跨区 Git/Registry 重试参数一起评审，避免「并发升高 → 出口抖动 → 全体重试」的雪崩。下列指标把「接力是否成功」从口号拆成可行动因，可与跨区链路与队列深度并列展示。
工程对齐说明（非实验室跑分，仅运维侧经验区间）：在 2025–2026 周期，跨区团队把「时区窗 + 池标签 + 并发上限」写进同一评审页后，同等核数下常见收益是把空档小时从「肉眼可见」压到「可接受」，并把洪峰排队从「随机爆表」变为「可预测、可加日租对冲」。这与行业对 CapEx→OpEx、按业务节奏弹性用机的讨论方向一致：关键不在多买核，而在把时间维度写进容量模型。
当仓库主区域与开发者区域长期不一致时，接力策略必须与制品就近与数据驻留一起评审；否则会出现「接力省下的 CPU 分钟，被跨洋制品同步吃光」的隐性账单。
碎片化的短租若缺少显式 window 标签、并发合同与退租动作，团队会退化成「谁有空谁跑」：夜间洪峰依旧，白天空档仍在，签名面反而扩大。要把 Apple Silicon 构建写进可评审主链，需要物理机独占、全球多节点可选、租期可按基线 + 峰值组合，并把时区策略与账单放在同一页。
仅依赖「同事互相喊一声」的接力，很难满足可审计密钥边界与可预测出口；对需要把 Runner 放在与主仓一致区域、并在亚太与北美之间灵活切换容量的团队而言，使用具备多地区节点与弹性租期的专业 Mac 云环境，通常比反复更换临时主机更符合生产节奏。MACCOME 在新加坡、日韩、香港与美东美西等提供 Mac Mini M4 / M4 Pro 与灵活租期，便于把 batch 池与 interactive 池落在正确区域并配套磁盘水位；建议先打开公开价格说明与多地区指南，再按 Runner 清单落单。
试点建议：短租两台分别贴近「主仓区」与「开发者密度区」，跑满本节六步 Runbook 的双周复盘，再决定月租/季租与是否扩至 2TB，避免「便宜区 + 口头接力」的长期隐性账单。
常见问题
接力排班会不会与「节点选择成本表」冲突？
不冲突：前者解决时间维度，后者解决空间与机型维度。合并评审时把「窗口 × 区域 × 租期」放在一页。公开价格见 租赁价格说明。
只有 GitHub-hosted 也能用本文吗？
思路可迁移（按小时热力图拆 job），但「租期水分摊」主要作用于自托管与独占物理机；若仍用共享 hosted runner，应把重点放在合并策略与缓存键，而非机器接力。
Simulator 任务可以进夜间 batch 池吗？
不建议。夜间池应默认纯 SSH 与高并发；Simulator 进 interactive 池并限制并发，否则会把 VNC 带宽与 GPU 争用问题扩散到全队。