Rosetta 2 何时停止支持？2026 企业 Mac CI 迁移清单

Apple 在 2026 年 9 月 1 日发布的 Rosetta 变更说明中确认：macOS 26.4 及以后版本可能在启动依赖 Rosetta 的应用时显示迁移提醒；macOS 27 是支持 Rosetta 运行 Intel-only macOS 应用的最后一个主要版本。macOS 27 之后，Intel-only 应用不能继续在 Apple Silicon Mac 上依赖通用 Rosetta 运行。具体边界应以 Apple 的 Rosetta 支持公告 和 Rosetta 技术文档 为准。

截至 2026 年 9 月 10 日，macOS 27.0 RC 已于 9 月 9 日发布，但面向公众的正式版本说明仍需继续核对。企业可以把 macOS 27 定义为最后迁移窗口，但不要提前推测 macOS 28 的最终行为、发布时间或例外范围。

你需要特别区分以下四种对象：

• Intel Mac 硬件：无法运行只面向 Apple Silicon 的工具链版本，例如 Xcode 27 的安装与运行要求已经转向 Apple Silicon。
• Intel-only macOS 应用：在 Apple Silicon 上依赖 Rosetta；这是本次 CI 迁移的主要风险。
• Universal Binary：同时包含 arm64 和 x86_64 切片，系统通常在 Apple Silicon 上优先执行 arm64。
• Linux VM 中的 Intel 二进制：macOS 27 将 Intel Linux 二进制翻译能力直接集成到系统，不应简单等同于 Intel-only macOS 应用的 Rosetta 兼容边界。详见 Apple 的 Linux VM 二进制说明。

因此，项目立项结论应写得明确：暂缓无证据的全量升级，冻结新增 x86_64 依赖，建立迁移负责人和兼容池退出日期。

企业 IT 不应只查看“主应用是否能打开”。CI 节点上的依赖通常分散在 Agent、Shell、包管理器、插件、动态库、LaunchAgent、安装脚本和自研工具中。只要其中一个环节拉起 Intel-only 子进程，流水线就可能在升级后失败。

每台构建机至少应建立一份可追溯资产表，字段包括：

• 文件或组件路径；
• 架构结果：arm64、x86_64 或 Universal；
• 被哪个 Job、脚本或插件调用；
• 所属项目与责任人；
• 是否影响测试、归档、签名或发布；
• 可替代版本或重编译计划；
• 原生节点验证证据；
• 兼容池退出日期；
• 回滚条件与审批人。

盘点时不要跳过以下位置：

• CI Agent 和 Runner；
• /usr/local/bin、/opt 以及自定义工具目录；
• Homebrew、Ruby、Python、Node.js 等包管理器目录；
• Shell、Ruby、Python、Perl 和 Node 脚本调用的外部命令；
• Xcode 插件、构建插件、动态库和 Framework；
• LaunchAgent、LaunchDaemon 与后台守护进程；
• 安装包的前置脚本、后置脚本和安装器插件；
• 自研命令行工具、内部签名工具和发布工具。

基础核查可以从以下最小命令开始：

file /path/to/tool
lipo -info /path/to/binary
uname -m
ps -axo pid,comm
sysctl -n sysctl.proc_translated

file 和 lipo 适合检查文件本身；uname -m 只能说明当前 Shell 的运行环境，不能证明所有子进程都是原生架构。Apple 文档指出，进程可以通过 sysctl.proc_translated 判断是否处于翻译状态，返回值为 0 表示原生、1 表示翻译进程。可参考 Apple 的进程翻译状态说明。

盘点完成后，把结果交给对应负责人签字。IT 负责人的交接条件不是“表格填完”，而是每个高风险组件都有调用关系、责任人和验证任务。

迁移不等于把所有二进制重新编译一遍。你应按组件类型选择替换、重编译或隔离。

原生替换

如果供应商已经提供 arm64 或 Universal Binary，优先使用原生版本。需要同时验证：

