Windows on Arm能运行x64应用，为什么还要单独核对驱动

一款x64程序能在Arm电脑上打开，并不足以证明它依赖的所有组件都能工作。判断Windows on Arm的兼容范围时，应先把应用本身与驱动分开：微软支持的应用模拟，并不包含对驱动的同样模拟。

版本差别是第一层边界。微软《How emulation works on Arm》说明，Windows 11 on Arm支持x86和x64应用模拟；Windows 10 on Arm支持的则是x86应用。把两者统称为“Windows支持模拟”会漏掉这一差异，也容易把某个系统版本的能力套到另一个版本上。

模拟为何能让原有应用运行？文档描述的是指令转换：运行时把x86指令块转换为Arm64指令，并通过缓存减少重复转换的开销。对使用者而言，这项能力属于Windows自身，不需要另装一个通用的模拟组件。这里解释的是系统机制，并不是本文对某台设备测得的运行速度。

关键限制紧接在机制说明之后：模拟只覆盖用户模式代码，不支持驱动；内核模式组件必须编译为Arm64。因此，“应用有x64版本”与“所需驱动有Arm64版本”是两项需要分别查证的信息。前一项成立，不能通过推理替后一项作答。

假设某个桌面程序还要通过配套驱动连接外部设备，这只是便于理解的场景，并非实测案例。即使主程序界面能够显示，也只能说明已经观察到的那部分行为；它不能证明设备连接、相关驱动以及其余功能都已兼容。反过来，看到软件包含驱动也不能直接断言它不能使用，还要看厂商是否提供了对应架构的组件。

整理兼容性资料时，可把操作系统版本、应用架构和依赖组件列在不同位置。对于未知项，保留“未核实”比写成一个笼统的“支持Arm”更有用。本文讨论的模拟范围也不能代替厂商针对某款产品的支持清单，更不能据此承诺全部功能或性能不变。

以上依据2026年10月12日读取的微软官方文档，未安装驱动、运行兼容性测试或修改系统设置。对开发团队和采购人员，这份资料首先提供的是核对顺序：确认所用Windows版本，再分别核应用与内核依赖，避免把应用模拟误读成整个软件链条的兼容保证。