GitHub Actions Mac Runner 固定还是弹性？2026 年方案

固定 Mac Runner 适合负载稳定、仓库较少且工具链启动成本高的 Xcode CI；发布峰值明显、多仓库共享或隔离要求较高时，应优先考虑临时 Runner。对大多数团队，本周建议先保留一组固定基线节点，再用弹性池吸收可预测的发布峰值，不要一开始就全面改造为纯弹性架构。

这篇文章适合三类人：移动开发团队负责人，想解决发布排队却不愿全年持有闲置节点；DevOps 与平台工程师，需要设计 Runner 注册、路由、隔离和回收；安全或发布负责人，需要判断签名资产能否进入临时节点。

最后更新于 2026 年 9 月 5 日。Runner Scale Set Client 的状态、macOS 支持、ephemeral runner 行为、Runner Group 权限和日志要求，已根据 GitHub 自托管 Runner 参考文档、官方 Runner Scale Set Client 仓库 和相关安全文档复核。

先按负载形态划分：固定基线、临时池，还是双轨

“GitHub Actions Mac Runner 弹性扩容”并不等于把 Mac 主机数量交给 GitHub 自动管理。它更准确的含义是：GitHub Actions 提供队列与 Runner Scale Set API，团队再用自己的基础设施完成 Mac 主机的供应、启动、注册、清理和回收。

GitHub 已确认 Runner Scale Set Client 是一个独立的 Go 客户端，可以连接 Runner Scale Set API，并生成临时 Runner 配置；但截至 2026 年 9 月 5 日，官方仓库仍标注为 Public Preview，接口和示例仍可能变化。它支持构建包含 macOS 在内的自定义弹性 Runner 方案，但并不会自动创建或重装真实 Mac 主机。官方资料已明确区分了客户端能力与底层基础设施职责。

判断时不要从“团队有多少开发者”开始，而要从工作流记录开始。至少提取以下证据：

• 任务从进入队列到开始运行的等待时间；
• Runner 在线、空闲和执行中的时间；
• Xcode、依赖包和构建缓存的保留价值；
• 失败原因是代码、工具链、签名状态，还是节点本身；
• 发布任务与普通测试是否在同一时间段集中出现。

如果日常任务排队很少，但每次版本发布都会突然堆积，永久增加节点通常会制造更多闲置容量。反过来，如果每天都有稳定的构建量，而且 Xcode、模拟器、依赖缓存和内部工具链初始化较慢，纯临时池可能把启动和准备成本重复支付。

决策条件：满足哪一项，就先选哪条路线

• 若仓库数量较少、任务来源可控、日常队列稳定，且工具链缓存需要长期保留，则选固定 Mac Runner。
• 若发布峰值可以提前预测，但平时节点长期空闲，则保留固定基线，并增加预热临时 Runner。
• 若多个仓库共享算力，且仓库信任级别、Xcode 版本或任务类型差异明显，则按隔离边界建立临时 Runner 池。
• 若任务需要长期维护钥匙串、内部网络和专用依赖源，则签名发布可以保留固定节点，普通编译测试分流到临时节点。
• 若团队无法自动完成主机清理、凭据撤销、外部日志保存和异常回收，则先不要启用大规模弹性扩容。
• 若弹性控制面发生故障仍必须维持关键发布能力，则至少保留一组固定基线节点。

日常构建稳定时，固定节点的优势不只是省事

固定 Runner 的价值在于状态可以被维护，而不是简单地“机器一直开着”。对于单仓库或少量私有仓库，开发团队可以提前安装指定版本的 Xcode、Ruby、Node.js、依赖管理器、模拟器运行时和内部命令行工具，避免每次临时启动都从干净环境重新准备。

这对 Xcode CI 尤其重要。编译测试、UI 测试和归档发布并不一定具有相同的环境需求。固定节点可以保留稳定的派生数据、依赖缓存和诊断工具，但这些状态也会带来隐性成本：缓存可能过期，旧工作区可能残留，钥匙串可能被错误复用，Runner 软件和 Xcode 更新还需要维护窗口。

固定方案成立，至少要满足三个条件：

1. 任务主要来自受控的私有仓库，不能让不可信的代码随意进入高权限节点；
2. 工作流的日常排队波动较小，新增节点不会只解决少数发布日问题；
3. 团队已经定义维护窗口、节点下线方式和故障备用路径。

GitHub 的自托管 Runner 参考文档指出，匹配标签和组的 Runner 如果没有在线空闲节点，任务会继续排队；排队超过 24 小时后才会失败。如果 Runner 接收任务后在 60 秒内没有接手，任务会重新进入队列。自托管 Runner 路由规则 说明了为什么“节点在线”不等于“任务已经可靠接管”。

