Spring Native是否已支持Spring全部组件？是否有官方路线图？

首先明确一个常见认知偏差：独立迭代的Spring Native项目在发布0.12.x版本后已经正式并入Spring Boot 3.x核心特性，不再作为独立项目维护版本，目前大家提到的Spring Native能力，本质就是Spring Boot官方提供的GraalVM原生镜像构建、AOT提前编译支持。

全组件支持现状 #

截止当前最新的Spring Boot稳定正式版，这套原生支持能力并没有实现对Spring全生态组件的100%完整支持。目前核心框架、官方主流组件的适配度已经可以覆盖绝大多数常规业务开发场景，但距离全组件无差别兼容还有一定的迭代空间。

暂未完成适配的组件与场景 #

目前存在兼容缺口的主要是以下几类：

• 长期停更的老旧第三方Spring Starter：这类组件通常依赖大量运行时反射、动态字节码增强逻辑，且没有内置GraalVM要求的可达性元数据，直接构建原生镜像大概率出现启动失败问题
• Spring官方生态的边缘小众特性：比如Spring Batch的部分自定义扩展点、Spring Integration的冷门协议适配模块、Spring MVC视图层的非热门模板引擎集成，目前没有覆盖完整的原生兼容测试，运行时可能出现未知异常
• 未做AOT适配的自定义AOP逻辑：如果业务代码中使用了强依赖JVM动态代理、运行时动态生成类的切面逻辑，且没有补充对应的原生配置，在原生模式下很容易出现功能失效的问题
• 所有自身不支持GraalVM原生镜像的第三方类库，无论和Spring的集成度多高，都无法直接在原生模式下正常运行

官方公开路线图说明 #

Spring Native的迭代规划完全公开，整体进度跟随Spring Framework、Spring Boot的主版本迭代节奏同步推进：

• 最高优先级是保障Spring核心容器、Spring Boot核心组件、Spring Cloud主流套件的原生兼容性，每个正式版本发布都会扩充已适配的组件范围，修复已知的兼容问题
• 官方团队同步维护GraalVM可达性元数据仓库，联合上游第三方开源社区补全常用类库的原生适配元数据，减少开发者手动编写适配配置的工作量
• 长期迭代目标是实现Spring官方维护的所有生态组件全量原生支持，覆盖业务开发的绝大多数常用场景

如果需要确认某个特定组件是否支持原生模式，最可靠的方式是使用对应组件的最新稳定版本实际构建一次原生镜像做功能验证，不要仅依赖文档列表判断，部分组件的适配是随版本迭代逐步补全的。

内容的提问来源于stack exchange，提问作者user9348287