加载失败
Apple 公告称将在 macOS 28（按评论推断即 2027 年发布）逐步淘汰 Rosetta 2，並表示会保留面向旧游戏的 Rosetta 子集。Rosetta 2 在社区被理解为既有“翻译引擎”也有与之配套的为 x86_64 编译的系统框架，后者的撤出会影响 GUI 应用、插件和某些依赖二进制兼容的工作流。评论讨论焦点包括 Apple/containerization（Apple 在 GitHub 的容器化项目）与 Virtualization framework（macOS 的虚拟化框架）对容器与 VM 的影响、audio 插件/扫描等专业工具的遗留问题，以及用 QEMU、Parallels、Crossover/Wine 等替代方案带来的性能与兼容性折衷。社区以历史先例（Rosetta 1、32-bit 淘汰）和对 7 年过渡期是否公平的分歧来解读这次变动的长期影响。
评论普遍把这看作 Apple 一贯的做法：在过渡期后撤回兼容层以减少维护负担并推动生态迁移。具体理由包括不愿为 x86_64 的 macOS 用户态库（如 AppKit、UIKit）长期构建和测试多架构版本，以及节省因大量 fat binaries 带来的体积和维护成本。有人指出 Rosetta 2 并非纯软件魔法，它包含芯片级优化（例如对 x86 内存排序模型 TSO 和专用指令的支持），但 Apple 仍可选择只保留翻译引擎的一部分而不继续打包完整的 x86 系统框架。多个评论以 Rosetta 1 和 32-bit 淘汰为历史先例，认为两年的通知是“最后通牒式”的推动手段。
许多后端/DevOps 评论聚焦在容器镜像和本地构建：Apple 最近开源并发布了 containerization 框架和 container 工具，但社区担心 Rosetta 退役会破坏在 Apple Silicon 上构建或运行 x86_64 容器的能力。具体案例包括某些官方镜像（例如 Microsoft SQL Server）仍为 x86-only，开发者现在靠 OrbStack/Colima 或 Rosetta 翻译在本机构建与测试；如果移除高性能翻译，将不得不依赖 qemu（更慢）或在 CI 上多做多架构构建。尽管有人提到通过 buildx、交叉编译或迁移到 ARM 云实例（如 AWS Graviton）是可行路径，但公告中表示会“保留供游戏/旧框架使用的 Rosetta 子集”，使容器场景的长期可用性仍有不确定性。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
对音频制作、扫描和其它专业工作流的用户影响被反复强调：评论列举了 SnapScan、ABBYY FineReader、以及大量 VST/AU 插件仍依赖 Rosetta 才能在 Apple Silicon 上运行的具体例子。多位用户讲述了无法打开旧工程或需要保留老机才能访问项目的真实损失，甚至为商业版权或母带恢复付出大量时间但失败的情况。社区讨论了应急方案（保留旧硬件、在 Windows 上恢复、使用 Vuescan 或插件桥接），并有人呼吁 Apple 开源 Rosetta 或让社区延续维护，或指出 Asahi Linux 等开源项目也在实现 x86 翻译作为替代。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
公告中特别提到会为“依赖 Intel 框架的旧未维护游戏”保留 Rosetta 子集，因而游戏社区尤其关注 Apple 的真实意图：这能否保障用 Wine/Crossover 运行的 Windows 游戏或基于老 macOS API 的原生游戏继续可玩。评论里既有乐观者指出 Steam 已有 Apple Silicon Beta 客户端，也有担忧者认为被保留的“游戏子集”边界模糊、可能只偏向通过 Game Porting Toolkit 或 Win32 翻译的通路。不少帖子强调 Crossover/Proton 在 macOS 上依赖高性能的 Rosetta 翻译，若核心支持退役会严重削弱这些移植方案与新旧游戏的可用性。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
讨论中反复对比 Rosetta 与传统仿真器/VM（如 QEMU、Parallels）的性能和适用场景：多数技术评论认为 Rosetta 性能优越部分原因在于 SoC 对 x86 行为（例如 TSO）有加速支持，纯软件仿真如 QEMU 通常更慢且会影响测试/CI。还有人区分了 Rosetta 的两类职能——二进制翻译引擎与为运行 x86_macOS 应用而同时提供的 x86_64 系统框架，后者的撤出影响更大。Parallels、Virtualization framework 与容器化工具在某些场景下提供替代，但评论指出这些方案各有兼容性或性能折衷，无法简单替代现有的高性能翻译体验。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
社群情绪分裂：有用户认为从 M1（2020）到 macOS 28（2027）给出的约 7 年过渡期合理，称这与 Apple 以往的架构迁移节奏一致；也有人愤怒地把这视为对近年购机用户的不公或“计划报废”。讨论还扩展到 Apple 的年更策略与是否可能推出类似 Snow Leopard 式的“修复/稳定”版本，部分评论建议受影响用户保留旧机或转向非 mac 平台。总体上多数人认可 Apple 有驱动生态前进的动机，但同时对弃置长期依赖旧二进制的软件表达强烈不满。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
Rosetta 2: Apple 的二进制翻译层，用于在 Apple Silicon（arm64）上运行为 x86_64 编译的 macOS 应用，包含 AOT/JIT 翻译并依赖芯片层面的若干优化以提升性能。
fat binaries: 同时包含多个 CPU 架构（例如 x86_64 与 arm64）代码的可执行文件或库，能在不同架构上运行但会增加体积与维护成本。
TSO: Total Store Order，一种 x86 的内存排序模型；评论中提到 Apple SoC 在为 Rosetta 提供高效翻译时对 x86 内存模型做了硬件支持。
containerization（Apple/containerization）: Apple 在 GitHub 上的 containerization 项目与 container 工具（用于 macOS 上运行/管理容器），该工具目前对在 Apple Silicon 上运行 x86 容器依赖翻译机制。
Virtualization framework: Apple 提供的 Virtualization framework，用于在 macOS 上创建和管理轻量 VM，容器化、Linux x86 镜像常通过该框架或相关工具运行。
QEMU: 开源通用仿真/虚拟化软件，可在不同架构间仿真执行（例如在 ARM 上仿真 x86），但通常性能低于 Rosetta 的硬件/软件协同翻译。
Game Porting Toolkit: Apple 面向游戏移植的工具集，帮助将 Windows 游戏迁移到 macOS，内部会用到兼容层和翻译技术来减少移植工作量。