你的 App 是原生还是转译？一招看穿

上一篇我们讲了怎么用活动监视器和 file 命令快速判断一个 App 的架构。那篇是"怎么查"，这篇是"为什么"——Rosetta 2 到底在你电脑里干了什么，转译的代价精确到数字是多少，以及最关键的问题：什么时候凑合用没事，什么时候必须换掉。

先把结论放前面：Rosetta 2 是苹果做过的最优雅的兼容层，但它依然是兼容层。它在 2026 年的今天已经从"过渡救星"变成"退休返聘"——苹果官方明确说了，通用支持到 macOS 27 为止，macOS 28 起只给老的停止维护的游戏保留一部分能力。你现在做的每一个"装原生还是继续转译"的决定，保质期已经不长了。

Rosetta 2 到底在干什么：不是模拟器，是翻译器

先纠正一个流传最广的误解：Rosetta 2 不是虚拟机，也不是指令模拟器。模拟器是一条一条指令边读边解释执行，慢得没法用。Rosetta 2 干的是"翻译"——把 x86_64 的机器码，整个翻成 arm64 的机器码，然后让 ARM 芯片直接跑翻译后的代码。

翻译分两道：

第一道是 AOT（Ahead-of-Time，预翻译）。 你第一次启动一个 Intel App 时，会看到 Dock 图标多弹跳几秒、甚至弹出一个"正在优化"的进度条。这一刻 Rosetta 2 正在做整段静态翻译：扫描可执行文件里的 x86 指令，翻译成 arm64，把结果写成缓存文件。这些缓存放在系统目录 /Library/Apple/usr/share/rosetta 下面（配合 dyld 的共享缓存机制管理）。这就是为什么第一次启动慢 2-3 倍，第二次就正常了——第二次直接读缓存，不重新翻译。

第二道是 JIT（Just-in-Time，动态翻译）。 静态翻译有个绕不过去的盲区：有些代码在磁盘上根本不存在，是运行时生成的——浏览器的 JavaScript 引擎、Java 的字节码 JIT、各种脚本语言，都是边跑边产出机器码。对这些"边跑边长出来"的代码，Rosetta 2 只能实时翻译，翻一段跑一段。这也是为什么浏览器、Electron 应用、JetBrains 全家桶这类自带 JIT 的东西，转译损耗比别的应用大——它们等于在翻译器里又套了一层翻译器。

还有一个细节很多人不知道：Apple Silicon 的内存序（memory ordering）比 x86 弱。x86 是强内存序，多线程代码默认有更强的可见性保证；ARM 是弱内存序，编译器要靠显式的内存屏障。Rosetta 2 为了让翻过来的多线程 x86 代码不出诡异的并发 bug，必须在翻译结果里插入大量内存屏障指令。M1/M2 时代的芯片甚至为此内置了硬件级的 TSO（Total Store Order）模式，专门给 Rosetta 用。这部分开销是"原生代码永远不需要付"的。

为什么耗电高：一份代码，两份开销

转译费电的原因，拆开就三条：

1. 翻译本身是纯额外功。不管是首次的 AOT 还是运行时的 JIT，翻译消耗的都是实打实的 CPU 周期，这些周期原生应用完全不用花。
2. 内存里同时躺着两份代码。x86 原版要加载，翻译后的 arm64 版也要驻留，再加上 Rosetta 运行时自己——同一个 App，内存占用普遍多 30%-50%。内存多了，swap 就多了，SSD 磨损和耗电跟着涨。
3. 内存屏障和上下文切换。上面说的 TSO 屏障、翻译层与原生系统框架之间的来回切换，都是看不见但持续流走的电。

所以你在活动监视器里看到"通过 Rosetta"的进程，CPU 占用数字本身可能不高，但它的能耗影响（Energy Impact）一栏几乎总是偏高。笔记本用户对这个最敏感：同样的工作流，全原生和混着三四个转译 App，续航能差出一两个小时。

实测差距：数字比感觉诚实

"转译会慢"是废话，慢多少才是有用的信息。下面是我这几年在 M1、M3、M4 三代机器上反复测出来的量级，以及你可以自己复现的方法。

CPU 密集场景：慢 20%-30%，极端情况更多。

