2026 年 11 月 2 日是 GitHub 公告的 macOS 14 Runner 镜像退役日期。还在使用相关标签的工作流，不要等到退役后再换：先并行验证受支持的托管 Runner 标签，按真实项目完成构建、测试、签名与发布验收，再切换生产配置；只有需要持续控制主机或固定环境时，才评估远程 Mac。(GitHub 官方退役公告)
谁该看这篇：仍使用 macOS 14 标签的 iOS/macOS 开发者，需要核对项目与新版系统、Xcode 工具链的兼容性。
CI 工程师：需要判断依赖、缓存和产物是否随 Runner 改变。研发平台负责人：需要确定托管 Runner 是否满足工作流的控制与运维要求。
最后更新于 2026 年 10 月 7 日；退役日期、标签及 brownout 信息已按 GitHub 公告核实，候选镜像与软件清单以官方 Runner 镜像仓库为准。发布前请再次核对公告是否有更新。
通知发现与影响盘点
macOS 14 Runner 退役影响的不只是写着 runs-on: macos-14 的主构建任务。GitHub 公告列出的受影响标签包括 macos-14、macos-14-large 和 macos-14-xlarge；在退役前的 brownout 窗口，使用这些标签的任务会暂时失败，公告还提示过渡期可能降低 Runner 容量、延长排队。
| 窗口 | 对工作流的影响 |
|---|---|
| 2026 年 10 月 5 日 14:00 至 10 月 6 日 00:00 | 已结束；可回查该时段相关任务是否失败 |
| 2026 年 10 月 12 日 14:00 至 10 月 13 日 00:00 | 计划中的暂时失败窗口 |
| 2026 年 10 月 16 日 14:00 至 10 月 17 日 00:00 | 计划中的暂时失败窗口 |
| 2026 年 10 月 19 日 14:00 至 10 月 20 日 00:00 | 计划中的暂时失败窗口 |
| 2026 年 10 月 23 日 14:00 至 10 月 24 日 00:00 | 计划中的暂时失败窗口 |
| 2026 年 10 月 26 日 14:00 至 10 月 27 日 00:00 | 计划中的暂时失败窗口 |
| 2026 年 10 月 29 日 14:00 至 10 月 30 日 00:00 | 计划中的暂时失败窗口 |
| 2026 年 10 月 30 日 14:00 至 10 月 31 日 00:00 | 计划中的暂时失败窗口 |
以上退役日期、受影响标签和 brownout 时段以GitHub 官方公告为准；如果公告有调整，应按最新信息重新安排迁移。
先从仓库工作流文件和可复用工作流中查找受影响标签，再记录每个 Job 的触发分支、触发事件、用途和负责人。不要只盘点主分支：发布、定时任务、手动触发、合并请求和专用归档任务，可能分别定义了 Runner。
可按这个清单划分影响范围：
- ✅ 搜索所有
runs-on中的macos-14、macos-14-large、macos-14-xlarge。 - ✅ 检查复用工作流、矩阵变量和组织级模板，确认标签是否经变量间接引用。
- ✅ 标明哪些 Job 会生成发布归档、签名产物或提交商店的构建。
- ✅ 给每个受影响 Job 指定迁移负责人和生产切换审批人。
基线冻结与差异记录
并行迁移前，先保存 macOS 14 上当前可用的构建基线。否则，系统镜像、Xcode、SDK、依赖锁文件或缓存发生变化时，失败原因会混在一起，难以区分是代码回归还是环境差异。
至少记录当前工作流的 runs-on 标签、Xcode 选择方式、部署目标、依赖安装命令、构建参数和测试目标。还应保留代表性 Job 的日志、测试结果、归档检查方法，以及发布链路中用于确认签名与产物的证据。工作流通过 runs-on 选择 Runner；标签对应执行环境，不是项目的部署目标。(GitHub Actions 工作流语法文档)
基线记录应能让另一个工程师复跑，而不只是截取一次绿色状态：
- 固定同一代码提交，并记录依赖锁文件是否有变化。
- 保存
xcodebuild -version、xcode-select -p、sw_vers与uname -m的输出。 - 记录模拟器设备、Scheme、构建配置、测试集合及归档命令。
- 明确如何检查
.xcarchive、导出的应用包、签名信息和发布阶段结果。 - 保存用于对照的日志与测试报告，确保迁移后的结果能与原基线逐项比较。
这里要把 Xcode 版本、镜像系统版本、架构、项目部署目标和工作流自身参数分开记录。部署目标写在项目配置中；它不能证明 Runner 上实际选择了哪个 Xcode，也不能证明模拟器和签名步骤已在新环境验证。
GitHub Actions macOS 14 Runner 迁移的并行试跑
首次试跑应隔离生产工作流：在迁移分支或专门的并行 Job 中运行候选标签，保留原 macOS 14 Job 作为基线，先比较同一代码提交。不要为了图省事，一开始就把生产 YAML 全部替换。
GitHub 公告建议迁往 macos-15、macos-15-xlarge、macos-latest（即 macos-26）或 macos-latest-xlarge（即 macos-26-xlarge）。标签与镜像软件清单应以官方 Runner 镜像仓库为准；可以分别核查 macOS 15 镜像清单和 macOS 26 镜像清单，不要仅凭标签名称推断系统、架构和预装工具。
候选标签应按项目约束选择，而不是默认挑版本号更高的镜像。比如需要保留某个 Xcode 版本时，先核查目标镜像的 Xcode 列表及选择命令；如果工作流依赖 Intel 架构、固定 UDID 或第三方 Action 的架构兼容性，也要先验证这些条件。GitHub 文档指出，部分社区 Action 可能不兼容 ARM64，而 ARM64 托管 Runner 没有静态 UUID/UDID；遇到这类依赖时，不能只看构建步骤是否通过。(GitHub 托管 Runner 文档)
并行试跑可按以下顺序操作：
- 在新分支或独立 Job 中，只替换候选
runs-on标签，保持命令、提交和依赖声明不变。 - 在任务开始处输出系统、架构、Xcode 路径与版本，确认实际运行环境。
- 对比依赖安装、编译、测试、归档各阶段的日志，不要只比较最终状态图标。
- 保存测试报告和构建产物，确保能复查差异。
- 记录候选标签、提交号、负责人、失败阶段和下一步处理人。
依赖差异定位与修复
新 Runner 失败时，先把错误归到具体阶段，再决定改什么。系统工具变化、依赖解析、缓存命中、脚本对目录或默认工具版本的假设、架构条件，都会导致表面相似的失败；直接固定全部依赖，或清空所有缓存，可能掩盖真正原因，也会增加后续维护负担。
建议按失败日志从前往后排查：
- 系统工具或 Xcode：查看实际选择的 Xcode、SDK、命令行工具和编译器，再核对候选镜像清单。若工具缺失或版本不合，先判断是否支持显式选择、项目本身是否要求特定版本。
- 依赖解析：比较锁文件、包管理器版本、解析参数和拉取结果。只有证据指向依赖差异时，才调整版本约束或解析策略。
- 缓存：检查缓存键是否包含系统、架构或依赖锁文件信息。缓存可按精确键匹配，也可使用前缀回退；迁移时要确认旧缓存没有让新环境复用不适用的内容。先缩小缓存范围或调整键，再考虑清除特定缓存。(GitHub Actions 依赖缓存文档)
- 脚本假设：检查绝对路径、默认 Shell、工具别名、文件权限和大小写敏感处理，确认脚本使用的是明确路径与版本，而不是偶然依赖旧镜像状态。
- 架构或第三方 Action：确认依赖二进制、Action 和工具链是否支持候选架构；不要把架构不兼容误当成 macOS 版本问题。
每次只改一个有证据支持的因素，并复跑同一提交。这样才能判断修复是否有效，也能避免依赖更新、缓存失效和 Runner 变化同时发生后，无法解释结果。
构建交付验收与职责边界
迁移验收需要覆盖项目真实发布链路，而不是用空项目或单独的 xcodebuild build 代替。按项目实际情况验证目标 Scheme、关键测试、归档、签名、导出以及上传或交付步骤，并把“构建通过”和“发布链路通过”分开记录。
| 验收环节 | 通过证据 | 不应替代它的检查 |
|---|---|---|
| 环境确认 | 日志记录实际系统、架构、Xcode 路径与版本 | 只看 runs-on 标签 |
| 构建与测试 | 同一提交下，目标 Scheme 与项目规定的测试通过 | 只跑一个空工程或单个编译命令 |
| 归档与签名 | 归档结构、导出结果和签名检查符合项目发布要求 | 把编译成功记作签名已验收 |
| 交付 | 发布或上传步骤按项目要求完成，并留有结果记录 | 仅确认产物文件存在 |
如果涉及真机、特定设备识别、图形会话或交互式调试，应把托管 Runner 的 CI 职责与需要真实设备或可持续桌面会话的验证分开。ARM64 托管 macOS Runner 不提供静态 UUID/UDID；因此，依赖固定设备标识的签名或测试环节必须单独确认方案，而不能从模拟器测试成功推导出真机链路已经通过。(GitHub 托管 Runner 文档)
生产切换、回退与方案决策
只有候选标签上的关键任务通过，且项目责任人确认构建、测试和发布证据齐备后，才切换生产工作流。切换前留下原标签、原配置和基线记录；出现关键测试失败、签名异常、归档不一致或发布阻塞时，暂停扩大切换范围，按预先确定的回退条件处理。不要把“回退到 macOS 14”当作长期兜底：该镜像已公告将退役，回退只能是有时间边界的迁移控制措施。
对照表可帮助平台团队区分标签选择、工作流验收和主机方案，不要把它们混成一个决定：
| 选择对象 | 适用判断 | 迁移时的核验重点 |
|---|---|---|
macos-15 或 macos-15-xlarge |
项目已验证该镜像中的系统、架构与工具链满足要求 | 核对镜像清单、实际 Xcode 及工作流结果 |
macos-latest 或 macos-latest-xlarge |
项目希望采用公告建议的最新 macOS 标签，且能接受持续验证标签所指向的镜像变化 | 把镜像更新纳入持续回归，勿把 latest 当作永久固定版本 |
| 远程 Mac 自托管 Runner | 有固定环境、持久状态、主机控制或特定网络需求，并愿意承担维护 | 评估主机在线、Runner 注册、网络访问、凭据隔离及故障恢复 |
GitHub 的自托管 Runner 文档要求 Runner 能与 GitHub Actions 通信，并具备工作负载所需资源；这意味着自托管并非“换个标签”就结束，团队还要负责主机与 Runner 运维。(GitHub 自托管 Runner 文档) 对需要评估远程 Mac CI 的团队，可以先了解 RUVCLOUD 的远程 Mac 服务，再对照方案与计费信息核实实际可用能力；本文没有本站配置、价格或节点数据，不据此推断具体服务规格。
决策条件：
- 若候选托管标签上的项目构建、测试、签名与发布链路均通过，且无需固定主机状态，就继续使用托管 Runner，并保存验收记录。
- 若问题仅是 Xcode、SDK、依赖或缓存差异，就先修复差异并复测，不要仅因首次失败就迁移整套 CI。
- 若必须长期固定系统环境、维护持久状态、使用特定网络或掌握主机级控制权，就评估远程 Mac，并把在线维护、凭据安全与故障恢复列入运维责任。
- 若真机或图形会话是验收前提，就单独安排相应测试环境；不要默认托管 Runner 或远程 Mac 能替代真实设备验证。
常见迁移问题
macOS 14 Runner 退役前怎样安排验证？
先完成标签盘点与基线记录，再用隔离 Job 对候选标签运行同一提交。按 brownout 日期安排回归和责任人值守；每轮保存日志与产物证据，若关键签名或发布环节未通过，就暂停生产切换并修复原因。官方公告若调整窗口，以最新版本为准。
切换到 macOS 15 或 macOS 26，最容易混淆什么？
Runner 标签、操作系统版本、架构、Xcode 与项目部署目标是不同层次。用镜像清单确认候选 Runner 实际提供的软件，再从 Job 日志记录实际选择的工具链；不要把部署目标仍然兼容，误认为整个构建、测试和签名环境都与旧 Runner 一致。
什么情况下托管 macOS Runner 不够用？
如果需要固定主机环境、持久化状态、特定网络访问或更细的主机控制，就比较远程 Mac 自托管方案，并评估团队维护 Runner 的能力。若工作流只是常规构建与测试，应先以托管 Runner 完成迁移；是否值得自托管，取决于真实需求，不应只凭“环境可控”这一点做决定。
迁移验收成功，是否等于生产发布成功？
不等于。构建和测试通过只能说明相应步骤完成；发布链路还要按项目要求检查归档、签名、导出以及上传或交付结果。将构建验收与发布验收分开留档，才能在生产出错时确定故障落在哪一段。
托管 Runner 适合希望减少主机维护的标准 CI，但其镜像标签与软件清单需要持续核对；若工作流还要求固定环境、持久状态或主机级控制，就要承担自托管的在线维护、网络和安全责任。若项目确有这类需求，可按工作负载评估 RUVCLOUD 远程 Mac；若没有，先完成托管 Runner 迁移和验收，通常更直接。查看 RUVCLOUD 方案与计费信息前，应以页面当前公布内容核实服务范围。