所以，固定 Runner 仍然要设置仓库访问边界、维护窗口和备用节点。最容易被忽略的错误是：把一台包含签名凭据的固定节点同时开放给测试仓库、实验分支和发布仓库。固定并不代表安全，长期在线反而意味着残留状态有更长的暴露时间。

发布峰值明显时，先区分“临时排队”与“长期基线”

版本发布、集中合并和大规模回归测试会制造明显峰值，但峰值本身不能直接证明需要更多常驻 Mac。需要先把任务分成两类：

• 基线任务：每天持续发生的编译、单元测试、静态检查和少量归档；
• 突发任务：版本候选验证、集中合并后的全量测试、多个渠道同时打包。

如果基线任务已经让固定节点大部分时间处于忙碌状态，增加常驻 Runner 可能合理。如果基线很轻，只有发布窗口出现短时排队，则可以比较预热临时 Runner 与按队列信号启动节点。

这里的关键不是“弹性池能否最终扩出来”，而是节点能否在峰值结束前吸收排队。至少要验证四个时间点：

1. 队列信号出现后，供应系统多久开始创建或启动 Mac；
2. Mac 主机启动后，多久能安装或确认 Runner 配置；
3. Runner 注册后，多久能被目标工作流正确路由；
4. 任务结束后，多久完成注销、清理和回收。

没有这些记录，所谓弹性扩容只是架构图上的箭头。特别是 Xcode 发布高峰，如果节点准备时间接近峰值持续时间，临时租用 Mac 也可能来不及解决排队；此时更适合让固定基线承接关键发布，把弹性节点用于可延迟的测试矩阵。

这张表只能用于初筛，不能替代真实工作流演练。我们建议至少选择一次普通提交、一次集中合并和一次发布候选流程，分别记录排队、节点上线、执行、注销和异常回收结果。

多仓库共享时，先做 Runner Group 和标签隔离

多个仓库共享 Mac 算力时，隔离不能只依靠 --ephemeral。还需要同时处理仓库路由、主机清理、缓存范围、凭据生命周期和日志留存。

GitHub 的 Runner Group 可以限制哪些仓库能够访问一组 Runner；标签则可以进一步表达 macOS、Apple Silicon、Xcode 版本或任务类型。工作流只有在组和标签都匹配时，才会把任务路由到符合条件的节点。Runner Group 权限说明 建议将访问范围明确限定，而不是让所有仓库共享默认池。

可以按下面的方式建立虚构的组织级划分：

• mobile-trusted：只允许发布仓库访问，处理签名归档；
• ios-build-arm64：用于普通 Apple Silicon 编译和测试；
• legacy-xcode：承载旧版本 Xcode 的兼容性任务；
• untrusted-validation：只运行经过限制的私有验证任务，不注入发布凭据。

标签必须反映真实节点属性。官方文档提醒，使用配置脚本手动添加默认标签时，GitHub 不会验证该标签是否真的对应操作系统或架构。标签管理文档 说明了这一边界。也就是说，标签写成 Apple Silicon 不代表主机真的运行在 ARM64 上，平台团队仍需在节点启动时做本地校验。

ephemeral runner 注销，不等于 Mac 主机已经清理

这是弹性 Mac 架构中最容易被误解的部分。

使用 --ephemeral 注册后，GitHub Actions 服务会在 Runner 完成一个任务后自动注销该 Runner。官方建议团队在注销之后自行执行清理，例如删除工作区、清除临时文件、撤销临时凭据，或直接销毁整台主机。自托管 Runner 自动扩容说明 明确指出，Runner 注销动作与主机清理动作不是同一个过程。

因此，验收时不能只看 GitHub 控制台里 Runner 是否消失，还要检查：

• 工作区、派生数据和依赖缓存是否已删除；
• 临时钥匙串、证书和配置文件是否已撤销；
• SSH 密钥、云端令牌和内部网络会话是否已失效；
• 主机磁盘快照、备份和日志中是否残留敏感数据；
• 主机异常关机时，清理流程是否仍能执行；
• 外部日志是否保存了任务失败前后的 Runner 状态。

GitHub 要求将 ephemeral Runner 的应用日志转发并保存在外部存储中，否则节点销毁后可能无法诊断失败原因。Runner 监控与故障排查文档 给出了 _diag、Runner_ 和 Worker_ 日志的位置与用途。

签名发布应与普通编译测试分流

包含钥匙串、证书、内部依赖源或专用网络连接的任务，不适合直接套用普通临时节点模式。

固定节点适合维护复杂状态，例如企业内部依赖、专用网络访问、签名工具链和发布审计。但固定节点必须收紧任务来源，只允许指定仓库、受保护分支和经过审批的环境进入。GitHub 的安全使用指南明确提醒，自托管 Runner 可能被工作流中的不可信代码持久性攻陷，尤其不应把高权限 Runner 暴露给公共仓库或不受控的拉取请求。自托管 Runner 安全使用参考 提供了相关风险说明。

