直接回答：Native Image 把 Java 应用 AOT 编译成原生可执行文件：启动从秒级降到几十毫秒、常驻内存减半以上、无需 JVM——收益集中在启动速度与内存密度，这让 Java 在 Serverless/CLI/短生命周期任务里第一次有竞争力。代价：构建时间从分钟涨到十几分钟；峰值吞吐通常略低于充分 JIT warmed-up 的 HotSpot（JIT 有运行时画像优势，除非用 PGO）；反射、动态代理、资源加载、JNI 等动态特性必须在构建期声明（reachability metadata），否则运行期 NoSuchMethod。
展开解析：工程现实：Spring Boot 3/Quarkus/Micronaut 的一等支持把反射元数据的苦活消化了大半（AOT 处理期自动生成），但引入任意第三方库仍可能踩未覆盖的动态特性，排查靠 agent 模式（跑一遍应用自动记录元数据）与社区 metadata 仓库。适用画像：函数计算与弹性到零的容器（冷启动敏感）、CLI 工具（分发单文件）、sidecar/Agent 类常驻小内存组件、高密度部署的微服务（省内存=省钱）。不适合：极端追求峰值吞吐且长期运行的服务（JIT 更强）、重度使用动态类加载的框架老栈、构建管线无法容忍长构建的团队。调试与观测打折：jstack/Arthas 生态不可用，要用 native 侧的工具（gdb、自带的监控端点），JFR 支持在完善中。决策建议：拿一个真实服务做 POC，量化启动、内存、吞吐、构建耗时四个数字再全面铺开，别被启动截图冲昏头。
追问方向：PGO（Profile-Guided Optimization）能补回多少峰值性能？元数据缺失如何系统排查？
（约 500 字）