为何不编写操作系统可理解的可执行文件而非机器码？

首先要明确：你提出的「编译器生成OS可识别的中间字节码，由OS内置JIT转成机器码」的思路，其实早就有过实践（比如早期UCSD Pascal的p-code、部分嵌入式系统的字节码执行环境），但主流AOT编译依然选择直接生成机器码，核心原因是这种中间层方案存在诸多无法忽视的劣势：

一、运行时性能与延迟问题 #

• 启动延迟高：程序每次启动都需要OS的JIT把字节码编译成机器码，甚至首次执行某段代码路径时还要做即时编译，对命令行工具、嵌入式设备、实时系统这类需要快速响应的场景来说，这种延迟是不可接受的。
• 性能上限受限：AOT编译器可以在编译阶段做大量静态优化（比如全局数据流分析、链接时优化LTO、针对特定CPU指令集的深度调优），而JIT受限于运行时的时间和资源，优化空间相对有限，长期运行的程序中，原生机器码的性能表现通常更稳定且上限更高。

二、系统复杂度与维护成本 #

• OS负担加重：操作系统需要内置一套完整的字节码规范、JIT编译器和运行时环境，还要适配不同的CPU架构，这会大幅增加OS的开发、测试和维护成本，也更容易引入bug和安全漏洞。
• 兼容性僵化：字节码规范一旦确定，后续的扩展或修改会非常困难，而直接编译机器码可以针对不同CPU架构的特性灵活优化，适配新硬件的速度更快。

三、依赖与兼容性问题 #

• 运行环境绑定：程序必须依赖OS内置的JIT环境才能运行，如果目标系统没有这套环境，程序就无法执行。而原生机器码可执行文件只要CPU架构匹配，就能直接运行，无需额外依赖。

四、安全风险 #

JIT编译过程中需要在内存中生成可执行的机器码，这会给恶意代码留下攻击空间，比如JIT spraying这类利用JIT内存区域的攻击手段，会提升系统的安全防护难度。

另外，现在编译器生成机器码的门槛已经很低了——像GCC、Clang这类成熟工具链提供了通用的后端，可以直接生成不同架构的机器码，编译器开发者不需要从零开始实现机器码生成逻辑，所以「直接生成机器码」反而成了更高效、可靠的选择。

内容的提问来源于stack exchange，提问作者Mario