摘要：你有没有过这样的经历？本地跑 SpringBoot 项目时，明明代码没改几行，启动却要等 3、4 秒；好不容易把项目迁移到 Java 17 的模块化环境，却因为 spring.factories 的类路径扫描机制报错；甚至在尝试 GraalVM 原生镜像打包时
你有没有过这样的经历？本地跑 SpringBoot 项目时，明明代码没改几行，启动却要等 3、4 秒；好不容易把项目迁移到 Java 17 的模块化环境，却因为 spring.factories 的类路径扫描机制报错；甚至在尝试 GraalVM 原生镜像打包时，直接卡在动态扫描配置这一步？
如果你是长期用 SpringBoot 2.x 的开发者，大概率对这些痛点不陌生 —— 而这一切的 “始作俑者”，其实是我们依赖了多年的 spring.factories 文件。今天就跟大家聊聊，为什么 SpringBoot 团队宁可挨骂也要干掉它，以及我们该如何平稳迁移，彻底解决这些老大难问题。
在吐槽它的问题之前，我们得先明确一个核心：spring.factories 并非 “一无是处”，它曾是 SpringBoot “约定优于配置” 理念的核心载体。
简单说，它是位于META-INF/目录下的配置文件，基于 Java SPI 机制的变种实现。你还记得吗？以前我们要注册自动配置类、应用监听器，不用手动写代码，只要在 spring.factories 里加一行配置就行，比如：
# 旧版spring.factories配置示例org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.MyAutoConfigurationorg.springframework.context.ApplicationListener=com.example.MyListenerSpringBoot 启动时，会通过SpringFactoriesLoader类扫描所有 JAR 包的这个文件，自动加载配置的类 —— 这也是为什么我们引入 starter 依赖后，很多功能 “开箱即用” 的原因。
但随着项目规模变大、依赖增多，这套机制的问题就逐渐暴露了。
这些痛点，你是不是也遇到过？
为什么 SpringBoot 3.0 要冒着重构风险取消 spring.factories？本质上是它已经跟不上技术发展的需求，尤其是在这三个方面：
你有没有注意到？当项目依赖超过 20 个 JAR 包后，启动时间会明显变长。这是因为 spring.factories 需要扫描所有 JAR 包的配置文件，逐个读取并加载类 —— 我们团队曾测过一个中型项目，单是扫描 spring.factories 就占了启动时间的 30%，从 2.8 秒硬生生拖到 3.5 秒。
对于微服务项目来说，每个服务都多等 0.7 秒，集群部署时的等待成本可想而知。
自从 Java 9 引入模块系统后，很多团队开始尝试模块化开发 —— 但 spring.factories 的类路径扫描机制，跟模块化的 “显式依赖” 理念完全冲突。
比如你在module-info.java里声明了只依赖 A 模块，但 spring.factories 可能会偷偷扫描到 B 模块的配置类并加载，导致模块边界被打破，编译时频繁报IllegalAccessError。我们去年迁移模块化项目时，光是解决 spring.factories 的冲突就花了 3 天。
现在云原生环境越来越普及，GraalVM 的原生镜像因为 “毫秒级启动、低内存占用”，成了很多微服务的首选 —— 但 spring.factories 的动态扫描机制，跟 GraalVM 的 “提前编译（AOT）” 模型根本不兼容。
GraalVM 需要在构建时就明确所有要加载的类，而 spring.factories 是运行时扫描的，导致打包原生镜像时要么报 “类未找到”，要么需要写大量反射配置，最后打包出来的镜像比传统 JAR 还大，完全失去了优势。
SpringBoot 3.0 并没有 “一刀切” 取消所有配置，而是用更高效的imports文件机制替代了 spring.factories。这套新机制不仅解决了上述痛点，还简化了配置 —— 具体怎么迁移，我分 3 步跟你说清楚：
新机制把原来 spring.factories 里的 “键值对”，拆成了不同功能的独立文件，放在META-INF/spring/目录下。最常用的对应关系如下，建议收藏：
原来的 spring.factories 键对应的 imports 文件名用途org.springframework.boot.autoconfigure.EnableAutoConfigurationorg.springframework.boot.autoconfigure.AutoConfiguration.imports注册自动配置类（最常用）org.springframework.context.ApplicationContextInitializerorg.springframework.context.ApplicationContextInitializer.imports注册应用初始化器org.springframework.context.ApplicationListenerorg.springframework.context.ApplicationListener.imports注册事件监听器比如原来在 spring.factories 里配置自动配置类，现在只要新建AutoConfiguration.imports文件，直接写类的全限定名就行，不用再写 “键” 了：
# 新版AutoConfiguration.imports配置（一行一个类）com.example.MyAutoConfigurationcom.example.UserAutoConfiguration自动配置类是我们最常写的组件，迁移时要注意两个关键变化：
注解从@Configuration换成@AutoConfiguration：虽然旧注解还能用，但@AutoConfiguration会自动触发 AOT 处理，更适合 GraalVM 环境；条件注解优先用@ConditionalOnProperty：避免用@ConditionalOnClass这类需要扫描类路径的注解，新机制下静态条件判断效率更高。给你看个完整的迁移示例，对比很明显：
// 旧版：SpringBoot 2.x的自动配置类@Configuration@EnableConfigurationProperties(MyProperties.class)@ConditionalOnClass(MyService.class)public class MyAutoConfiguration { // ...}// 新版：SpringBoot 3.x的自动配置类@AutoConfiguration // 替换@Configuration@EnableConfigurationProperties(MyProperties.class)@ConditionalOnProperty(prefix = "myapp", name = "enabled", havingValue = "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); }}对于监听器、初始化器这类扩展点，SpringBoot 3.0 推荐直接用@Bean注册，而不是写 imports 文件 —— 这样更直观，也方便调试。
比如原来在 spring.factories 里注册 ApplicationListener，现在只要在配置类里加个 @Bean 方法：
// 新版：用@Bean注册监听器@Configurationpublic class ListenerConfig { @Bean public MyListener myListener { return new MyListener; }}如果是第三方依赖里的扩展点，没法改代码，再用对应的 imports 文件注册，保持项目配置统一。
我们团队在 3 个微服务项目中迁移了新机制，实测效果很明显：
启动时间：从平均 3.5 秒降到 2.8 秒，提升约 20%；内存占用：初始化时从 320MB 降到 290MB，减少 10%；GraalVM 打包：原来需要写 50 + 行反射配置，现在不用额外配置，打包出来的镜像启动只要 150ms，比传统 JVM 快 17 倍。更重要的是，迁移过程完全兼容旧依赖 —— 如果项目里还有用 spring.factories 的第三方 starter，SpringBoot 3.0 会自动兼容，不用等第三方升级，我们可以分阶段迁移，风险可控。
微服务项目：尤其是部署在 K8s 里的服务，启动快 20% 意味着扩容时能更快响应流量；模块化开发项目：彻底解决 spring.factories 打破模块边界的问题，编译更顺畅；尝试 GraalVM 的项目：新机制是原生镜像打包的 “刚需”，不用再跟反射配置较劲。迁移时如果遇到问题，比如旧配置和新配置冲突，或者不知道某个扩展点该怎么迁移，可以在评论区留言 —— 我会把我们整理的 “迁移问题排查清单” 分享给你，也欢迎大家交流自己的迁移经验，一起踩坑少走弯路！
来源：从程序员到架构师
