如何用treg scan预览可共享的密钥与技能？只读扫描完整教程
2026/9/26 6:42:45
1. 为什么搞清楚 x64 和 ARM64 比你想的更重要
很多人第一次意识到"架构"这个概念，是在装某个软件死活装不上的时候。下载页面摆着两个选项，一个写着 x64，一个写着 ARM64，随手点了一个，结果要么安装器直接报错，要么装上了却跑不起来，要么通过转译层勉强运行但风扇狂转、电池尿崩。这种体验在 Apple Silicon 全面铺开之后变得极其普遍，因为 Mac 从 Intel 时代整体迁移到了自研芯片，市面上同时存在两种架构的机器，而软件生态的过渡期注定是混乱的。
这篇文章要解决的就是一个非常具体的问题：怎么准确判断一台 Mac 到底是 x64 还是 ARM64，以及怎么判断某个软件、某个进程、某个终端环境当前跑在哪种架构下。听起来简单，但实际操作中坑非常多。比如你可能听说过 Rosetta 2 这个转译层，它能让 ARM64 的 Mac 运行 x64 的程序，这就导致"机器架构"和"进程架构"是两回事——你的 Mac 是 ARM64，但你正在跑的一个老软件可能是 x64 进程，通过 Rosetta 转译执行。分不清这两层，排查问题就会一直在错误的方向上打转。
这篇文章适合几类人：刚换 Mac 还不清楚自己机器底细的新用户；需要给不同同事分发不同版本安装包的运维或技术支持；在终端里折腾开发环境、被 conda 或 Homebrew 的架构问题折磨过的开发者；以及任何遇到过"这个软件在我电脑上装不了"的人。我会从芯片型号的肉眼识别讲起，一路讲到终端命令的精确判断，把机器架构、进程架构、软件包架构这三层彻底拆开讲清楚。
先给一个最基础的结论，方便你建立框架：Apple Silicon 芯片（M1、M2、M3、M4 系列）对应的架构是 ARM64，也叫 aarch64；Intel 芯片对应的架构是 x64，也叫 x86_64。这是最粗的一层对应关系。但真正干活的时候，你需要判断的往往不是"我的机器是什么"，而是"我当前这个终端会话、这个进程、这个安装包是什么架构"，这才是容易出错的地方。
2. 从芯片型号肉眼判断：最快但最容易想当然的一步
2.1 关于本机面板里藏着的信息
最直接的入口是左上角苹果菜单里的"关于本机"。点开之后你会看到芯片或处理器的信息。如果是 Apple M 开头的型号，比如"Apple M1""Apple M2 Pro""Apple M3 Max"，那这台机器就是 ARM64 架构。如果显示的是"处理器"后面跟着 Intel Core i5、i7、i9 或者 Xeon 之类的字样，那就是 x64 架构。
这里有个细节值得注意：较新版本的 macOS 在 Apple Silicon 机器上会明确写"芯片"这个词，而 Intel 机器上写的是"处理器"。这个措辞差异本身就是苹果在区分两代平台。不过光看这一层还不够，因为"关于本机"只告诉你物理硬件是什么，它不会告诉你当前运行的某个具体程序是什么架构。
我见过不少人在这里就停下了，觉得"我机器是 M2，那所有东西都是 ARM64"。这个推断在大多数情况下成立，但恰恰在出问题的时候不成立。原因就是 Rosetta 2。当你运行一个只为 Intel 编译的老程序时，macOS 会自动调用 Rosetta 2 把它转译成 ARM64 能执行的指令。这时候从系统角度看，这个进程是以 x64 身份存在的，只是被转译层接管了。所以"机器架构"和"进程架构"必须分开看。
2.2 系统信息里的处理器详情
如果你想要更详细的信息，可以按住 Option 键点击苹果菜单，会看到"系统信息"这一项（不按 Option 直接点也能在菜单里找到）。打开后在左侧选"硬件"或"处理器"，右侧会列出芯片名称、核心数、架构相关的描述。在 Apple Silicon 机器上，这里通常能看到芯片的完整型号和核心配置。
系统信息这个工具的价值在于它能一次性看到很多底层细节，比如内存、显卡、以及各个已安装应用的架构信息（在"软件"分类下的"应用程序"里，有一列叫"种类"，会标注每个 App 是"Apple 芯片""Intel"还是"通用"）。这个视图对于排查"哪些软件还在用 Rosetta 跑"特别有用，你可以一眼扫过去，找出那些标注为"Intel"的应用，它们就是通过转译运行的。
提示：系统信息里"应用程序"列表的"种类"列，是判断已安装软件架构最省事的图形化方式。"通用"表示同时包含 ARM64 和 x64 两套二进制，"Apple 芯片"表示原生 ARM64，"Intel"表示只有 x64 版本、需要 Rosetta 转译。
2.3 为什么不能只靠型号判断
只靠芯片型号判断架构，在"机器层面"是准确的，但在"软件层面"会误导你。举个典型场景：你在 M2 的 Mac 上装了一个老版本的数据库客户端，它只有 x64 版本。这时候你的机器是 ARM64，但这个客户端进程是 x64（通过 Rosetta 运行）。如果你要给它装插件或者配置环境变量，就必须按 x64 的路径来，而不是 ARM64 的路径。这就是为什么必须掌握终端命令，因为只有命令能精确告诉你"当前这个东西"到底是什么架构。
另外还有一个容易忽略的点：同一个软件可能同时提供两个版本，你下载的时候选错了，装上去也能跑（因为 Rosetta 兜底），但性能会打折。长期用转译版本跑重负载程序，续航和发热都会明显变差。所以判断架构不只是为了"能不能装"，也是为了"装得对不对、跑得好不好"。
3. 终端命令才是精确答案：uname、arch 与 file 的实战用法
3.1 uname -m：判断当前终端会话的架构
打开终端，输入：
uname -m这条命令返回的是当前终端进程所在的架构。在原生 ARM64 的终端里，它会返回arm64。在 Intel 机器上，它返回x86_64。关键点来了：在 Apple Silicon 机器上，如果你通过 Rosetta 打开了一个 x64 的终端（比如某些老版本的终端工具，或者你手动用arch -x86_64启动的会话），这条命令会返回x86_64，即使你的物理机器是 ARM64。
这就是"机器架构"和"会话架构"分离的直接体现。uname -m回答的问题是"我现在这个 shell 跑在什么架构上"，而不是"我的机器是什么架构"。这个区别在配置开发环境时至关重要，因为 Homebrew、conda 这类工具会根据当前会话架构来决定安装哪个版本的包。
3.2 arch 命令：查看和切换执行架构
arch命令在不带参数时，效果和uname -m类似，返回当前架构。但它更强大的地方在于可以指定用某个架构来执行命令：
arch -x86_64 some_command arch -arm64 some_command这个能力在 Apple Silicon 上非常实用。比如你有一个只有 x64 版本的命令行工具，想强制用 Rosetta 跑它，就可以用arch -x86_64前缀。反过来，如果你想确认某个工具在原生 ARM64 下能否正常工作，可以用arch -arm64强制走原生路径。
我实际用下来，最常见的场景是处理 Homebrew 的双架构问题。Homebrew 在 Apple Silicon 上默认装在/opt/homebrew（ARM64 原生），但如果你之前从 Intel Mac 迁移过来，可能还残留着/usr/local下的 x64 版本。两个版本的 brew 混用会导致包装到错误的路径、依赖解析混乱。这时候用arch命令明确指定架构来调用对应的 brew，能避免很多玄学问题。
3.3 file 命令：直接看一个可执行文件的架构
前面两条命令看的是"运行时会话"，而file命令看的是"文件本身"：
file /bin/ls file /usr/bin/python3 file /Applications/SomeApp.app/Contents/MacOS/SomeApp输出里会明确写出架构信息，比如Mach-O 64-bit executable arm64或者Mach-O 64-bit executable x86_64。如果是通用二进制（同时包含两套），会看到类似Mach-O universal binary with 2 architectures的描述，后面列出 arm64 和 x86_64。
这条命令是排查"这个二进制到底是什么架构"的终极手段。当你搞不清楚某个 App 或某个命令行工具是原生还是转译时，直接file一下它的可执行文件，答案立刻清楚。对于 App 来说，可执行文件通常在.app/Contents/MacOS/目录下，文件名一般和 App 同名。
3.4 三条命令的分工总结
为了让你一眼看清什么时候用哪条，我整理了一个对照表：
| 命令 | 回答的问题 | 典型输出 | 适用场景 |
|---|---|---|---|
uname -m | 当前终端会话是什么架构 | arm64 / x86_64 | 判断当前 shell 环境 |
arch | 当前架构，或指定架构执行 | arm64 / x86_64 | 强制用某架构跑命令 |
file <路径> | 某个文件本身是什么架构 | Mach-O ... arm64 | 判断二进制/App 架构 |
这三条命令配合使用，基本能覆盖所有"我到底在什么架构上"的疑问。记住核心原则：uname 和 arch 看的是运行时，file 看的是文件本身。搞混这两个维度，是很多人排查架构问题的第一个坑。
4. Rosetta 2 带来的"双重身份"：进程架构与机器架构的分离
4.1 Rosetta 2 到底做了什么
Rosetta 2 是苹果为 Apple Silicon 提供的 x64 到 ARM64 的转译层。当你在 M 系列芯片的 Mac 上运行一个只有 x64 版本的程序时，系统会自动调用 Rosetta 2，把这个程序的 x64 指令实时翻译成 ARM64 指令来执行。对用户来说，程序照常运行，感觉不到明显差异（除了性能和功耗上的损失）。
这个机制的存在，直接导致了"机器是 ARM64，但进程可以是 x64"这种双重身份。理解这一点，是排查很多诡异问题的前提。比如你发现某个软件在活动监视器里显示为"Intel"类型，占用 CPU 很高，那就是它在通过 Rosetta 转译运行，性能不如原生。
4.2 怎么判断一个正在运行的进程是不是走了 Rosetta
活动监视器是最直观的工具。打开后找到"种类"这一列（如果没有显示，可以在列标题上右键勾选），它会标注每个进程是"Apple 芯片""Intel"还是其他。标注为"Intel"的进程，就是通过 Rosetta 运行的 x64 进程。
在终端里，也可以用命令来判断。ps命令配合一些参数能看到进程的架构信息，不过更简单的方式是看进程的可执行文件路径，然后用file去查。另外，sysctl可以查询系统层面的信息：
sysctl -n sysctl.proc_translated在通过 Rosetta 运行的进程里，这个值会返回 1；在原生 ARM64 进程里，返回 0 或者报错说不存在这个键。这个技巧在写脚本判断"当前是否在 Rosetta 下运行"时特别有用。
4.3 什么时候该在意进程架构
不是所有场景都需要关心进程是不是走了 Rosetta。日常办公、浏览网页，转译带来的性能损失基本无感。但以下几类场景必须在意：
第一类是性能敏感型任务，比如视频渲染、代码编译、科学计算。这些任务用转译版本跑，可能比原生慢不少，而且发热和耗电明显增加。第二类是需要精确控制依赖的环境，比如 Python 的 conda 环境、Node.js 的 native 模块。如果基础解释器是 x64 的，那它装出来的 native 扩展也是 x64 的，和 ARM64 的库混用就会出问题。第三类是开发和调试，你需要知道自己的代码到底跑在哪个架构上，才能正确配置编译选项和依赖路径。
我踩过的一个典型坑是 conda 环境。早期在 M1 上装 Anaconda，默认装的是 x64 版本，导致所有包都是 x64 的，跑起来又慢又容易出兼容问题。后来换成 Miniforge 或者明确指定 ARM64 版本，才彻底解决。这个问题的根源就是没搞清楚"当前会话架构"和"我想要的目标架构"之间的差异。
4.4 强制走原生或强制走转译
有时候你需要主动控制用哪个架构。强制走 x64（Rosetta）：
arch -x86_64 <命令>强制走原生 ARM64：
arch -arm64 <命令>这两个前缀在配置双架构 Homebrew 时特别常用。比如你有一个 x64 的 brew 装在/usr/local，想用它装包，就写arch -x86_64 /usr/local/bin/brew install xxx。想用 ARM64 的 brew，就写arch -arm64 /opt/homebrew/bin/brew install xxx。明确指定架构，能避免 brew 自己猜错。
注意：不要在同一套依赖体系里混用两种架构的包。比如 Python 环境，要么全 ARM64，要么全 x64，混着来迟早出问题。判断标准就是看基础解释器的架构，然后所有扩展都跟着它走。
5. 软件包与安装包层面的架构识别：下载前的必修课
5.1 安装包文件名里的架构暗号
很多软件的下载页面会提供多个版本，文件名里通常带着架构标识。常见的命名模式有：
xxx-x64.dmg/xxx-x86_64.dmg：x64 版本，Intel 机器用，Apple Silicon 需要 Rosettaxxx-arm64.dmg/xxx-aarch64.dmg：ARM64 版本，Apple Silicon 原生xxx-universal.dmg：通用版本，两种架构都包含
看到这些后缀，就能直接判断该下哪个。Apple Silicon 用户优先选 arm64 或 universal，只有在没有 ARM64 版本时才退而求其次选 x64。
5.2 命令行工具的架构陷阱
命令行工具（比如各种 CLI、SDK）的架构问题比图形应用更隐蔽，因为它们往往通过包管理器安装，而包管理器自己也有架构之分。以 Homebrew 为例，ARM64 版本装在/opt/homebrew，x64 版本装在/usr/local。如果你两个都装了，which brew返回哪个，就决定了你后续装出来的包是什么架构。
判断当前 brew 的架构：
which brew file $(which brew)如果路径是/opt/homebrew/bin/brew，基本就是 ARM64；如果是/usr/local/bin/brew，基本就是 x64。再用file确认一下，就万无一失了。
5.3 开发环境里的架构一致性
做开发的人最容易在架构上翻车，因为一条工具链上有很多环节，每个环节都可能是不同架构。以 Python 为例，解释器、pip、虚拟环境、native 扩展，任何一环架构不一致都会出问题。判断方法是从头查起：
which python3 file $(which python3) python3 -c "import platform; print(platform.machine())"platform.machine()会返回arm64或x86_64，直接告诉你当前 Python 解释器的架构。这个信息决定了你应该装哪个架构的 wheel 包。
Node.js 类似，可以用：
node -p "process.arch"返回arm64或x64。这个值决定了 npm 安装 native 模块时编译出什么架构的二进制。
5.4 一个实用的架构自查清单
为了让你在遇到问题时能快速定位，我整理了一个自查流程：
- 先确认机器架构：关于本机看芯片型号，或
uname -m（注意这个可能被 Rosetta 影响） - 确认当前终端会话架构：
uname -m或arch - 确认目标软件/文件的架构：
file <路径> - 确认包管理器的架构：
which brew+file - 确认运行时环境的架构：Python 用
platform.machine()，Node 用process.arch
这五步走下来，任何架构相关的疑惑都能定位清楚。核心思路就是：从机器到会话，从文件到运行时，逐层确认，不要跳步。
6. 那些年我在架构问题上踩过的坑
6.1 迁移助理带来的架构残留
从 Intel Mac 迁移到 Apple Silicon Mac 时，迁移助理会把旧机器上的应用和数据一起搬过来。问题在于，很多旧应用是 x64 的，搬过来之后虽然能通过 Rosetta 运行，但如果你后续想更新或者装插件，就会遇到架构不匹配的问题。更麻烦的是，有些配置文件里写死了/usr/local这样的 x64 路径，在新机器上 ARM64 的对应路径是/opt/homebrew，导致命令找不到。
我的建议是：迁移之后，花点时间用系统信息的"应用程序"列表扫一遍，把标注为"Intel"的应用列出来，逐个检查是否有 ARM64 原生版本。有的话就换成原生版本，没有的话就接受它走 Rosetta 的事实，但心里要有数。
6.2 conda 环境的架构混乱
前面提过 conda 的坑，这里展开说。在 Apple Silicon 上，如果你用官方 Anaconda 安装包，早期版本装出来的是 x64 环境。这意味着你的 Python 解释器是 x64 的，通过 Rosetta 运行。这时候你pip install装出来的包，如果是带 native 扩展的，也是 x64 的。表面上看一切正常，但性能打折，而且和系统里其他 ARM64 的工具配合时容易出问题。
解决方案是改用 Miniforge 或者 Miniconda 的 ARM64 版本，确保基础环境是原生的。判断当前 conda 环境架构：
python -c "import platform; print(platform.machine())"如果返回x86_64，说明你还在 Rosetta 下跑，需要考虑重建环境。
6.3 终端里 conda 切换的架构陷阱
有热词提到"vscode终端切换conda的命令"，这里有个架构相关的细节。VS Code 的集成终端默认继承 VS Code 本身的架构。如果 VS Code 是 x64 版本（通过 Rosetta 运行），那它开出来的终端也是 x64 会话，里面激活的 conda 环境也会偏向 x64。这会导致你在 VS Code 里跑得好好的代码，换到系统终端里就出问题，因为两个终端的架构不一样。
解决办法是确保 VS Code 本身是 ARM64 原生版本，这样它的集成终端也是 ARM64，和系统终端保持一致。检查方法：在 VS Code 里打开终端，运行uname -m，看返回的是arm64还是x86_64。
6.4 安装包下错版本的隐蔽后果
下错架构的安装包，最坑的地方在于它往往能装上、能运行，让你以为没问题。但实际上它在通过 Rosetta 转译，性能、功耗、稳定性都打了折扣。有些软件在转译下会出现偶发的崩溃或功能异常，你排查半天以为是软件 bug，其实是架构不匹配。
养成习惯：下载任何软件前，先看清楚有没有 ARM64 或 universal 版本。有就优先选，没有再用 x64。装完之后，用活动监视器或file命令确认一下实际架构，确保符合预期。
7. 把架构判断变成肌肉记忆
架构这件事，说穿了就三层：机器架构、会话架构、文件架构。机器架构看芯片型号，会话架构看uname -m，文件架构看file。三层分清楚，绝大多数问题都能定位。
我自己的习惯是，在新机器上第一件事就是打开终端跑一遍uname -m和arch，确认是原生 ARM64。然后检查 Homebrew 的路径，确认是/opt/homebrew。接着检查常用的开发环境（Python、Node）的架构，确保都是原生的。这套流程走下来，后面装软件、配环境就很少出架构相关的幺蛾子。
最后分享一个我常用的小技巧：如果你不确定某个命令当前跑在什么架构下，又懒得记那么多命令，可以在命令前面加arch直接看，或者用file $(which <命令名>)一步到位。这两个操作足够应付日常九成以上的架构判断需求。真正复杂的场景，比如双架构 Homebrew 共存、conda 环境迁移，再按前面讲的逐层排查就行。架构问题不可怕，可怕的是不知道自己在哪一层上判断错了。