SpringBoot 3.0 挥别 spring.factories，拥抱云原生新纪元

Hi，各位 Spring Developers。

如果你从 Spring Boot 1.x 或 2.x 的时代一路走来，那么 META-INF/spring.factories 这个文件对你来说一定不陌生。它就像是 Spring Boot 自动配置王国里一位沉默但权势滔天的“老臣”，默默地支撑着整个自动配置体系的运转。然而，在 Spring Boot 3.0 的浪潮中，这位“老臣”被光荣地“劝退”了。

这个变化绝非小题大做。它是一次深刻的架构演进，其背后是 Spring 团队对性能、可维护性以及未来技术趋势（特别是 GraalVM 原生镜像）**的深思熟虑。

一：spring.factories 的黄金时代与隐忧

1. 它是什么？

本质上，spring.factories 是 Spring 框架实现的一种通用的 SPI (Service Provider Interface) 机制的变体。它是一个位于 classpath 下 META-INF/ 目录中的标准 Properties 文件，其核心作用是实现类与接口的解耦。

在 Spring Boot 中，它最广为人知的用途就是注册自动配置类。

2. 它是如何工作的？

当一个 Spring Boot 应用启动时，它会执行一系列引导操作。其中关键的一步就是扫描整个应用的 classpath（包括所有依赖的 JAR 包），查找所有名为 META-INF/spring.factories 的文件。

代码示例：一个典型的自定义 Starter

假设我们正在编写一个 my-custom-starter，它提供了一个 MyCustomService 的自动配置。

步骤 1：创建自动配置类

// MyCustomAutoConfiguration.java
@Configuration
@ConditionalOnClass(MyCustomService.class)
@EnableConfigurationProperties(MyCustomProperties.class)
public class MyCustomAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public MyCustomService myCustomService(MyCustomProperties properties) {
        // ... 根据 properties 创建 MyCustomService 实例
        return new MyCustomService(properties.getGreeting());
    }
}

步骤 2：在 spring.factories 中注册

我们需要在 src/main/resources/META-INF/spring.factories 文件中进行注册：

# Auto-Configuration
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.my.starter.MyCustomAutoConfiguration

启动流程图解 

这个机制非常灵活，任何第三方库都可以通过提供自己的 spring.factories 文件，无缝地将其配置类集成到 Spring Boot 的生态中。

3. 时代的眼泪：spring.factories 的三大“原罪”

尽管功勋卓著，但随着技术的发展，spring.factories 的弊端也日益凸显：

1. 性能瓶颈：应用启动时，Spring Boot 必须遍历整个 classpath，打开、读取、解析每一个 spring.factories 文件。在一个大型的、拥有数百个依赖的微服务项目中，这会产生显著的 I/O 开销和计算负担，拖慢了宝贵的启动时间。

2. 可读性与维护性差：所有类型的 SPI 配置都堆在同一个文件里，比如 ApplicationListener, EnvironmentPostProcessor, EnableAutoConfiguration 等。当文件内容变多时，会变得混乱且难以维护。

3. 对 AOT (Ahead-Of-Time) 编译不友好：这是最致命的一点。为了实现像 GraalVM 这样的原生镜像技术，需要在编译时就确定所有需要加载的类。spring.factories 的动态扫描机制与此背道而驰。AOT 编译器很难在编译期静态地、高效地分析出所有需要被实例化的配置类，这使得构建高度优化的原生应用变得异常困难。

为了拥抱云原生，追求更快的启动速度和更低的内存占用，变革势在必行。

二：新王登基 - AutoConfiguration.imports

Spring Boot 2.7 开始引入了新的机制作为过渡，并在 3.0 中正式将其确立为标准。spring.factories 中用于自动配置的部分，被一个更简单、更高效的文件所取代。

1. 新的约定

新的约定是，在 META-INF/spring/ 目录下（注意，比之前多了一层 spring/ 目录），创建一个名为 org.springframework.boot.autoconfigure.AutoConfiguration.imports 的文件。

2. 它是如何工作的？

这个新文件不再是 Properties 格式，而是一个纯文本文件。它的内容非常简单：每一行列出一个自动配置类的全限定名。

代码示例：迁移到新的 Imports 文件

对于我们之前的 my-custom-starter，我们不再需要 spring.factories，而是创建 src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件：

com.example.my.starter.MyCustomAutoConfiguration

就是这么简单！没有键值对，只有类的列表。

启动流程图解：

3. 新架构的压倒性优势

1. 极致的性能：Spring Boot 不再需要进行宽泛的 classpath 扫描和复杂的 Properties 文件解析。它只需要精确定位并按行读取一个简单的文本文件。这个改变极大地提升了应用的启动速度。

2. AOT 和 GraalVM 的完美搭档：这种静态的、明确的列表格式对 AOT 编译器极其友好。编译器可以在构建时轻松地读取所有 .imports 文件，准确无误地识别出所有自动配置类，从而生成高度优化的、无反射的、启动飞快的原生可执行文件。

3. 职责单一，清晰明了：一个文件只做一件事——声明自动配置类。这使得代码库更加整洁，开发者的意图也一目了然。

三：开发者迁移指南

作为开发者，我们该如何适应这一变化？

• 对于库/Starter 的作者：

  1. 创建新文件：在 src/main/resources/META-INF/spring/ 目录下创建 org.springframework.boot.autoconfigure.AutoConfiguration.imports。

  2. 迁移配置：将 spring.factories 文件中 org.springframework.boot.autoconfigure.EnableAutoConfiguration 键下的所有类名，复制到新的 .imports 文件中，每行一个。

  3. 保持向后兼容（可选）：如果你的库需要同时支持 Spring Boot 2.x 和 3.x，你可以同时保留 spring.factories 和新的 .imports 文件。Spring Boot 2.7 会优先使用新的 .imports 文件，但仍会识别旧的 spring.factories；而 Spring Boot 3.0+ 将只识别新的 .imports 文件来加载自动配置。

• 对于应用开发者：

  • 绝大多数情况下，你无需做任何事。你所依赖的 Spring Boot Starters 和第三方库的维护者会完成这个迁移。你只需要确保将依赖升级到兼容 Spring Boot 3.0 的版本即可。

  • 如果你在自己的应用代码中定义了 spring.factories 来实现自动配置，那么你需要按照上述“库作者”的指南进行迁移。

结论：一次面向未来的进化

从 spring.factories 到 AutoConfiguration.imports 的转变，是 Spring Boot 发展史上一次意义重大的“断舍离”。

它告别了过去灵活但略显沉重的动态扫描机制，全面拥抱了一个更快速、更清晰、为 AOT 和云原生量身定制的静态声明模型。

这次进化再次证明了 Spring 框架的活力及其不断自我革新的决心。它为我们开发者铺平了通往更高效、更现代化的 Java 应用开发的道路。