我来帮你把这些问题拆解清楚，都是结合官方技术细节和实际部署经验总结的：

1. 编译自.NET Framework 4.7.2的Windows服务能否在ARM64 Windows上原生运行？ #

可以的。.NET Framework 4.8.1作为就地更新，会替换系统上的框架运行时环境，其中就包含完整的ARM64原生运行时。只要你的Windows服务是用Any CPU或者ARM64目标平台编译的（而非强制指定x86/x64），在安装了4.8.1的ARM64 Windows 10/11上，它会自动调用原生ARM64运行时执行，完全不需要修改现有代码。

2. .NET Framework 4.8.1的ARM64原生支持是否覆盖Windows服务？ #

当然覆盖，它绝非只局限于WinForms或控制台程序。.NET Framework 4.8.1的ARM64支持是框架层面的全量支持，所有托管应用类型——包括Windows服务、WPF、经典ASP.NET、控制台程序等——都能享受到原生ARM64的执行能力。本质上不管是什么应用类型，基于.NET Framework的托管代码都会调用统一的框架运行时，只要运行时支持ARM64，所有类型的应用都能原生运行。

3. 如果无法原生运行，是不是只能迁移到现代.NET？ #

其实不一定非要直接迁移。如果你的服务目前是用x86目标平台编译的（导致只能通过Windows的x86仿真层运行），那最简单的解决办法是重新编译项目，把目标平台改成Any CPU或者ARM64，之后在ARM64系统上部署，就能用上原生运行时了。

当然，如果你的团队有长期的维护计划，迁移到现代.NET（.NET 5/6/8及以上）确实是更优的选择——现代.NET对ARM64的支持更成熟，性能表现更好，还有持续的功能更新和长期支持服务。但如果只是为了让现有4.7.2的服务在ARM64上实现原生运行，重新调整编译配置就足够解决问题。

如果还有具体部署或编译配置上的细节问题，随时提出来就行~