为什么 SpringBoot 宁可挨骂也要干掉 spring.factories？

作者：微信小助手

发布时间：2025-07-19T10:08:30

兄弟们，今天咱们来聊一个 SpringBoot 社区里的 “劲爆” 话题 —— 为什么 SpringBoot 宁可被骂也要干掉 spring.factories？这个问题就像一颗投入平静湖面的石子，在开发者圈里掀起了不小的波澜。很多老司机可能会问：“spring.factories 用得好好的，干嘛要改？” 别急，咱们今天就来扒一扒这背后的 “恩怨情仇”。

一、spring.factories 的前世今生

（一）曾经的 “功臣”

在 SpringBoot 的早期版本中，spring.factories 可是个 “大红人”。它就像一个神奇的 “配置管家”，允许第三方库通过 META-INF/spring.factories 文件注册自动配置类。比如说，你引入一个数据库驱动的依赖，它就能自动帮你配置好数据源，是不是很方便？

那它是怎么工作的呢？简单来说，SpringBoot 启动的时候，会扫描所有 JAR 包中的 META-INF/spring.factories 文件，然后根据里面的配置加载对应的自动配置类。这种 “约定优于配置” 的方式，大大减少了开发者的工作量，让我们可以快速搭建应用。

（二）暗藏的 “隐患”

但是，随着时间的推移，spring.factories 的问题也逐渐暴露出来。就像一个看似完美的人，身上却隐藏着一些致命的缺点。

  1. 启动速度的 “噩梦”

想象一下，当你的项目依赖了成百上千个 JAR 包时，SpringBoot 就像一个勤劳的 “扫街工”，要一个一个地扫描每个 JAR 包中的 spring.factories 文件。这得多慢啊！实测显示，某电商平台在依赖 300+ 个 JAR 包的情况下，仅配置加载阶段就消耗了 2.3 秒启动时间。这对于追求高性能的现代应用来说，简直是一场 “噩梦”。

  1. 维护的 “灾难现场”

当项目越来越大，模块越来越多时，spring.factories 文件就像一个 “大杂烩”，里面的内容越来越多，维护起来简直就是一场 “灾难”。不同的模块可能会引入冲突的配置，让开发者们头疼不已。

  1. 模块化的 “绊脚石”

随着 Java 9 引入模块系统（JPMS），spring.factories 的问题就更明显了。它基于类路径扫描的方式，与模块化设计理念格格不入，无法很好地支持 Java 模块系统。

二、SpringBoot 的 “忍无可忍”

（一）性能的 “生死时速”

在这个 “速度为王” 的时代，SpringBoot 团队显然也意识到了启动速度的重要性。为了提升性能，他们决定对 spring.factories 下手。毕竟，谁也不想自己的应用启动得像 “蜗牛爬” 一样慢。

（二）模块化的 “大势所趋”

Java 模块系统的出现，标志着 Java 生态向模块化发展的趋势。SpringBoot 作为 Java 生态的重要一员，自然不能落后。而 spring.factories 这种基于类路径扫描的方式，显然已经跟不上时代的步伐了。

（三）GraalVM 的 “临门一脚”

近年来，GraalVM 原生镜像技术越来越火。它可以将 Java 应用编译成原生可执行文件，大大提升性能和启动速度。但是，spring.factories 基于运行时类路径扫描的机制，与 GraalVM 的提前编译（AOT）模型存在根本性冲突。为了更好地支持 GraalVM，SpringBoot 必须做出改变。

三、新贵登场：AutoConfiguration.imports

（一）“新管家” 的闪亮登场

为了解决 spring.factories 的问题，SpringBoot 3.0 引入了一个新的配置文件 ——META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。这个文件就像一个 “新管家”，取代了 spring.factories 的位置。

它的使用方式非常简单，只需要在文件中列出需要自动配置的类的全限定名，每行一个。例如：

com.example.MyAutoConfiguration
com.example.AnotherAutoConfiguration

这种方式不仅提高了配置的可读性和可维护性，还支持模块化管理。不同的模块可以有自己的 AutoConfiguration.imports 文件，独立维护自己的自动配置列表。

（二）性能的 “质的飞跃”