• 安装路径是否改变；
• Shell 的 PATH 是否仍指向旧目录；
• CI Agent 是否调用了旧缓存；
• 插件是否加载了错误架构；
• 签名、公证和版本锁定是否仍然有效。

包管理器尤其容易造成“看起来已经升级，实际仍在调用旧路径”的问题。迁移后应在干净节点执行安装，并把最终二进制路径写入构建日志。

自研组件重编译

自研工具可以选择构建 arm64，也可以发布 Universal Binary。Apple 的 Universal Binary 指南明确列出，除了主应用，还要关注 App Extension、插件、Framework、静态库、动态库、命令行工具、守护进程和 Launch Agent。参考 Apple 的 Universal Binary 构建指南。

如果项目链接了第三方库，第三方库也必须提供相应架构。Apple 说明，进程中加载的代码不能混用 arm64 与 x86_64，缺少兼容架构的库会在链接或运行阶段暴露问题。参考 Apple 的 Apple Silicon 迁移文档。

暂时隔离

闭源工具、旧版插件或暂时没有替代版本的组件，应进入例外清单，而不是无限期留在默认流水线中。例外记录至少包括：

• 业务影响；
• 供应商或内部责任人；
• 当前调用的任务；
• 风险等级；
• 临时兼容节点；
• 退出日期；
• 迁移失败时的回滚动作。

任何要求降低系统安全设置、允许不受信任扩展或依赖交互式登录的组件，都不应直接放入生产兼容池。它应进入阻断或限期退出清单。

CI 平台团队的核心任务不是“让两个节点都能跑”，而是证明原生节点可以承接生产任务，并且不会被兼容环境的缓存和变量污染。

建议把节点划分为两个池：

• arm64-native：只运行已经完成原生验证的任务；
• rosetta-compat：只承接仍有明确 x86_64 依赖的任务。

两个池应使用独立标签、队列、缓存目录和依赖安装路径。不要让同一个缓存目录在两种架构之间复用，否则可能出现依赖已安装但架构不匹配、构建脚本误判平台或产物被旧缓存覆盖的问题。

双跑任务应覆盖：

• 代表性 Pull Request；
• 单元测试与 UI 测试；
• Archive；
• 代码签名；
• 公证；
• TestFlight 或内部发布；
• 失败重试；
• 节点重启后的无人值守恢复。

验收时，不要只比较构建是否成功。还应比较产物哈希、签名状态、嵌入 Framework、测试结果、日志告警和失败分类。具体耗时、队列长度和容量结论只能使用企业自己的记录或本站实测，不能从其他机器的公开宣传数据推导。

Xcode 27 已要求运行在 Apple Silicon Mac 上；其 Release Notes 还说明，面向 macOS 27 的构建目标在默认架构设置上会减少对 x86_64 的依赖。你可以将 Xcode 27 Release Notes 作为工具链审核的固定来源，但仍需结合实际项目脚本验收。

很多迁移在开发者终端上成功，却在 CI 中失败，原因通常不在编译器，而在无人值守环境。

安全与发布负责人应单独验证以下边界：

Keychain 与签名

确认原生节点使用正确的 Keychain、证书和 Provisioning Profile。检查解锁动作是否依赖图形化登录，是否能在干净会话中完成签名，是否会把临时密钥写入错误用户目录。

插件与动态加载

Universal Binary 的主程序并不代表所有插件都兼容。某些插件加载器会在启动时寻找固定路径下的 Intel 动态库，导致主任务能够编译，但在测试、归档或发布阶段才失败。

安装器脚本

macOS 27 Release Notes 提醒，未指定 hostArchitecture 的安装包可能默认使用 arm64，企业需要检查前置和后置脚本是否仍按 Intel 环境编写。相关边界可参考 macOS 27 Release Notes。

重启与自动恢复

迁移完成前，至少做一次节点重启验收：

• CI Agent 是否自动上线；
• SSH 是否能重新连接；
• LaunchAgent 或 LaunchDaemon 是否自动启动；
• Keychain 是否处于可用状态；
• 缓存目录权限是否正确；
• 首个任务是否能无人值守完成；
• 失败后是否能被调度器重新接管。