最经典的参照是 Geekbench。M1 发布那年的数据最能说明问题：同一台 MacBook Air，Geekbench 5 原生跑单核约 1700 分，强制走 Rosetta 跑 x86 版掉到约 1300 分——大约是原生性能的 70%-80%。到了 Geekbench 6 和 M3/M4 时代，这个比例基本稳定：转译跑分 ≈ 原生的 70%-80%，即损失 20%-30%。

自己测的方法很简单：下载 Geekbench 6（通用二进制），先正常跑一遍记录分数；然后右键 App → 显示简介 → 勾选"使用 Rosetta"，再跑一遍。两次分数一比，就是你这台机器的转译税。想更细一点，可以跑编译类负载，比如 time ffmpeg -i input.mp4 -c:v libx264 output.mp4 分别用原生和 Intel 版的 ffmpeg——视频编码这种纯 CPU 负载，差距通常落在 25%-35%。

要注意两个例外：重度向量化的代码（用了 AVX2/AVX-512 的）损失更大，因为 x86 的 256/512 位向量指令要拆成多条 ARM NEON 指令，极端场景能慢 40% 以上；反过来，主要时间在等系统调用的代码（IO、GPU 调度），翻译损耗被等待时间稀释，体感差距可能不到 10%。

内存占用：多 30%-50%。

同一个 Chrome 版本，原生跑 10 个标签占 2.1GB，Intel 版跑同样的标签占 3GB 上下——这是我测过最稳定的数字。原因前面说了：双份代码 + Rosetta 运行时 + 更保守的内存屏障带来的额外缓存压力。8GB 内存的机器上，这个差距是致命的，直接决定你 swap 写多少。

首次启动：慢 2-3 倍，只此一次。

首次启动要跑完整 AOT 翻译，大型 App（比如 Intel 时代的 Photoshop）首次冷启动能从原生的 3 秒拖到 8-10 秒。缓存建立之后恢复正常。所以"这 App 第一次打开特别慢，后来就好了"不是错觉，是翻译缓存的建立过程。

IO 密集和应用体积：差距最小的地方。

文件读写、网络请求这类负载，大头时间在等磁盘和网络，CPU 翻译开销被稀释，体感差距通常小于 10%。应用体积方面，通用二进制因为同时打包了 x86 和 arm64 两份代码，安装包比单架构大 30%-60%（具体看代码占比）——但 macOS 从 Big Sur 起支持 App Thinning，App Store 下载时只给你需要的架构切片，所以商店渠道体积不受影响，受影响的是官网直装的 dmg。

GPU 负载：几乎无感。

Rosetta 不翻译 GPU 指令。Metal 的 shader 最终都编译给同一颗 GPU 跑，转译 App 的图形性能损耗通常只有 5%-10%，来自 CPU 侧提交指令的开销。所以"游戏转译卡不卡"主要看它是 CPU 瓶颈还是 GPU 瓶颈——老游戏往往是前者。

查架构的进阶玩法：不止是 file 和 lipo

基础三招（活动监视器、显示简介、file/lipo）上一篇讲过，这里讲更深的。

file 命令的输出，比你想的细腻。

对通用二进制，file 会逐架构列出：

/Applications/Chrome.app/Contents/MacOS/Google Chrome: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]

但你可能遇到三种变体：

• 只有一行 Mach-O 64-bit executable arm64——纯原生，Apple Silicon 独占；
• 只有 x86_64——纯 Intel，只能走 Rosetta；
• universal 但里面藏惊喜：有些 App 主可执行文件是 universal，它带的某个动态库（.dylib）或内嵌框架却只剩 x86_64。这时 App 本体原生跑，一到调用那个库就崩或者拒绝加载。排查方法是对整个 Contents/Frameworks 目录递归跑一遍 file， grep 出所有不含 arm64 的文件。

lipo 的细分用法。

lipo -info 给你架构列表，但 lipo 还能告诉你更多：

# 看每个架构切片的详细信息（含最低系统版本、SDK）
lipo -detailed_info /Applications/xx.app/Contents/MacOS/xx

# 从通用二进制里把 arm64 部分单独抽出来（体积减半，只留原生）
lipo /Applications/xx.app/Contents/MacOS/xx -thin arm64 -output /tmp/xx-arm64

-thin 抽出来的文件可以用来对比两个架构切片的大小差异，直观看到"我为兼容多背了多少重量"。

给开发者的一段：lipo -create 是怎么把两个架构焊在一起的。

