jit是运行时动态编译，aot是构建期静态编译；jit依赖运行时热点识别，需预热，启动慢但运行时优化强；aot依赖编译期可达性分析，启动快但兼容性差、需手动处理反射等动态特性。
JIT 是运行时动态编译，AOT 是构建期静态编译
JIT（Just-In-Time）编译器内置于 JVM 中，程序启动后靠解释器先跑着，等某段代码被反复执行（比如循环体、高频接口），JVM 才把它识别为“热点”，交给 JIT 编译成机器码缓存起来——这过程要预热，所以第一次请求慢、冷启动明显。native-image 则完全不同：它在打包阶段就把整个应用（含依赖的 JVM 子集）静态分析、裁剪、编译成一个独立二进制文件，不带 JVM，启动即执行，毫秒级响应。
- 典型现象：
java -jar app.jar启动要 2–5 秒；./app-native启动常低于 50ms - 根本差异：JIT 依赖运行时行为做决策，AOT 依赖编译期可达性分析——一旦有反射、动态代理、Spring 的
@Value或 JSON 反序列化，AOT 就可能直接失败或运行时报ClassNotFoundException - 兼容性代价：AOT 编译产物是平台绑定的，
linux-x86_64编出来的不能在mac-arm64上跑；JIT 字节码则跨平台通用
Spring Boot 3 默认开启 AOT，但实际仍需手动适配
Spring Boot 3 引入了 spring-aot 模块，在构建时自动生成 AOT 处理后的字节码（如代理类、配置元数据），但它不是 GraalVM native-image，只是为后续原生编译铺路。真要生成原生镜像，你仍得用 GraalVM 的 native-image 工具，并处理大量运行时特性缺失问题。
- 必须加参数：
--no-fallback，否则构建失败会悄悄回退到 JVM 模式，掩盖真实问题 - 常见报错：
Error: com.oracle.svm.hosted.substitute.DeletedElementException，说明某类/方法被 AOT 裁剪了，需通过reflect-config.json显式注册反射入口 - Spring 官方推荐组合：
mvn spring-boot:build-image（构建容器镜像） +native-image（生成原生可执行文件），二者路径不同、产物用途也不同
JIT 和 AOT 不是二选一，而是按场景混用
Java 21+ 的 Project Leyden 正在推动混合路线：核心框架代码 AOT 静态编译保启动速度，业务逻辑中高频路径仍由 JIT 运行时优化。Spring Boot 3.3+ 也支持在 AOT 构建基础上，对特定 Bean 启用 JIT 动态重编译（通过 @JitOptimized 注解标记）。
- 微服务网关、Serverless 函数：优先 AOT，资源敏感、生命周期短
- 后台批处理、实时风控引擎：JIT 更合适，运行时间长、数据模式多变，JIT 的循环向量化、分支预测优化能持续生效
- 别迷信 “AOT 一定更快”：空载下 AOT 内存占用低，但高并发时 JIT 编译的热点代码执行效率仍普遍高于 AOT 的通用优化版本
GraalVM 的 native-image 构建失败，90% 是因为没处理好动态特性
AOT 最痛的点不是技术门槛，而是它把原本 JVM 运行时容忍的“模糊性”全暴露成构建错误。比如 Spring 的 @ConditionalOnClass、Lombok 的注解处理器、甚至 Class.forName("xxx") 都可能让 native-image 在静态分析阶段直接放弃该类。
立即学习“Java免费学习笔记（深入）”；
- 第一步：加
--report-unsupported-elements-at-runtime，让构建成功但运行时报错，快速定位哪些类没注册 - 第二步：用
native-image-agent运行一次 JVM 版本，自动收集反射、JNI、资源访问日志，生成reflect-config.json等配置文件 - 第三步：Spring Boot 用户务必检查
spring-native是否已废弃（2024 年起官方移除），改用spring-aot-maven-plugin+spring-graal-native插件链