如果一个方案只能在人工登录后工作，它不是生产兼容方案，只是交互式演示。

macOS 27 上的 Intel-only 软件还能维持运行吗？

可以，但不能把这理解成长期承诺。Apple 已确认 macOS 27 是通用 Rosetta 支持的最后一个主要版本，企业应把可运行窗口用于完成验证，而不是继续新增 Intel-only 依赖。

如何判断构建节点正在调用 Rosetta？

先扫描 CI Agent、命令行工具、脚本解释器、插件、动态库和安装脚本，再用 file、lipo 和进程翻译状态交叉确认。只检查主应用，通常会漏掉脚本拉起的 x86_64 子进程。

将 x86_64 工具迁往 arm64 时应先做什么？

供应商有原生版本时直接替换；自研工具则重编译为 arm64 或 Universal Binary。最终必须用真实项目完成测试、归档、签名与发布，不能把“安装成功”当作迁移完成。

兼容池是否应该继续保留到 macOS 27 生命周期结束？

可以短期保留，但必须有明确任务范围和退出日期。兼容节点只能处理已知例外，不能接收新的永久依赖，也不能与原生节点共享未经隔离的缓存。

哪些流水线环节最容易暴露 Rosetta 退出风险？

风险集中在 Intel-only CLI、旧插件、动态库、安装包脚本、包管理器路径和依赖交互式会话的后台进程。签名、公证、Keychain 和重启恢复也可能在最后阶段暴露问题。

迁移是否完成，取决于证据，而不是节点数量。下面的验收矩阵可以直接交给 CI 平台和发布团队填写。

容量规划也不要按开发者人数直接估算。至少使用待迁任务量、原生节点有效产能、发布峰值、兼容池退出周期和故障冗余建立变量模型。

如果现有节点不足以承载双跑，你可以先用一组隔离的 Apple Silicon 远程 Mac 试验节点，接入真实流水线，验证 arm64 工具链、签名、公证和重启恢复。CALMVPS 提供按需使用的远程 Mac 方案，你可以先查看 CALMVPS 的价格与套餐信息，再根据任务证据决定采购、自建或租赁规模。若需要先确认远程节点的交付与使用方式，可进一步查看 CALMVPS 的远程 Mac 订购入口。

在签署长期采购或租赁方案前，建议逐项勾选：

• ✅ 已完成所有 CI 节点的 x86_64 资产盘点；
• ✅ 每个例外组件都有负责人和退出日期；
• ✅ 原生池与兼容池使用独立标签、队列和缓存；
• ✅ 代表性 PR、测试、Archive、签名和发布任务已双跑；
• ✅ 产物哈希、签名状态和日志已留档；
• ✅ Keychain、插件、安装脚本和守护进程已完成无人值守验证；
• ✅ 节点重启后 Agent 能自动恢复；
• ✅ 迁移失败时有明确回滚节点和版本；
• ✅ 采购方案已按任务量、峰值和冗余建模，而不是按开发者人数估算；
• ✅ 兼容池不再接收新的永久 x86_64 依赖。

如果你当前方案是继续维护旧版 Intel 工具、购买更多本地 Mac，或临时拼接一组不可审计的共享机器，真实缺点通常是：依赖关系难以追踪、扩容速度受采购周期限制、迁移期双跑缺少隔离、节点故障后的恢复证据不足。对只需要验证一组 Apple Silicon 节点、承接短期 CI 峰值或完成 macOS 27 升级 PoC 的团队，先租用 CALMVPS 的远程 Mac，往往比立即锁定长期硬件采购更容易控制试验范围；但长期稳定重负载、必须连接物理设备或有特殊合规要求的团队，仍应优先评估自有节点。

下一步不要先决定买多少台机器。先建立隔离的 Apple Silicon 试验节点，把真实流水线跑通，拿到架构、签名、恢复和产物证据，再决定兼容池退出时间以及长期采购或租赁规模。