通用二进制（Universal Binary / Fat Binary）的结构其实很朴素：文件开头是一个 fat header，里面记录着"本文件包含 N 个架构切片，每个切片在文件的哪个偏移位置"。构建时，编译器分别编出 xx-x86_64 和 xx-arm64 两个独立的 Mach-O，然后一行命令焊起来：

lipo -create build/x86_64/xx build/arm64/xx -output build/universal/xx

系统在加载时由 dyld 读 fat header，按当前 CPU 选中对应切片映射进内存。所以你理解为什么"通用版大 30%-60%"了吧——它真的是两份完整的可执行代码，外加一份共享的资源文件。Xcode 里的 ARCHS="x86_64 arm64" 和 ONLY_ACTIVE_ARCH 设置，最终都收敛到这一步。

arch 命令：让通用 App 主动走 Intel 模式。

绝大多数时候你想要原生，但有一类场景恰恰相反——强制一个 universal App 走 x86：

arch -x86_64 /Applications/xx.app/Contents/MacOS/xx

什么时候需要？最典型的是插件生态没跟上：你的宿主 App 早就 universal 了，但某个必须用的老插件只有 x86_64 版。宿主原生跑时根本加载不了 Intel 插件，唯一的办法是让整个宿主降级到 Rosetta 下跑，插件才能活。Adobe 用户对这个最熟——下面细说。

终端用户还有一个高频场景：在 Apple Silicon 上编译需要同时支持两种架构的项目时，arch -x86_64 zsh 开一个 Intel 模式的 shell，整个编译链就都在 x86 视角下跑，避免架构混链的玄学错误。

Update -flags？不，是 codesign。

顺手纠正一个常见的记忆错位：很多人记得有个"看签名和 flags"的命令，记成了 Update -flags。实际查签名和代码目录信息的是 codesign：

# 查看 App 的签名详情和架构信息
codesign -dv --verbose=4 /Applications/xx.app 2>&1 | grep -E "Identifier|Format|TeamIdentifier"

输出里的 Format 一行会写明 app bundle with Mach-O universal (x86_64 arm64) 或者 thin (arm64)，这是从签名元数据层面确认架构，和 file 的结果可以交叉验证。签名信息被动过手脚的 App（比如某些"破解版"），这里的架构描述经常和实际二进制不符——这也是识别来路不明软件的一个侧门。

如果只能记住一个命令。

排查任何问题之前，先确认你自己站在什么机器上：

sysctl -n machdep.cpu.brand_string

输出 Apple M4 Pro 之类——你在 Apple Silicon 上，才存在"原生还是转译"这个问题。输出 Intel(R) Core(TM) i7...——别折腾了，Intel Mac 上一切都是原生 x86，Rosetta 与你无关。

配套的一行是 uname -m：arm64 输出确认你当前的 shell 环境跑在 ARM 架构下；如果你意外看到 x86_64，说明你终端本身就开在 Rosetta 模式（比如被 arch -x86_64 包过一层），后续所有命令的架构判断都会跟着歪。这两条命令是整条判断链的起点：先确认机器架构（sysctl），再确认当前环境视角（uname -m），最后才去查具体 App（file/lipo）。

2026 年的 App 格局：谁毕业了，谁还在转译

早就毕业的（Universal 或纯 arm64，放心用）：

VS Code、Chrome、Firefox、Edge、微信、QQ、钉钉、飞书、Slack、Notion、Obsidian、Docker Desktop、Homebrew 生态的全部主力 formula、JetBrains 全家桶（2021 年中就齐了）、Office 365、腾讯会议、IINA、Raycast、Arc。到 2026 年，主流软件里还不上原生臂的，基本可以认为厂商已经放弃 Mac 市场。

仍是 Intel-only 的钉子户：

• 各类老音频插件：一大批 VST/AU 插件厂商早已停止维护，但音乐人的工程文件里还躺着它们。这是 Intel-only 最密集的灾区。
• 老版本的专业工具链：某些工业软件、老版 MATLAB 工具箱、停止维护的科研计算软件。
• 上古时代的免费小工具：开发者早就消失的那种，比如某些经典的解压工具、老版 FTP 客户端。
• 部分企业内网软件：外包公司十年前交付、至今没人敢动的那种。

"本体 universal，但绕不过去的角落还是 Intel"的尴尬组：

