GraalVM 原生映像（Native Image）支持标准构建与 -Ob（Quick Build Mode）两种编译模式：前者执行完整静态分析与多轮优化，生成高度优化、生产就绪的二进制；后者跳过部分激进优化以显著缩短构建时间，适用于开发迭代。
graalvm 原生映像（native image）支持标准构建与 `-ob`（quick build mode）两种编译模式：前者执行完整静态分析与多轮优化，生成高度优化、生产就绪的二进制；后者跳过部分激进优化以显著缩短构建时间，适用于开发迭代。
在使用 Maven 构建 Spring Boot 应用为 GraalVM 原生可执行文件时，标准命令为：
mvn clean -Pnative native:compile
而构建日志末尾提示的 QBM: Use the quick build mode ('-Ob') to speed up builds during development. 指向的是 Quick Build Mode —— 一个专为开发阶段提速设计的实验性优化开关。
? -Ob 的工作原理
-Ob 并非简单“关闭所有优化”，而是有选择地禁用若干耗时高、对开发调试收益低的优化阶段，主要包括：
- 跳过部分跨方法内联（aggressive inlining）与死代码消除（DCE）的深度迭代；
- 减少基于调用图（call graph）的上下文敏感分析轮次；
- 禁用某些针对小函数体的循环向量化与指令重排策略；
- 保留更多调试符号与元数据（便于后续诊断，但略微增大二进制体积）。
这些调整通常可将构建时间缩短 30%–60%（取决于项目规模与依赖复杂度），尤其在频繁修改后需快速验证本地行为时效果显著。
⚠️ 使用 -Ob 的注意事项（即“demerits”）
虽然开发友好，但 -Ob 构建产物存在明确约束，不可用于生产环境：
| 维度 | 标准构建（默认） | 快速构建（-Ob） |
|---|---|---|
| 性能 | 经过多轮 AOT 优化，峰值吞吐与内存效率最优 | 启动更快，但运行时 CPU/内存开销略高（典型 +5%~15%） |
| 二进制大小 | 更紧凑（更激进的裁剪与压缩） | 略大（保留冗余元数据与未优化桩代码） |
| 兼容性保障 | 全面验证反射、JNI、动态代理等配置 | 部分边缘路径可能因分析不足而触发运行时异常（如 ClassNotFoundException 或 UnsupportedFeatureError） |
| 可重现性 | 确定性构建（相同输入 → 相同输出） | 受 JVM 启动参数与宿主机状态影响略增 |
✅ 最佳实践建议：
- 开发阶段：始终启用
-Ob，配合--no-fallback（确保提前暴露动态特性缺失）与--report-unsupported-elements-at-runtime（延迟报错便于调试）；- CI/CD 与发布流水线：必须禁用
-Ob，使用纯净标准构建，并搭配--strict-jni,--enable-url-protocols=http,https等显式加固选项；- 验证技巧：可通过
nm -C your-app | grep "Universe"或objdump -t your-app | grep "gc\|heap"辅助判断优化深度差异。
? 如何启用 -Ob？
在 Maven 命令中直接追加系统属性即可（无需修改 pom.xml）：
mvn clean -Pnative native:compile -Dnative.image.build.args="-Ob"
或在 pom.xml 的 <configuration></configuration> 中持久化（仅推荐用于开发 profile）：
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>
<arg>-Ob</arg>
<arg>--no-fallback</arg>
</buildArgs>
</configuration>
</plugin>总之，-Ob 是 GraalVM 提供的关键开发加速杠杆——它不牺牲功能正确性，但主动权衡了运行时效率与构建速度。理解其边界并分场景选用，是高效落地原生映像技术的核心能力之一。
