ARM64EC 詳解：何時使用、如何使用，以及最常絆倒人的相依性規則
更新於 2026年6月5日
ARM64EC 是 Windows on Arm 開發中最常被誤解的一環。它經常出現在 OpenSSL、Qt、Ruby 及 .NET 的議題討論串中，被問到「等一下，這是 ARM64 還是 ARM64EC？」——現在就來釐清。
常被混淆的三件事
- ARM64 — 純原生 Arm64。速度最快，但一個 Arm64 處理程序只能載入 Arm64 二進位檔。
- ARM64EC（「模擬相容」）— 一種 Windows 11 ABI，讓原生 Arm64EC 程式碼與模擬的 x64 程式碼在同一個處理程序中共存。Arm64EC 部分以原生速度執行；x64 部分則在模擬環境下執行。
- ARM64X — 單一 PE 二進位檔，同時包含 x64/Arm64EC 檢視與純 Arm64 檢視，任何一種處理程序都能載入。常用於共用 DLL。
ARM64EC 到底是什麼
它是針對無法一次完全轉為原生的應用程式所設計的橋接方案——通常是因為這些程式依賴某個 x64 外掛程式、編解碼器或無 Arm64 版本的函式庫。你將自己的程式碼重新編譯為 Arm64EC（原生速度），而 x64 相依元件則繼續在同一個處理程序中以模擬方式執行。Windows 11 on Arm 本身也採用此方式：x64 應用程式呼叫的大部分作業系統程式碼都是編譯成 ARM64EC，因此模擬應用程式能在不知不覺中以原生速度執行系統呼叫。
ARM64EC 需要 Windows 11 SDK——在 Windows 10 on Arm 上不存在。
最常絆倒人的相依性規則
這是被引用次數最多的一個陷阱，直接引用 Microsoft 的說法：
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 內部識別碼，並非最終 PE 類型。） - 在工作管理員中，ARM64EC 應用程式會顯示為 「ARM64（x64 相容）」——詳情請參閱如何判讀架構欄位。
ARM64EC 與全原生之間如何選擇
ARM64EC 是手段而非目的。如果所有相依元件都有 Arm64 版本，純 Arm64 更快且更簡單——沒有每個處理程序的模擬開銷，也沒有 ABI 混合。當且僅當某個僅有 x64 版本的相依元件阻礙了純原生路徑時，才採用 ARM64EC。請從完整的移植路線圖開始，讓相依性審查告訴你該走哪條路。