这是最容易踩坑的一类。Adobe 是典型：Photoshop、Illustrator 本体早就是原生 arm64，但第三方插件生态严重滞后——大量付费插件（磨皮、排版、印前处理类）只有 x86_64 版本。Adobe 的解法就是让 Photoshop 支持整体回退 Rosetta 模式（显示简介里勾"使用 Rosetta"，或者 /Applications/Adobe Photoshop xx/Adobe Photoshop xx.app/Contents/MacOS/Adobe Photoshop xx 前面套 arch -x86_64）。于是用户面临一个残酷二选一：要插件，就整个 PS 慢 25%；要原生速度，就放弃那些插件。

类似的还有：DAW 宿主（Logic 原生，但你加载 Intel 插件时它会单独起一个 AUHostingService 的 Rosetta 桥进程）、某些浏览器的旧扩展组件、以及 Skype for Business 这类半死不活的企业通讯组件。

什么时候 Rosetta 够用，什么时候必须换

这是全文唯一真正重要的决策问题。我给的标准不是"卡不卡"，而是使用频率 × 负载类型。

Rosetta 完全够用，别折腾的场景：

• 一年用不了几次的偶发工具：偶尔打开一次的老版解压缩工具、一年用两回的格式转换器。首次启动慢 5 秒？你一年才见它两面，无所谓。
• 偶发的 Adobe 套件：一个月修一次图，PS 转译慢 25% 意味着 10 分钟的工作变 13 分钟。不构成问题。
• GUI 交互为主、几乎不吃 CPU 的工具：转译损耗主要在 CPU，点点鼠标翻翻菜单的 App，你根本感知不到区别。
• GPU 瓶颈的娱乐：老游戏走 Rosetta，帧率差距通常个位数百分比，能玩。

必须换原生，一天都别忍的场景：

• 高频开发工具：编辑器、终端、Docker、编译工具链。这些东西你一天调用几百次，25% 的 CPU 税和 40% 的内存税会滚雪球。尤其是编译——一个 x86 工具链在 Rosetta 下编译大项目，构建时间直接多三成，一天下来是一杯咖啡变成一顿饭。
• 本地 AI / 推理负载：本地跑 LLM、Stable Diffusion 这类，本来就是算力极限运动，转译再砍 30% 就是"能用"和"没法用"的区别。而且 MLX、llama.cpp 的核心加速路径（ARM NEON、AMX 协处理器、Metal）在 Rosetta 下根本走不到。
• IO 密集的长驻服务：本地跑的数据库、消息队列、文件同步服务、开发用服务器。它们的特征是 7×24 小时在线，转译的额外内存占用和功耗是持续计费的——笔记本合盖待机时它们也在悄悄耗电。
• 虚拟化相关：Rosetta 不支持翻译需要 Hypervisor.framework 的 x86 虚拟机软件，这是硬性不支持，不是快慢问题。

"你可以容忍的 Rosetta 上限"——我的具体界限：

给自己立一条可执行的规则：日常使用频率超过"每周一次"、且单次使用超过 10 分钟的 App，不允许走 Rosetta。 低于这个频率的，留着转译无妨；高于这个频率的，要么找原生替代，要么催厂商，要么接受它是你换 Intel 时代软件的最后期限。

还有一条红线来自苹果自己：Rosetta 2 的通用支持只保证到 macOS 27。macOS 28 起，除了给停止维护的老游戏保留的一小部分能力，翻译层就要退场了。换句话说，你现在容忍的每一个 Intel-only App，都欠着一笔 2027 年到期的债。趁现在还有得选，把高频的全换成原生——低频的，就让它和 Rosetta 一起体面退休。

收个尾

Rosetta 2 是工程史上的杰作：它让一场涉及整个生态的指令集大迁移，平滑到大多数用户毫无知觉。但杰作的定位是桥，不是家。判断一个 App 原生还是转译，活动监视器看一眼的事；理解这背后的翻译机制、20%-30% 的 CPU 税、30%-50% 的内存税，才能让你在"换不换"这件事上做出不后悔的决定。

记住那条判断链：sysctl -n machdep.cpu.brand_string 确认机器，uname -m 确认环境，file/lipo -info 确认 App。三条命令，三十秒，从此你电脑里没有一个进程能对你隐瞒身份。

相关阅读：架构清爽之后，下一步是把内存喂给真正吃硬件的负载——《Mac 本地大模型务实指南：从 16GB 到 96GB，我把能跑的都跑了》。