ARM64EC 深度解析：何时用、怎么用，以及人人踩坑的依赖规则
更新于 2026年6月5日
ARM64EC 是 Windows on Arm 开发中最被误解的角落。它出现在 openssl、Qt、Ruby、.NET 的 issue 帖里，永远是那句「等等，是 ARM64 还是 ARM64EC？」——这篇把它讲清楚。
人们混淆的三个概念
- ARM64——纯原生 Arm64。最快，但 Arm64 进程只能加载 Arm64 二进制。
- ARM64EC（Emulation Compatible，兼容模拟）——一种 Windows 11 ABI，原生 Arm64EC 代码与模拟的 x64 代码在同一进程内共存。Arm64EC 部分原生运行，x64 部分模拟运行。
- ARM64X——单个 PE 二进制，同时包含 x64/Arm64EC 视图和纯 Arm64 视图，两类进程都能加载。用于共享 DLL。
ARM64EC 到底是什么
它是给「无法一步到位完全原生」的应用的桥梁——通常是因为依赖某个没有 Arm64 版的 x64 插件、编解码器或库。你把自己的代码重编译为 Arm64EC（原生速度），而 x64 依赖继续在同一进程内以模拟方式运行。Windows 11 on Arm 自己就用了这套：x64 应用调用的大部分系统代码都编译为 ARM64EC，所以模拟应用在不知情的情况下获得了原生速度的系统调用。
ARM64EC 需要 Windows 11 SDK——它在 Windows 10 on Arm 上不存在。
人人踩坑的依赖规则
这是被引用最多的坑，直接引微软原文：
x64 或 Arm64EC 进程可以加载并调用 x64 和 Arm64EC 二进制，而 Arm64 进程只能加载 Arm64 二进制。
所以：ARM64EC 进程能加载 x64 ✓ 和 ARM64EC ✓，但 纯 ARM64 ✗。如果你构建 ARM64EC 却想拉入一个纯 Arm64 依赖，它加载不了。把原生 Arm64 库混进 EC 构建的人就栽在这里。
渐进式迁移流程
预期的工作流是渐进的，且应用每一步都保持可运行：
- 从你完全模拟的 x64 应用开始。
- 先把最吃 CPU 的模块重编译为 ARM64EC——单位工作量的性能收益最大。
- 逐模块继续。
- 当每个依赖都有 Arm64 版后，可选地收尾为完全原生 Arm64。
ARM64X 与纯转发器技巧
如果你发布的 DLL 同时被 x64/EC 和纯 Arm64 进程加载，把它构建为 ARM64X——一个文件，两个视图。一个巧妙的模式是纯转发器：一个无代码的微型 ARM64X DLL，把加载器重定向到正确架构的真实 DLL。
如何辨别你构建出的是什么
- 对最终二进制运行
link /dump /headers，ARM64EC 内容显示8664 machine (x64) (ARM64X)。（中间 OBJ/LIB 显示A641 (ARM64EC)，是 MSVC 内部 id，非最终 PE 类型。） - 任务管理器里，ARM64EC 应用显示为 “ARM64 (x64 兼容)“——见如何读体系结构列。
ARM64EC vs 完全原生
ARM64EC 是手段，不是终点。如果每个依赖都有 Arm64 版，纯 Arm64 更快也更简单——没有逐进程模拟，没有 ABI 混合。只有当某个仅 x64 的依赖挡住纯原生路径时，才该用 ARM64EC。从完整的移植路线图开始，让依赖审计告诉你走的是哪条路。