GraalVM 原生映像（Native Image）支持普通构建和 -Ob（Quick Build Mode）两种编译模式：前者执行完整静态分析与多轮优化，生成高度优化、体积小、启动极快的生产级可执行文件；后者跳过部分优化阶段，显著缩短构建时间，适用于开发迭代场景。
graalvm 原生映像（native image）支持普通构建和 `-ob`（quick build mode）两种编译模式：前者执行完整静态分析与多轮优化，生成高度优化、体积小、启动极快的生产级可执行文件；后者跳过部分优化阶段，显著缩短构建时间，适用于开发迭代场景。
在使用 GraalVM 构建 Spring Boot 等 Java 应用的原生可执行文件时，Maven 命令通常为：
<code class="bash">mvn clean -Pnative native:compile</code>
该命令触发 GraalVM 的完整原生映像构建流程，包含以下关键阶段：
- 静态可达性分析（Reachability Analysis）：深度扫描所有可能被执行的代码路径（含反射、JNI、动态代理等），确保无运行时类加载；
- 提前编译（AOT Compilation）：将字节码直接编译为平台特定机器码；
- 多轮优化（如 SSA 重写、内联、死代码消除、指针压缩等）：由 Graal 编译器执行 3–5 轮高级优化，显著提升性能并减小二进制体积。
而启用快速构建模式仅需添加 -Ob 参数（注意是字母 O + 小写 b，非数字 0）：
<code class="bash">mvn clean -Pnative native:compile -Dnative.image.args="-Ob"</code>
✅ -Ob 的核心行为：
- 跳过耗时较长的中后段优化轮次（尤其是循环优化、全局寄存器分配与部分内联决策）；
- 保留基础优化（如常量传播、基本块简化、初始内联），确保功能正确性和基本性能；
- 构建时间通常可缩短 30%–60%（取决于项目规模与依赖复杂度）；
- 生成的二进制仍为完全独立的原生可执行文件，支持秒级启动与零 JVM 开销。
⚠️ 注意事项与权衡：
- 体积略大：因未执行深度死代码消除与内存布局优化，生成的二进制通常比普通构建大 10%–25%；
- 峰值性能略低：在 CPU 密集型场景（如数值计算、高吞吐序列化）下，基准测试显示吞吐量可能下降 5%–15%，但对典型 Web API（I/O-bound）影响微乎其微；
-
不适用于生产发布：
-Ob生成的镜像未通过 GraalVM 官方生产验证流程，OCI 镜像扫描或合规审计中可能被标记为“非优化构建”； -
调试友好性更高：符号信息更完整，配合
--debug-attach更易定位运行时问题。
? 推荐实践策略：
| 场景 | 推荐模式 | 理由 |
|------|----------|------|
| 日常开发/本地验证/CI 快速反馈 | ✅ -Ob | 缩短 mvn native:compile 迭代周期，提升 TDD 效率 |
| Staging 测试/性能基线比对 | ❌ 普通构建（默认） | 确保与生产环境行为一致 |
| 生产部署/容器镜像发布 | ✅ 普通构建（禁用 -Ob） | 获得最小体积、最高启动速度与最佳长期运行性能 |
? 提示：Spring Boot 3.2+ 与 Quarkus 3.x 已将
-Ob深度集成至开发工具链。例如，Quarkus Dev UI 中点击 “Build Native (Quick)” 即自动注入-Ob；Spring Boot 的spring-native-maven-plugin也支持<quickbuild>true</quickbuild>配置项，语义更清晰。
总之，-Ob 不是“降级”，而是面向开发效率的有意识权衡——它牺牲了部分后端优化换来了更快的反馈闭环。理解其机制并按阶段选用，是高效落地 GraalVM 原生映像的关键一步。
