当提到 "Java 原生编译"（GraalVM Native Image），你想到的是什么？无尽的 JSON 元信息配置文件、反复试错的反射登记、比应用本身还复杂的构建脚本？

Solon 换了一条路。它的 AOT 流水线采用三段式编译，前一阶段的产出自动喂给下一阶段。框架的"克制"哲学——最小化动态代理、用显式配置替代"魔法"——使得原生编译比你想的简单。

三段式流水线

Solon Native 编译分三个阶段，每个阶段都可以独立运行：

第二阶段是 Solon 真正干活的地方。

深入第二阶段：Solon AOT

Solon AOT 处理器（SolonAotProcessor，来自 solon-aot 模块）在使用 -P aot profile 时，自动在 mvn package 之后执行。

它在编译时启动你的应用程序，完整走一遍启动流程，捕获框架在运行时需要的所有信息：

• 代理类预编译——原本需要在运行时通过 ASM 字节码生成的 AOP 动态代理，在构建阶段就编译成真实的 .class 文件
• 类索引生成——项目类多的时候，这个索引通过跳过类路径扫描来加速启动
• GraalVM 元信息生成——反射、资源、序列化的元信息自动写入 GraalVM 原生配置格式

关键细节：自 v3.7.2 起，-P aot 可以在任意 JDK（不只是 GraalVM）上运行。-P aot 去掉了 GraalVM 构建工具依赖，让 AOT 成为一个轻量优化过程，即使你还在 JDK 8 上也能用。

当你准备编译完整的原生二进制时，使用 -P native——它会引入 GraalVM 的 native-maven-plugin（需要 GraalVM JDK）。

能得到什么

用 Solon 编译原生可执行文件，换来的是：

• 毫秒级启动——没有 JVM 预热，没有类加载开销
• 内存介于 JVM 和 Go 之间——GraalVM 原生镜像去掉了所有未使用的代码
• 独立二进制文件——不需要 JRE，不需要 java -jar。直接 ./myapp

这些优势对 Serverless 函数、容器化微服务和 CLI 工具尤其有意义。

现实：原生编译的限制

GraalVM 原生镜像有一些硬约束。以下是 Solon 的 AOT 流水线自动处理的内容：

手动补充：RuntimeNativeRegistrar

没有自动系统是完美的。那些在 Solon 托管范围之外使用反射或加载资源的第三方库，需要手动登记。

Solon 提供了 RuntimeNativeRegistrar 接口——一个 @Component bean，让你完全控制登记内容：

@Component
public class NativeRegistrar implements RuntimeNativeRegistrar {
    @Override
    public void register(AppContext ctx, RuntimeNativeMetadata metadata) {
        // 登记未自动检测到的资源文件
        metadata.registerResourceInclude("com/mysql/jdbc/LocalizedErrorMessages.properties");
        
        // 登记需要序列化的类
        metadata.registerSerialization(JsonResult.class);
        
        // 登记需要反射访问的类，指定成员类别
        metadata.registerReflection(BufferedImage.class, 
            MemberCategory.INVOKE_DECLARED_CONSTRUCTORS,
            MemberCategory.INVOKE_DECLARED_METHODS);
    }
}

第三方库通常分四类：

• A：不支持——使用动态编译或字节码操作的框架（如 CGLIB 代理）。原生下无法工作。
• B：需要较多配置——如 mysql-connector-java 5.x。需要额外的登记工作。
• C：需要少量配置——如 mysql-connector-java 8.x。一两个资源登记就够了。
• D：完全支持——库自带 native-image 元信息。

Solon 团队用 nginxWebUI 做了完整的适配案例——一个真实项目，大约花了大半天完成适配。

原生感知代码工具

在编写可能在 JVM 和原生环境都能运行的代码时，有三个工具类：

• NativeDetector.inNativeImage() —— 检测是否在原生镜像中运行
• ResourceUtil —— 原生兼容的资源获取
• ReflectUtil —— 原生兼容的反射工具

它们在 JVM 上委托给标准 Java 反射，在原生镜像中从注册的元数据读取。

快速上手

想自己试试？只需要几步：

1. 添加依赖——solon-aot（org.noear，由 BOM 管理版本）
2. 安装 GraalVM——JDK 17、21 或 25；运行 gu install native-image
3. 单模块项目：mvn clean -P native native:compile -DskipTests
4. 多模块项目：先对所有模块执行 mvn install，然后在主模块执行 -P native native:compile

生成的二进制文件在 target/ 下——不需要 JRE，直接运行。

诚实的局限性

Solon 的 AOT 流水线是务实的，不是万能的：

1. 首次编译很慢——GraalVM 需要分析整个闭包世界。不是秒级，是分钟级。
2. 不是所有库都能用——如果依赖用了动态类加载或字节码生成，要么替换它，要么跳过原生编译。
3. -P aot 对小项目没什么用——对只有 ~10 个类的最小项目，启动提升可以忽略（文档里用 native-example 在 2020 款 MacBook Pro 上验证过）。

三段式编译是 Solon 对 Java 原生编译的务实回答：尽可能自动化，同时诚实地告诉你边界在哪。-P aot profile 可以在任意 JDK 上使用，让你在不投入完整原生编译的前提下获得元信息生成的好处。

如果你之前因为配置复杂而回避 GraalVM，Solon 的流水线移除掉了大部分摩擦。手动补充接口在那里，但大多数时候你不会需要它。