临时节点则更适合普通编译、单元测试、UI 测试和不包含长期签名资产的验证流程，但前提是凭据可以重复注入、任务结束后能够撤销，并且主机可以可靠回收。不要把“临时注册”误认为“自动安全清理”。

建议把流水线拆成两条路由：

• build-test：使用 Apple Silicon 临时节点，允许弹性扩容，不注入发布证书；
• release-sign：使用受限固定 Runner Group，绑定保护环境和人工审批；
• post-release-verify：再次回到临时节点，验证产物和安装流程。

这样做的目的不是把所有风险消除，而是避免普通测试任务与高权限签名任务共享同一台长期运行的 Mac。

Runner Scale Set Client 接入远程 Mac 时，团队仍需拥有基础设施控制面

截至本文更新日期，官方资料确认 Runner Scale Set Client 可以用于构建包括 macOS 在内的自定义弹性 Runner 方案；但客户端只负责与 Scale Set API 对接、生成临时配置和管理消息会话，不负责提供真实 Mac 主机。

这与 Actions Runner Controller 的 Kubernetes Runner Pod 模式不能直接等同。官方文档将 ARC 描述为 Kubernetes 操作器，用于编排和扩缩容自托管 Runner；对于真实 Mac 主机，团队仍要自己处理主机电源、网络、镜像、系统初始化、远程访问和销毁流程。Actions Runner Controller 官方概念说明 说明了其 Kubernetes 运行模型。

接入远程 Mac 时，最小验证链应当是：

1. 模拟一个工作流队列事件，确认扩容控制面可以收到需求；
2. 由团队自己的基础设施供应一台可用 Mac；
3. 在不暴露真实令牌的情况下生成单次 Runner 配置；
4. 让目标工作流通过 Runner Group 和标签路由到该节点；
5. 任务完成后确认 Runner 注销；
6. 确认 Mac 主机完成清理、关机或销毁；
7. 人为制造启动失败、注册失败和任务中断，验证异常回收；
8. 从外部日志中还原整个任务生命周期。

GitHub 的官方添加 Runner 文档指出，注册配置使用的是自动生成的限时令牌，令牌有效期为 1 小时；示例中的令牌、账户和主机名应全部使用占位符，不能把真实注册信息写进文章、脚本仓库或日志。添加自托管 Runner 文档

故障降级决定了双轨方案是否值得上线

纯弹性架构最危险的地方，不是扩容失败一次，而是失败后没有可用的替代路径。以下情况都应提前设计：

• Runner Scale Set Client 或扩容控制面不可用；
• 远程 Mac 启动失败或无法加入专用网络；
• Runner 软件更新异常；
• 注册成功但标签或 Runner Group 路由错误；
• 任务结束后主机没有回收；
• 外部日志系统不可用；
• 发布签名任务已经进入队列，但临时节点迟迟未就绪。

对关键发布任务，建议保留固定基线节点，并设置清晰的最大等待时间。超过阈值后，不要无限重试扩容；应暂停新增节点、保留当前排查证据，并由平台负责人决定是否人工接管。

最终的选择可以用一次真实演练完成，而不是用抽象容量公式决定：

• 普通提交连续运行，观察固定基线是否足够；
• 集中合并运行，验证临时池能否在峰值窗口内上线；
• 发布候选运行，确认签名任务不会被错误路由；
• 主动关闭一台弹性 Mac，检查注销、日志和回收；
• 暂停扩容控制面，确认固定节点仍能完成关键发布。

如果固定节点在日常一直空闲，且发布峰值又能被提前识别，继续增加常驻 Mac 并不划算；如果弹性池无法在发布窗口内可靠供应，纯临时方案也只是把排队问题转移到了节点启动阶段。

给团队的最终选择：先保留基线，再用试跑决定弹性边界

固定方案的真实缺点是容量闲置、维护窗口和残留状态长期存在；纯弹性方案的缺点是主机供应链复杂、凭据回收容易遗漏、日志与故障排查成本更高。对需要 Xcode 签名的团队，临时节点还会增加内部网络、钥匙串注入和发布审计的设计工作。

因此，除非团队已经具备成熟的 Mac 主机编排与回收能力，否则不建议把全部 CI 迁移到纯弹性池。更稳妥的路径是：用固定 Runner 承接日常和关键发布，用临时 Runner 承接可预测峰值与普通测试，再根据真实队列和回收记录逐步扩大弹性范围。

如果试跑结果显示全年并不需要持有全部 Mac 节点，可以先查看 JexMac 的 Mac 租赁方案，再结合 远程 Mac 使用与连接帮助 评估临时节点是否适合接入 CI。对于需要按周、按月或按季度获得真实 Mac 主机的团队，远程租赁比临时采购硬件更容易配合发布周期；但长期稳定重负载、必须掌握物理接口，或需要完全自主管理硬件的团队，仍应认真比较自购 Mac mini 与自建机房方案。