GitHub Actions 的托管 Runner 单个任务最多执行 6 小时；超过限制，任务会终止失败。GitHub Actions 使用限制文档 因此，GitHub Actions macOS Runner 怎么选，先看你的构建负载和维护能力：低频、标准环境优先托管；需要定制并长期复用构建环境，或必须控制任务运行方式，再评估自托管 Mac Runner。本周先记录各类构建的运行时间、并发需求和失败原因，不要只凭一次慢构建就迁移。
谁该看这篇：偶尔构建 iOS 应用、希望少管 Runner 基础设施的独立开发者。
已经搭好 GitHub Actions、需要固定 macOS 工具链或更可控环境的开发者。
准备把个人构建流程扩展成长期自动化发布流程的小团队。
先按工作负载划清 Runner 管理边界
“托管还是自托管”是在选谁管理 Runner 环境，不是在选“云端还是本地”。自托管 Runner 可以部署在你管理的机器上，也可以运行于远程 Mac 环境。无论在哪儿，关键区别都是：谁负责操作系统、工具链、Runner 在线状态和隔离策略。
托管 Runner 的典型优势，是按工作流标签使用由平台管理的环境；自托管 Runner 的优势，则是你可以控制环境并反复使用。但“持续在线”不是自托管机器的默认保证：机器关机、Runner 进程停止或网络不通时，任务无法被它接走。GitHub 文档说明，没有匹配的在线空闲 Runner 时，自托管任务会留在队列中；队列超过 24 小时会失败，具体规则可查看自托管 Runner 参考文档。
| 评估指标 | 托管 macOS Runner | 自托管 Mac Runner |
|---|---|---|
| 构建频率与并发 | 低频、标准化任务较容易直接开始；并发上限与账户计划和 Runner 类型有关，需查当前限制 | 适合重复使用固定环境；要自行保证机器容量与可用性，单台机器不等于多任务并行 |
| 工具链控制 | 选标签与镜像；预装软件可能变化，需按当前镜像说明核验 | 可按项目管理 macOS、Xcode 与依赖版本；更新和兼容问题也由你处理 |
| 环境复用 | 每个托管任务使用新实例，不能依赖上次任务留下的本地状态 | 可保留工具与缓存，但要设计清理策略，避免旧文件影响下一次构建 |
| 可用性与恢复 | 平台管理机器；仍受任务时限、并发和平台规则约束 | 机器与 Runner 进程要有人监控；离线时需处理排队、恢复和重试 |
| 安全边界 | 仍要保护工作流密钥与发布权限 | 还需评估 Runner 能访问的仓库、内部网络和本地文件，并隔离不可信任务 |
表格是责任边界的比较，不是性能或价格保证。托管 Runner 标签、镜像和限制会更新；选择前对照GitHub 托管 Runner 当前参考表，不要把 macos-latest 当作永远固定的系统或 Xcode 版本。
第一步：用构建记录判断频率、并发和排队成本
先按工作流拆开记录，而不是把所有 CI 任务合并成一个“构建量”。至少分成拉取请求检查、主分支验证、签名归档和发布上传。给每类任务记下触发频率、运行时长、同时触发的数量、可接受排队时间，以及失败后需要人工介入的次数。
托管 Runner 的并发上限按计划和 Runner 类型而异。GitHub 当前限制文档列出了标准托管 Runner 的并发规则，也指出 macOS 任务有单独的并发上限；具体值应以Actions 限制页面为准，而不是借用其他套餐或历史文章中的数字。不要据此推测具体排队时长：把工作流真实的等待时间从运行日志中取出来，再判断瓶颈是可用并发、任务耗时，还是依赖安装和缓存。
✅ 低频构建、可接受偶尔等待：先用托管 Runner，避免为很少发生的任务承担常驻机器维护。
⚠️ 经常同时触发多个构建：先核对现有并发限制和实际队列记录，再比较增加托管并发与自托管容量的成本。
✅ 构建重复、环境准备占比高：测量依赖安装和环境恢复耗时；如果固定环境能解决明确问题，再评估自托管，而不是默认认为复用缓存就一定更快。
成本也要按工作流逐项比较。托管方案记录计费分钟、免费额度使用情况，以及不同 macOS Runner 标签的当前计费规则；自托管方案则记录机器租用或折旧、持续运行成本、维护工时、故障恢复和备用能力。用同一周期、同一批构建记录计算总成本，不要拿单次执行费直接对比整台机器的价格。
第二步：把 Xcode 和依赖环境要求写成验收条件
先列出构建真正需要的环境：macOS 版本、Xcode 版本、目标架构、模拟器运行需求、签名工具、包管理依赖，以及是否需要特定网络资源。然后核对托管镜像是否覆盖这些要求。GitHub 托管镜像可能预装多种工具，但标签对应的镜像内容与软件版本应查当前说明；latest 适合愿意跟随更新的工作流，不适合作为隐式固定版本策略。
自托管适合有明确环境控制需求的情况，例如必须长期保留某个工具链组合，或者团队的构建步骤依赖特定机器设置。代价是环境漂移也由你负责：macOS 或 Xcode 更新后，原来通过的构建可能失败；Runner 软件自动更新也不会替你更新操作系统和其他软件。自托管 Runner 运维说明特别提醒，Runner 程序的自动更新不包括系统和其他软件更新。
版本也要落实到工作流，而不是只写在团队口头约定里。托管环境可采用明确的 macOS 标签，并在构建日志中核对实际 Runner；自托管环境则要通过 Runner 标签和内部验收记录说明它适用的工具链。runs-on 可以依据 Runner 标签或组路由任务，使用多个标签时，Runner 必须同时满足这些标签。工作流语法文档解释了这种选择方式。
第三步：把维护责任算进持续可用性
托管不代表构建永不失败，只是平台承担 Runner 机器管理。你仍需维护工作流、依赖和签名流程，关注任务时限、并发限制、缓存与产物管理。托管 Runner 使用新实例执行任务，所以不能假设上一轮安装的本地工具或文件会自然保留。需要持久化的内容应放在明确的缓存、产物或其他存储流程中。
自托管需要额外接手机器运行状态、网络连通、磁盘空间、系统与工具更新、Runner 软件更新、日志检查和故障恢复。把责任写进值班流程：谁发现 Runner 离线，谁恢复服务；排队任务何时重试；发布被中断时如何判断是否已经完成上传。GitHub 还说明，自托管机器需能与 GitHub Actions 通信，并满足工作流所需的网络访问条件。把网络白名单、代理或内部资源访问纳入验收，不要只确认网页能打开。
⚠️ 自托管 Runner 自动更新 Runner 程序，不等于整台 Mac 自动完成安全更新、Xcode 更新和磁盘清理。若你关闭 Runner 自动更新，必须安排自己的版本更新流程；GitHub 文档说明，更新延误可能导致任务不再被调度。请按当前自托管 Runner 更新规则核对策略。
一个常见场景是：个人项目的拉取请求检查每天只偶尔触发，但每次发布都依赖固定 Xcode 和签名环境。此时不必全量迁移。让普通测试继续使用托管 Runner，只把经过权限审核的归档与发布任务路由到受控 Runner；这样能把自托管的维护范围限制在确实需要的环节。
第四步：单独评估凭证、任务隔离和网络权限
iOS 发布流程会接触签名材料、证书或发布凭证。无论选哪种 Runner，都应只向需要的工作流和步骤提供所需密钥，缩小仓库、环境和令牌的访问权限。检查运行任务的代码来源：来自外部贡献者的变更，不应因为构建方便就获得发布凭证或访问内部资源的能力。
自托管环境尤其要盘点 Runner 可以访问什么：仓库、内部服务、共享目录、网络出口和机器上的残留文件。GitHub 的安全指引要求对使用自托管 Runner 的不可信任务做好环境限制，并避免跨任务复用可能留下风险的环境；对于公开仓库的外部拉取请求，也要审慎评估是否让它们在自托管机器上运行。可参考安全使用拉取请求工作流的官方说明和自托管 Runner 组的访问建议。
风险不只来自密钥泄露。若一个任务能改写机器上后续任务会读取的文件、缓存或工具配置，问题可能延续到下一次构建。对发布任务使用独立权限边界，审查任务执行后的清理方式；不要把“只有一个开发者”当成可以忽略隔离的理由。
第五步：按条件选择，并让迁移可回退
按下面的条件分支做决定：
- 若构建低频、使用标准 macOS 环境，且你希望少维护机器：先选托管 Runner。记录工作流的真实队列和运行数据，遇到限制再调整方案。
- 若你必须固定或复用定制环境，并能负责更新、清理与故障恢复：再评估自托管 Mac Runner。先确认它符合工作流所需的系统、工具链、网络和访问边界。
- 若只有签名发布任务需要特殊控制：拆分工作流，先保留托管检查任务，只把需要特定环境的任务迁过去。
- 若目前没有人负责 Runner 离线、密钥权限和系统维护：暂不迁移。继续使用托管 Runner，直到团队明确维护责任。
开始迁移时，先让不使用发布密钥的测试任务跑新 Runner。逐项核对构建结果、工具版本、产物和清理行为；再迁移签名归档任务，最后才切换正式发布。保留原有托管任务作为回退路径，观察一段真实发布周期后再决定是否扩大迁移范围。用标签或 Runner 组路由不同工作流，相关设置可参考官方 Runner 选择说明。
对于远程 Mac 构建，验收也不要止于“能连上机器”。逐项确认工作流标签是否匹配、macOS 与 Xcode 是否满足项目要求、Runner 进程能否稳定连接、磁盘清理由谁负责，以及签名任务是否与普通测试隔离。你可以查看 MangoVM 的 Mac mini 环境页面和数据保护说明，再按自己的工作流核对环境与安全条件；页面信息不等同于对特定 Runner 兼容性或性能的保证。
常见问题
托管与自托管 Runner 的区别只是机器归属吗？
不是。更重要的是环境生命周期与管理责任。托管 Runner 按标签使用平台管理的环境；自托管 Runner 则由你管理底层机器、系统软件、网络和访问边界。自托管可以是你自己的 Mac，也可以是远程 Mac 环境，不等于必须购买并摆放一台本地 Mac。
个人 iOS 项目适合直接上自托管 Mac Runner 吗？
先看维护能力，不要只看项目规模。构建不频繁、没有特殊环境要求时，托管 Runner 通常是更简单的起点。只有当固定工具链、环境复用或运行控制带来可验证的收益，并且有人负责更新、清理和故障恢复时，再考虑自托管。
自托管 Runner 的日常维护会落到哪些事情上？
需要持续关注机器与网络是否可用、Runner 是否正常连接、操作系统和开发工具是否更新、磁盘空间是否充足，以及任务结束后是否清理残留。还要设定故障发现、任务重试和发布恢复责任。Runner 软件自动更新不应被当作整台 Mac 的完整维护方案。
什么情况下应该把构建迁移到远程 Mac？
当本地电脑不适合常驻运行构建、团队需要固定的 macOS 工具环境，或需要把发布任务与个人设备分离时，可以评估远程 Mac。先迁移不持有发布密钥的验证任务，确认版本、网络、权限和清理流程后，再逐步移动签名与发布任务。若这些条件无法确认，就先保留托管 Runner。
如果你的方案现在是把构建塞进个人 Mac，常见代价是设备离线会中断任务、工具链容易随日常使用变化、开发机同时承担发布与开发风险；若改用自行管理的专用机器，则还要承担更新、清理和故障恢复。需要固定环境但不想为此购置并长期照看实体 Mac 时，可以把 MangoVM 的远程 Mac 作为自托管 Runner 候选，再按你的 macOS、Xcode、访问权限与维护要求逐项验收；若构建长期高负载或必须直接连接特定物理设备，也应先评估自购 Mac 是否更合适。
常见问题
GitHub Actions 托管 macOS Runner 和自托管 Runner 的差别，主要在哪里？
差别不只是机器由谁提供，而是谁管理运行环境。托管 Runner 通常按所选标签启动由 GitHub 管理的干净环境，适合标准化构建；自托管 Runner 则由你或受托环境管理，能复用工具链并控制机器访问，但操作系统、磁盘清理、Runner 在线状态和安全隔离也要纳入自己的维护流程。
个人 iOS 项目什么时候值得使用自托管 Mac Runner？
如果项目构建不频繁、使用标准 Xcode 环境，优先从托管 Runner 开始通常更省心。只有当你确实需要固定且反复复用的环境、特殊工具链、可控网络边界，或构建排队和成本记录显示托管方式不适合时，才评估自托管；迁移前还要确认自己能持续处理更新、清理和故障恢复。
GitHub Actions 自托管 Runner 需要自己维护哪些内容？
你需要维护承载 Runner 的 Mac、macOS 与开发工具、Runner 软件状态、可用空间、网络连接和权限边界。还要考虑任务结束后的工作区与缓存清理、机器离线时的任务处理，以及密钥如何进入发布流程。Runner 程序可自动更新，不代表系统和 Xcode 等软件也会自动维护。
什么时候适合把 iOS 构建迁移到远程 Mac？
当本地 Mac 不适合作为常驻构建机、团队需要持续访问一套可控的 macOS 工具链，或你希望把个人电脑从发布任务中解耦时，可以评估远程 Mac。先让不接触发布凭证的测试任务验证标签、网络、依赖和清理方式，再迁移签名与发布任务；实际环境是否合用，要按工作流要求逐项核验。
给 GitHub Actions 配一台固定的 macOS Runner
用 MangoVM 独享 Apple Silicon 物理 Mac mini 部署自托管 Runner，让工具链、依赖与缓存留在稳定环境中。