SpringBoot弃用spring.factories改用AutoConfiguration.imports的原因及问题解析

SpringBoot 3.x正式移除了用于自动配置的spring.factories文件，改用org.springframework.boot.autoconfigure.AutoConfiguration.imports替代。官方在相关Issue中提到原机制会对"原生工作"造成问题，但未展开说明，以下是具体的技术解析：

核心问题解析 #

1. GraalVM原生镜像构建的适配障碍 #

spring.factories基于Java的ServiceLoader机制实现，依赖运行时动态扫描JAR包中的META-INF/spring.factories文件来加载自动配置类。但GraalVM原生镜像构建需要静态代码分析，无法识别这种运行时动态加载的逻辑，会导致自动配置类被遗漏，最终原生镜像启动时出现配置缺失、功能异常的问题。

而AutoConfiguration.imports采用静态声明的方式，每行直接列出一个自动配置类的全限定名，GraalVM可以在构建阶段直接解析这些类名，将对应的配置类打包进原生镜像，完美适配SpringBoot的原生镜像支持方案。

2. 启动加载效率的提升 #

使用spring.factories时，SpringBoot启动阶段需要扫描所有依赖JAR包中的META-INF/spring.factories文件，再解析文件中的配置类列表，这个扫描和解析过程在依赖较多的项目中会增加启动时间。

AutoConfiguration.imports省去了文件扫描步骤，启动时直接读取文件中声明的类名进行加载，大幅减少了启动阶段的IO操作和解析开销，提升了应用启动速度。

3. 配置的可读性与维护性优化 #

spring.factories中自动配置类以逗号分隔的形式集中在一行或多行，当配置类数量较多时，查找、修改特定配置类变得繁琐，也不利于排查配置冲突。

AutoConfiguration.imports采用每行一个类的格式，结构清晰直观，开发者可以快速定位到需要的配置类，在自定义自动配置、排除默认配置时更高效。

4. 与Spring核心机制的对齐 #

Spring框架本身在逐步推进静态声明式的配置方式（比如@Import注解），AutoConfiguration.imports的设计更贴合Spring的核心理念，将自动配置的导入逻辑从动态扫描转向静态声明，让配置逻辑更透明，也更容易与Spring的条件配置、配置优先级等特性集成。

官方说明引用 #

使用spring.factories查找自动配置类会对我们的原生工作造成问题。最初使用它是因为已有可用代码，但我们希望在2.7版本提供替代方案，并在3.0版本停止将spring.factories用于自动配置。

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