新的配置方式在性能上有了显著提升。首先，它减少了不必要的类扫描，因为每个扩展点类型使用单独的文件，避免了加载不需要的配置。其次，它与 Java 模块系统兼容，不再是模块化的 “绊脚石”。实测数据显示，使用新方案后，类加载时间减少了 30%，类加载量减少了 29%。

（三）功能的 “全面升级”

除了性能提升，新方案在功能上也有了全面升级。它支持条件化配置，开发者可以使用 @Conditional 注解来动态决定是否加载某个配置类。例如：

@AutoConfiguration
@ConditionalOnClass(name = "com.example.ExternalService")
public class MyAutoConfiguration {
    // 配置类的内容
}

这样，只有当类路径下存在 ExternalService 类时，这个配置类才会生效。这种灵活的配置方式，让开发者可以更好地控制应用的行为。

四、社区的 “爱恨情仇”

（一）开发者的 “吐槽大会”

任何重大的变更都会引起社区的讨论，这次也不例外。一些习惯了 spring.factories 的开发者开始 “吐槽”：“为什么要改？我用得好好的！”“迁移成本太高了，我不想改！” 甚至有人在社交媒体上发起了 “抗议”。

（二）Spring 团队的 “良苦用心”

面对社区的质疑，Spring 团队也给出了自己的解释。他们表示，虽然这次变更会给一些开发者带来不便，但从长远来看，这是为了提升 SpringBoot 的整体性能和可维护性。他们希望通过这次变更，让 SpringBoot 更好地适应现代 Java 生态的发展，为开发者提供更高效、更灵活的配置方式。

（三）迁移的 “最佳实践”

为了帮助开发者顺利迁移，Spring 团队提供了详细的迁移指南。首先，开发者需要识别 spring.factories 中的配置，然后将其转换为 AutoConfiguration.imports 文件。例如，将 spring.factories 中的：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.MyAutoConfiguration,\
com.example.AnotherAutoConfiguration

转换为 AutoConfiguration.imports 文件中的：

com.example.MyAutoConfiguration
com.example.AnotherAutoConfiguration

此外，开发者还可以使用 spring-boot-autoconfigure-processor 工具来优化自动配置加载，减少手动管理的负担。

五、实战案例：从 spring.factories 到 AutoConfiguration.imports

（一）创建自定义自动配置

假设我们要创建一个自定义的自动配置类 MyAutoConfiguration，它需要根据配置文件中的属性来决定是否生效。我们可以按照以下步骤进行：

  1. 创建配置属性类

@ConfigurationProperties(prefix = "myapp")
public class MyProperties {
    private boolean enabled = true;
    private String name = "default";
    // getter 和 setter 方法
}

  1. 创建自动配置类

@AutoConfiguration
@EnableConfigurationProperties(MyProperties.class)
@ConditionalOnProperty(prefix = "myapp", name = "enabled", havingValue = "true", matchIfMissing = true)
public class MyAutoConfiguration {
    private final MyProperties properties;
    public MyAutoConfiguration(MyProperties properties) {
        this.properties = properties;
    }
    @Bean
    @ConditionalOnMissingBean
    public MyService myService() {
        return new MyServiceImpl(properties.getName());
    }
}

  1. 注册自动配置

在 META-INF/spring/ 目录下创建 org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件，并添加以下内容：

com.example.MyAutoConfiguration

（二）迁移已有的配置

如果你的项目中已经使用了 spring.factories，迁移到新方案也很简单。首先，找出 META-INF/spring.factories 中的 EnableAutoConfiguration 配置项，然后将其中的自动配置类列表迁移到 AutoConfiguration.imports 文件中。例如，将：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.MyAutoConfiguration,\
com.example.AnotherAutoConfiguration

迁移为：

com.example.MyAutoConfiguration com.example.AnotherAutoConfiguration

最后，检查项目是否依赖了 spring-boot-autoconfigure-processor，并进行优化。

六、总结：拥抱变化，走向未来

SpringBoot 干掉 spring.factories 的决定，虽然在短期内引起了一些争议，但从长远来看，这是一次必要的 “革命”。新的配置方式不仅提升了性能，还增强了灵活性和可维护性，更好地适应了现代 Java 生态的发展。

对于开发者来说，虽然迁移过程可能会遇到一些困难，但这也是一个学习和成长的机会。我们应该拥抱变化，积极学习新的配置方式，让自己的技术栈跟上时代的步伐。毕竟，在技术的世界里，停滞不前就意味着落后。