静态编译与动态编译：链接方式与执行时机（AOT vs JIT）

文章目录

概念与维度
- [📦 维度一：链接方式（静态链接 vs 动态链接）](#📦 维度一：链接方式（静态链接 vs 动态链接）)
- - [1. 静态编译（静态链接 Static Linking）](#1. 静态编译（静态链接 Static Linking）)
  - [2. 动态编译（动态链接 Dynamic Linking）](#2. 动态编译（动态链接 Dynamic Linking）)
- [⚙️ 维度二：执行时机（AOT vs JIT）](#⚙️ 维度二：执行时机（AOT vs JIT）)
- - [1. 静态编译（提前编译 AOT, Ahead-of-Time）](#1. 静态编译（提前编译 AOT, Ahead-of-Time）)
  - [2. 动态编译（即时编译 JIT, Just-In-Time）](#2. 动态编译（即时编译 JIT, Just-In-Time）)
- [📊 核心差异对比总结](#📊 核心差异对比总结)
- [💡 实际应用与趋势](#💡 实际应用与趋势)
相关问题理解
- C、C++只能是AOT么，不能是JIT么
- - [🛠️ 层面一：用 C/C++ 编写 JIT 编译器（最常见的形态）](#🛠️ 层面一：用 C/C++ 编写 JIT 编译器（最常见的形态）)
  - [💻 层面二：C/C++ 程序自身在运行时进行 JIT（自我编译与执行）](#💻 层面二：C/C++ 程序自身在运行时进行 JIT（自我编译与执行）)
  - [⚖️ 既然 C/C++ 可以实现 JIT，为什么大家普遍觉得它是 AOT 语言？](#⚖️ 既然 C/C++ 可以实现 JIT，为什么大家普遍觉得它是 AOT 语言？)
- AOT和JIT都是要编译程序为机器码，最终编译的结果有什么不同
- - [📝 1. 优化依据不同：静态猜测 vs 动态事实](#📝 1. 优化依据不同：静态猜测 vs 动态事实)
  - [🌍 2. 适配程度不同：通用兼容 vs 量身定做](#🌍 2. 适配程度不同：通用兼容 vs 量身定做)
  - [🔗 3. 产物形态与生命周期不同：永久固化 vs 内存缓存](#🔗 3. 产物形态与生命周期不同：永久固化 vs 内存缓存)
- 为什么不都采用JIT的编译方式
- - [⏳ 1. 启动慢与"预热期"的代价](#⏳ 1. 启动慢与“预热期”的代价)
  - [💾 2. 额外的内存与 CPU 开销](#💾 2. 额外的内存与 CPU 开销)
  - [📱 3. 平台限制与安全红线](#📱 3. 平台限制与安全红线)
  - [🔗 4. 牺牲跨平台特性与动态灵活性](#🔗 4. 牺牲跨平台特性与动态灵活性)
- [Java 如果采用AOT，失去最大红利是什么意思](#Java 如果采用AOT，失去最大红利是什么意思)
- - [🌍 传统 Java 的"中间商赚差价"模式（JIT）](#🌍 传统 Java 的“中间商赚差价”模式（JIT）)
  - [⛓️ 为了极致性能引入 AOT（如 GraalVM）发生了什么？](#⛓️ 为了极致性能引入 AOT（如 GraalVM）发生了什么？)
  - [💡 总结："生态红利"是怎么丢的？](#💡 总结：“生态红利”是怎么丢的？)

概念与维度

在计算机科学领域，"静态编译"与"动态编译"这两个术语其实包含了两层截然不同的含义。为了全面且深刻地理解它们，我们需要从两个核心维度来剖析：

链接方式（Linking）：程序依赖的库代码是如何被打包进可执行文件的。
执行时机（Execution Timing）：源代码或中间代码是在何时被翻译成机器码的。

下面将从这两个维度为你进行体系化的深度解析。

📦 维度一：链接方式（静态链接 vs 动态链接）

这个维度主要关注的是**库文件（Library）**如何与你的程序结合。

1. 静态编译（静态链接 Static Linking）

原理与原因 ：在程序构建（编译和链接）阶段，编译器会将程序所依赖的所有库代码（如 .a 或 .lib 静态库）直接提取出来，完整地复制并嵌入到最终生成的可执行文件中。
实现方式 ：以 C/C++ 为例，使用 GCC 编译时加上 -static 参数（如 gcc -static main.c -o app），就会强制链接器将 libc.a 等静态库打包进去。Go 和 Rust 语言默认就采用这种方式，生成一个完全独立的二进制文件。
优点：
- 极强的独立性与可移植性：生成的可执行文件包含了运行所需的一切，不依赖外部环境中的任何库文件。你可以把它复制到任何相同架构的系统上直接运行，彻底解决了"在我的电脑上能跑，在你的电脑上报错"的依赖缺失问题。
- 启动速度快：因为不需要在启动时去系统里寻找和加载外部库，省去了动态链接器的解析过程。
- 版本兼容性完美：程序自带特定版本的库，不会因为系统升级了某个库而导致旧程序崩溃。
缺点：
- 文件体积庞大：每个程序都自带一份完整的库代码。比如一个简单的"Hello World"程序，动态链接可能只有几十 KB，静态链接后可能膨胀到几百 KB 甚至几 MB。
- 内存浪费：如果同时运行多个相同的静态编译程序，每个进程都会在内存中加载一份相同的库代码副本，无法共享。
- 更新维护困难 ：如果依赖的库发现了安全漏洞（如 glibc 的幽灵漏洞），你必须重新编译整个程序并重新分发，而不能像动态链接那样简单替换一下系统的 .so 或 .dll 文件。

2. 动态编译（动态链接 Dynamic Linking）

原理与原因 ：在编译阶段，只记录程序需要哪些库以及调用了哪些函数（符号引用），并不把库代码打包进去。程序运行时，由操作系统的动态链接器（如 Linux 下的 ld-linux.so）负责在内存中加载这些共享库（如 .so 或 .dll），并完成地址绑定。
实现方式 ：这是大多数 C/C++ 编译器的默认行为（如直接执行 gcc main.c -o app）。Python、Java 等语言在导入模块或类库时，本质上也是在进行动态加载。
优点：
- 节省磁盘与内存空间：多个程序可以共享同一份内存中的动态库副本，极大提高了资源利用率。
- 模块化与易维护：库的升级非常灵活，只要接口兼容，替换掉系统里的动态库文件，所有依赖它的程序都能自动享受到修复或性能提升。
- 支持插件机制：程序可以在运行时按需加载特定的动态库，这是实现软件插件化、热插拔的基础。
缺点：
- 依赖地狱（Dependency Hell）：目标机器必须安装有正确版本的动态库。如果版本不匹配或缺失，程序将无法启动。
- 启动稍慢：程序启动时需要花费时间去定位、加载和链接动态库。

⚙️ 维度二：执行时机（AOT vs JIT）

这个维度关注的是代码翻译发生的时间点。

1. 静态编译（提前编译 AOT, Ahead-of-Time）

原理与原因 ：在程序运行之前，就通过编译器将高级语言源代码一次性全部翻译成目标平台的本地机器码（Native Code）。
实现方式：C、C++、Go、Rust 都是典型的 AOT 编译语言。近年来，为了优化 Java 和 .NET 的启动速度，也引入了 AOT 技术，例如 GraalVM 可以将 Java 字节码直接编译成原生二进制文件（Native Image），.NET 也提供了 Native AOT 编译。
优点：
- 极致的运行时性能：代码已经是机器码，CPU 可以直接执行，没有任何翻译开销。
- 启动迅速：非常适合对冷启动时间极其敏感的场景，如命令行工具、Serverless 函数计算、云原生容器应用等。
缺点：
- 缺乏运行时优化：编译器在编译时无法预知程序运行时的真实数据特征（比如哪段代码是热点），因此无法做针对性的极致优化。
- 跨平台能力弱：为 Windows 编译的 AOT 程序无法直接在 Linux 上运行，必须针对每个目标平台重新编译。

2. 动态编译（即时编译 JIT, Just-In-Time）

原理与原因 ：程序在发布时携带的是中间代码（如 Java 的字节码、C# 的 IL）。在程序运行时，虚拟机（如 JVM、CLR）或解释器会监控代码的执行，将频繁执行的"热点代码"动态编译成本地机器码并缓存起来，下次执行时直接使用。
实现方式：Java (JVM)、C# (.NET CLR)、JavaScript (V8 引擎) 是 JIT 技术的集大成者。
优点：
- 惊人的运行时优化潜力：JIT 编译器拥有"上帝视角"，它可以根据程序运行时的实际类型、调用频率、硬件特性等进行激进的优化（如方法内联、逃逸分析、死代码消除）。长期运行的服务，其峰值性能往往能超越 AOT 编译的程序。
- 完美的跨平台性：只需编译一次成中间字节码，就可以在任何安装了对应虚拟机的平台上运行。
缺点：
- 启动慢与预热期：程序刚开始运行时，代码多为解释执行或正在编译，性能较差。需要经过一段时间的"预热"才能达到最佳状态。
- 额外的资源消耗：JIT 编译过程本身会占用 CPU 和内存资源。

📊 核心差异对比总结

为了让你更直观地把握两者的区别，这里提供两份核心对比表：

1. 链接方式对比（库的打包）

特性	静态编译 (Static Linking)	动态编译 (Dynamic Linking)
文件大小	较大（内含完整库代码）	较小（仅含库引用信息）
运行时依赖	无外部依赖，独立运行	需系统安装匹配的动态库
内存占用	较高（多进程无法共享库代码）	较低（多进程共享库内存）
库更新	需重新编译整个程序	替换动态库文件即可
典型场景	Go 二进制文件、嵌入式固件、单机工具	操作系统组件、大型服务器集群、插件化软件

2. 执行时机对比（代码的翻译）

特性	静态编译 (AOT)	动态编译 (JIT)
编译时机	运行前离线完成	运行时按需动态编译
启动速度	极快（无编译开销）	较慢（需解释+预热编译）
峰值性能	稳定，但上限受限于编译期信息	极高（可利用运行时信息进行激进优化）
跨平台性	差（需针对不同平台分别编译）	强（中间字节码通用）
典型代表	C, C++, Go, Rust, GraalVM Native	Java (JVM), C# (CLR), JavaScript (V8)

💡 实际应用与趋势

在现代软件开发中，这两种技术并不是非此即彼的对立关系，而是根据业务场景取长补短，甚至走向融合：

云原生与微服务（偏向静态 AOT + 静态链接） ：

在 Docker 容器和 Kubernetes 编排中，开发者越来越青睐 Go 语言或使用了 GraalVM 的 Java 应用。因为它们能生成静态链接的 AOT 二进制文件。这种文件体积极小、启动毫秒级、无任何外部依赖，非常适合弹性伸缩和快速部署的云环境。
企业级长运行服务（偏向动态 JIT） ：

对于电商交易核心、金融风控系统等需要 7x24 小时不间断运行的大型后端服务，启动慢几秒钟完全可以接受。它们更看重长期运行后的极限吞吐量。此时，Java 或 .NET 的 JIT 编译器能够在运行数小时后，将热点代码优化到极致，提供比 AOT 更高的性能表现。
混合编译模式（博采众长） ：

现代运行时环境正在打破界限。例如 Android 的 ART 虚拟机采用了混合模式：在安装应用时对关键路径进行 AOT 编译以保证启动速度，而在运行时依然保留 JIT 能力去优化后续产生的新热点；Java 的 HotSpot 虚拟机同样支持在运行过程中将部分字节码进行 AOT 编译并缓存，实现了启动速度与运行性能的平衡。

相关问题理解

C、C++只能是AOT么，不能是JIT么

C 和 C++ 绝对不仅仅是 AOT（提前编译），它们完全可以是 JIT（即时编译）的。

虽然在日常开发中，我们绝大多数时候都是通过 GCC、Clang 等编译器将 C/C++ 代码直接编译成机器码来运行（即典型的 AOT 模式），但这并不代表 C/C++ 无法进行 JIT 编译。实际上，在现代高性能计算和系统编程领域，C/C++ 的 JIT 技术非常活跃且强大。

我们可以从以下两个层面来深入理解：

🛠️ 层面一：用 C/C++ 编写 JIT 编译器（最常见的形态）

这是目前工业界最主流的"C/C++ 与 JIT"的结合方式。由于 C/C++ 拥有极高的性能和对底层硬件的直接操控能力，许多顶级的 JIT 编译器本身就是用 C/C++ 编写的。

LLVM（Low Level Virtual Machine）：这是一个极其著名的模块化编译器基础设施，完全由 C++ 编写。它提供了一套成熟的 JIT 编译 API（如 ORC JIT）。开发者可以在自己的 C++ 程序中嵌入 LLVM 引擎，实现在运行时动态生成 IR（中间表示），然后让 LLVM 实时将其编译成高度优化的本地机器码并直接在内存中执行。
AI 框架与深度学习：例如清华发布的计图（Jittor）深度学习框架，其前端是 Python，但后端的核心算子就是通过内置的 JIT 编译器，将代码动态编译成高性能的 C++ 或 CUDA 代码，再交由 CPU/GPU 执行，从而实现极致的运算效率。

💻 层面二：C/C++ 程序自身在运行时进行 JIT（自我编译与执行）

这是一种更硬核的玩法，指的是一个正在运行的 C/C++ 程序，能够自己在内存中"凭空"造出新的机器码并执行它。这通常用于实现某些需要极致灵活性的功能，比如公式计算器、游戏脚本引擎或热更新系统。

实现这种"真正的 C++ JIT"通常需要经历以下三个核心步骤：

动态生成机器码：程序在运行时，根据需求手写 x86-64 等架构的底层机器指令，或者借助 LLVM 等库生成对应的二进制代码。
申请可执行内存 ：通过操作系统提供的接口（如 Linux/macOS 下的 mprotect 或 Windows 下的 VirtualProtect），向系统申请一块具有"可读写且可执行"权限的内存区域。
跳转执行：将生成的机器码写入这块内存，然后通过函数指针强制跳转到该内存地址，CPU 就会像执行普通函数一样去执行这段刚刚动态生成的代码。

⚖️ 既然 C/C++ 可以实现 JIT，为什么大家普遍觉得它是 AOT 语言？

这主要是由设计目标 和使用成本决定的：

维度	传统 AOT 编译 (GCC/Clang)	动态 JIT 编译 (手写/LLVM)
编译时机	离线静态编译，一次编译多次运行	在线动态编译，边运行边翻译
复杂度	极低，一条命令即可完成	极高，需处理内存权限、调用约定、ABI 兼容等底层细节
适用场景	绝大多数通用软件开发	特定领域的极致优化（如 AI 算子融合、动态表达式求值）
调试难度	较低，有成熟的断点调试工具	困难，动态生成的代码难以映射回源码进行调试

总结来说，C/C++ 不仅能做 JIT，而且是构建高性能 JIT 系统的基石。只是在常规的业务开发中，AOT 带来的确定性、独立性和零运行时开销更符合大多数场景的需求；而在那些需要"在运行时根据实时数据生成最优指令"的特殊场景下，C/C++ 的 JIT 能力才会大显身手。

AOT和JIT都是要编译程序为机器码，最终编译的结果有什么不同

你的理解完全正确，AOT（提前编译）和 JIT（即时编译）的最终产物确实都是机器码 ，CPU 最终执行的也都是这些冷冰冰的 0 和 1。

它们最根本的区别不在于"结果是什么"，而在于**"这份机器码是在什么时候、由谁、根据什么信息造出来的"**。这就好比同样是做一道菜（最终的机器码），一个是中央厨房提前做好的预制菜（AOT），一个是米其林大厨根据你的实时口味现场烹饪的（JIT）。

具体来说，这两者生成的机器码在以下三个核心维度上有本质的不同：

📝 1. 优化依据不同：静态猜测 vs 动态事实

AOT（静态编译）：编译器在打包程序时，根本不知道你的程序运行起来会是什么样。它只能基于代码本身进行**"静态分析"和"保守猜测"**。比如遇到一个虚函数调用，AOT 编译器不知道实际会调用哪个子类的方法，只能生成一段通用的、相对繁琐的查找指令。
JIT（动态编译）：它在程序运行时工作，拥有"上帝视角"。它会监控程序的执行，收集真实的**"运行时数据"**。比如它发现某个虚函数在过去 10000 次调用中，9999 次调用的都是同一个子类方法，JIT 就会大胆地生成一份极度优化的机器码：直接内联这个方法，并加一个简单的判断兜底。这种基于真实数据的激进优化，是 AOT 无法做到的。

🌍 2. 适配程度不同：通用兼容 vs 量身定做

AOT（静态编译） ：为了保证你编译好的程序能在各种同架构的电脑上跑，AOT 编译器通常会生成兼容性较好但未必是最快的机器码。例如，它可能只会使用最基础的 x86-64 指令集，而不敢轻易使用某些新款 CPU 才有的高级向量扩展指令（AVX-512等），否则老旧电脑就会报错崩溃。
JIT（动态编译）：因为它就在你的电脑上运行，它非常清楚你当前的 CPU 到底支持哪些高级特性。因此，JIT 可以生成**为你当前硬件"量身定做"**的机器码，充分利用最新的指令集来加速计算。

🔗 3. 产物形态与生命周期不同：永久固化 vs 内存缓存

AOT（静态编译） ：生成的机器码会被永久固化 在硬盘上的可执行文件（如 .exe 或 Linux 下的无后缀二进制文件）里。每次运行，操作系统就把这份固定的机器码加载到内存执行。
JIT（动态编译） ：生成的机器码是临时存放在内存中的。程序刚启动时，硬盘上只有中间字节码；运行一段时间后，内存中才会逐渐出现 JIT 编译好的高效机器码。一旦程序关闭，这些精心优化的机器码就随风消散了，下次启动还得重新经历一遍"预热"过程。

为了让你更直观地感受这两份"机器码"的差异，可以参考下表：

维度	AOT 产出的机器码	JIT 产出的机器码
优化逻辑	基于静态规则，保守且通用	基于运行时热点数据，激进且特化
硬件适配	兼顾老设备，兼容性优先	榨干当前 CPU 性能，效率优先
存在形式	硬盘上的固定文件	内存中的临时缓存
典型比喻	批量印刷的教科书（人手一本，内容固定）	老师根据你的错题定制的辅导讲义（千人千面）

所以，虽然终点都是机器码，但 AOT 赢在起跑线（启动极快，拿来就能跑） ，而 JIT 赢在长途奔袭（跑得越久，状态越好，极限速度越快）。

为什么不都采用JIT的编译方式

既然 JIT（即时编译）能榨干硬件性能，还能做各种激进的动态优化，那为什么我们不把所有程序都做成 JIT 呢？

这主要是因为 JIT 并不是完美的，它为了追求极致的运行时速度，牺牲了其他几个非常关键的维度。如果把所有程序都强行改成 JIT，会带来以下几个无法忽视的硬伤：

⏳ 1. 启动慢与"预热期"的代价

JIT 需要一边运行一边收集数据、一边编译。这就导致程序在刚启动时，跑的是效率较低的解释执行代码或初步编译的代码，必须经过一段时间的"热身"才能达到性能巅峰。

日常体验灾难：想象一下，你只是想打开一个简单的命令行工具查个文件，或者点开一个桌面软件看一眼，结果却要等好几秒甚至更久的"预热"，这种体验是极其糟糕的。
云原生场景不适用：在现代的云原生和 Serverless（无服务器架构）中，很多服务生命周期极短，可能只运行几百毫秒处理完请求就销毁了。对于这种"短命"的程序，JIT 还没来得及热身完毕程序就结束了，完全发挥不出它的优势，反而白白浪费了资源。

💾 2. 额外的内存与 CPU 开销

JIT 编译器本身就是一个嵌在程序里的"重量级插件"。

内存占用高：JIT 需要在内存里开辟专门的区域（Code Cache）来存放编译好的机器码，同时编译器自身运行也需要消耗大量内存。在手机、物联网设备等内存极其紧张的环境下，JIT 可能会成为拖垮系统的负担。
抢占 CPU 资源：在程序运行的过程中，JIT 编译过程会持续占用宝贵的 CPU 算力。这意味着，原本可以 100% 用于执行业务逻辑的 CPU，不得不分出精力去搞"自我翻译"。

📱 3. 平台限制与安全红线

这是最致命的一点：很多主流平台根本不允许使用 JIT。

iOS 的禁令：苹果出于系统安全和生态管控的考虑，明确禁止 App Store 中的应用在运行时动态生成机器码。因此，所有的 iOS 应用（包括用 Unity 开发的游戏）都必须采用 AOT 提前编译。如果全采用 JIT，你的程序连苹果手机都上不了。
浏览器沙箱：Web 端的前端代码运行在浏览器的严格沙箱中，出于防范恶意代码注入的安全考量，也无法像传统桌面程序那样随意进行大规模的动态编译。

🔗 4. 牺牲跨平台特性与动态灵活性

打破"一次编写，到处运行"：Java 等语言的核心优势在于中间字节码可以跨平台。如果全部采用 JIT，虽然字节码依然跨平台，但如果为了极致性能引入 AOT 辅助（如 GraalVM Native Image），生成的产物就会绑定特定操作系统，失去了 Java 最大的生态红利。
限制动态特性：JIT 能够完美支持反射、动态代理等 Java 的高级动态特性。而如果为了规避 JIT 的缺点转向 AOT，这些依赖于"运行时才知道发生了什么"的动态功能就会受到极大的限制，甚至需要极其繁琐的手动配置才能生效。

为了让你更直观地理解为什么不能"一刀切"，我们可以看看这两种策略在实际中的分工：

维度	JIT (即时编译)	AOT (提前编译)
核心优势	峰值性能极高，越跑越快	启动极快，内存占用低
核心劣势	启动慢，吃内存/CPU，有平台限制	缺乏动态优化，失去部分跨平台性
典型适用场景	长期运行的后端服务、大数据计算	手机App(iOS)、命令行工具、Serverless

所以，现代计算机世界并没有选择"二选一"，而是走向了融合与平衡。例如，现代的 JVM（Java虚拟机）默认采用"混合模式"：程序刚启动时用解释器快速响应，发现哪些代码是热点后再交给 JIT 编译优化；而像安卓系统则会在安装应用时做一部分 AOT 编译保证启动速度，同时在空闲时利用 JIT 继续优化后续的性能。根据具体的业务场景选择合适的编译策略，才是最聪明的做法。

Java 如果采用AOT，失去最大红利是什么意思

这句话确实有点绕，因为它触及了 Java 发展过程中一个非常有趣的"自我矛盾"。要理解这句话，我们得先搞清楚 Java 传统的"跨平台"到底是怎么实现的：

🌍 传统 Java 的"中间商赚差价"模式（JIT）

Java 之所以能吹嘘"一次编写，到处运行"，是因为它玩了一个很聪明的花招：

你写代码：你在 Windows 电脑上写好 Java 代码。
编译成"通用语" ：Java 编译器把它翻译成一种中间的、通用的格式 ，叫做"字节码"（.class 文件）。这个字节码谁也看不懂，除了 Java 虚拟机（JVM）。
到处分发：你把这份"字节码"发给用 Mac 的同事、用 Linux 的服务器，完全没问题。
本地翻译（JIT）：每台电脑上都装有一个专属的 JVM（比如 Windows 版 JVM、Mac 版 JVM）。程序运行时，JVM 会充当"同声传译"，当场把这些通用的字节码，实时翻译成自己系统能听懂的机器码（这就是 JIT）。

结论：因为大家传递的都是那份"通用的字节码"，所以实现了跨平台。

⛓️ 为了极致性能引入 AOT（如 GraalVM）发生了什么？

后来大家发现，JVM 这个"同声传译"虽然方便，但太占内存，而且启动时还得现翻译，速度不够快。于是出现了像 GraalVM Native Image 这样的 AOT（提前编译）技术。

AOT 的做法非常直接粗暴：它把"同声传译"给开除了。

当你使用 AOT 辅助时，编译器不再生成那个"通用的字节码"，而是直接在打包阶段，就把你的代码彻底翻译成了特定系统的机器码。

如果你在 Windows 上用 AOT 打包，生成的就是一个纯粹的 .exe 文件。
这个 .exe 文件里已经没有那些通用的字节码了，全是 Windows 系统能直接执行的 0 和 1。

后果：

这时候，如果你把这个在 Windows 上打包好的 .exe 文件发给用 Mac 或 Linux 的同事，他们根本打不开！因为这个文件是专门为 Windows "量身定做"的死板机器码，里面没有通用的字节码，也没有 JVM 来帮它做二次翻译。

💡 总结："生态红利"是怎么丢的？

回到你那句话：

"如果全部采用 JIT"：大家手里拿的都是通用的字节码，去哪都能跑，享受到了 Java 最大的便利（生态红利）。
"引入 AOT 辅助" ：为了追求启动快、省内存（极致性能），你交出的不再是通用字节码，而是一个绑定了特定操作系统的二进制文件。
"失去了生态红利"：你原本只需要维护一份代码包就能发给所有人，现在你必须分别为 Windows、Linux、Mac 各打包一次，发三个不同的版本。这就变得和 C/C++ 一样麻烦了，Java 原本引以为傲的"走到哪跑到哪"的优势，在这个特定的 AOT 场景下就荡然无存了。

打个比方：

JIT（传统 Java）：你写了一本《乐谱》（字节码），全世界的钢琴家（JVM）拿到这本谱子，都能在自己的钢琴上弹出来。
AOT（GraalVM）：你为了追求极致的演奏效果，直接把这首曲子录成了一张 CD（特定平台的机器码）。你把这张 CD 发给别人，如果别人的播放器制式不匹配（比如你是 NTSC 制式，他是 PAL 制式），他就根本放不出来声音。