Spring Boot 自动配置这玩意儿但凡是个做 Java 后端的肯定都跟它打过交道。以前排查启动慢、配置不生效的问题第一反应就是去翻META-INF/spring.factories文件看看对应的AutoConfiguration类有没有被列进去。但从 Spring Boot 2.7 开始这个文件里跟自动配置相关的部分逐渐退出历史舞台取而代之的是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。这个文件名太长了以至于很多人第一次看到的时候都怀疑自己是不是记错了路径。我在实际项目里踩过不少坑有把两个文件混着用的有在 2.7 版本里升级后发现自动配置直接失效的还有因为 IDEA 缓存问题导致新配置死活不生效的。这篇就系统梳理一下这两个文件的来龙去脉、加载原理、迁移步骤以及我在真实项目中排过的那些坑。1. 自动配置的加载逻辑从 spring.factories 到 imports 文件先说清楚一个底层事实Spring Boot 的自动配置并不是把所有Configuration类一股脑全加载而是通过EnableAutoConfiguration注解触发再靠AutoConfigurationImportSelector去扫描候选的配置类名单然后按条件装配。你写在spring.factories或者AutoConfiguration.imports里的内容就是这个“候选名单”。1.1 为什么 Spring Boot 2.7 要引入新文件很多老开发者对spring.factories感情很深毕竟用了六七年。但 Spring 团队在 2.7 版本引入新文件是有明确考量的第一spring.factories是 Spring Framework 框架层面的通用 SPI 机制负责加载的不只是自动配置还有ApplicationContextInitializer、ApplicationListener、EnvironmentPostProcessor、FailureAnalyzer等几十种类型。每个 key 对应的语义不同自动配置只是其中一个 key。但偏偏EnableAutoConfiguration这个 key 被用得太频繁导致spring.factories文件内容很臃肿还容易让后来者误以为所有东西都在这一个文件里写。第二自动配置类和普通 SPI 配置类的排序规则、条件装配时机完全不同。自动配置的类加载之前必须经过ConditionalOnMissingBean、ConditionalOnClass等条件判断还要参与AutoConfigureBefore、AutoConfigureAfter、AutoConfigureOrder等排序逻辑。把这些逻辑和通用 SPI 混在一个文件里对加载器和排查问题的开发者都是负担。第三AutoConfiguration.imports文件天然支持注释行允许空行键值对结构更清晰。不需要像spring.factories那样用“逗号分隔”写一大串全限定类名也不怕写错 key 被静默忽略。从 2.7 开始Spring Boot 官方建议把所有自动配置类名放进META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports每行一个全限定类名。等到了 Spring Boot 3.0spring.factories里的EnableAutoConfiguration配置条目直接被删除了也就是说新版本项目里如果还想着往旧文件里写自动配置那是真的不生效了。1.2 两个文件的本质区别SPI 机制与专用机制的碰撞要真正理解这个迁移得从机制上对比一下两种文件的定位。spring.factories是 Spring Framework 提供的一套基于SpringFactoriesLoader的通用 SPI 加载机制。框架启动时会加载 classpath 所有 jar 包里的META-INF/spring.factories文件把里面的配置按 key 分类缓存起来然后根据 key 拿到对应的实现类列表。这本质上是一个“路径 key 类名列表”的配置模式优点是通用性强缺点也是太通用——对自动配置这个特殊场景没有任何语义上的支持。AutoConfiguration.imports是 Spring Boot 专门为自动配置设计的专用加载机制文件名字本身就是固定全限定名。Spring Boot 在加载自动配置的时候会调用AutoConfigurationImportSelector#getCandidateConfigurations从这个 imports 文件里读候选类继承原来的排序和过滤逻辑整体加载流程更精准。可以类比一下spring.factories就像公司总前台所有人都从那里登记进入而AutoConfiguration.imports是独立的技术研发专用通道。人多的时候专用通道效率更高、职责更清晰排查问题也更快。2. 源码层面拆解启动时两个文件到底是怎么被加载的光知道“新文件替代旧文件”还不行关键是搞清楚 Spring Boot 到底是怎么找到这些配置类的。我从 Spring Boot 2.7 和 3.x 的源码里把核心链路梳理了一遍。2.1 SpringFactoriesLoader 与 spring.factories 的加载链路在 Spring Boot 2.7 及之前版本自动配置候选类的入口在AutoConfigurationImportSelector里。代码逻辑是这样的protected ListString getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) { ListString configurations SpringFactoriesLoader.loadFactoryNames( getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader()); Assert.notEmpty(configurations, No auto configuration classes found in META-INF/spring.factories. If you are using a custom packaging, make sure that file is correct.); return configurations; }getSpringFactoriesLoaderFactoryClass()返回的是EnableAutoConfiguration这个注解类。SpringFactoriesLoader.loadFactoryNames会去扫描 classpath 下所有 jar 包里的META-INF/spring.factories文件找到以org.springframework.boot.autoconfigure.EnableAutoConfiguration...为前缀的那段内容然后把等号后面逗号分隔的类名全部解析出来。这里有个容易忽略的细节SpringFactoriesLoader加载的是所有jar 包里的 factories 文件包括你项目依赖的三方库。如果你的项目里引了做数据源、消息队列、对象存储的 starter它们各自 jar 包里也会带着自己的spring.factories文件。所以最终的自动配置候选列表是海量的Spring Boot 再拿着这个列表逐一判条件。2.2 AutoConfigurationImportSelector 如何读取 imports 文件从 2.7 开始getCandidateConfigurations的逻辑改了变成了双源加载protected ListString getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) { ListString configurations new ArrayList( SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader())); ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()).forEach(configurations::add); Assert.notEmpty(configurations, No auto configuration classes found in META-INF/spring.factories nor in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you are using a custom packaging, make sure that file is correct.); return configurations; }注意代码里的变化先仍然从spring.factories里加载旧的配置项保证向前兼容再通过ImportCandidates.load(AutoConfiguration.class, ...)读取AutoConfiguration.imports里的内容把两边的类名合并到同一个列表里。ImportCandidates是 Spring Boot 2.7 新增的内部工具类。它的load方法接收两个参数第一个是注解类AutoConfiguration.class第二个是类加载器。方法内部拼出固定的资源路径META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports然后遍历 classpath 上所有的 jar 包找到所有叫这个名字的文件一行一行读取类名。这个文件格式简单直接允许#注释允许空行每行一个全限定类名。相比逗号分隔的方式阅读体验和 git diff 的可读性都好了不少。等到 Spring Boot 3.0源码就彻底精简了protected ListString getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) { ListString configurations ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()) .getCandidates(); Assert.notEmpty(configurations, No auto configuration classes found in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you are using a custom packaging, make sure that file is correct.); return configurations; }旧路径的兼容逻辑移除了读取 imports 文件成了唯一来源。这也意味着如果你在 Spring Boot 3 项目里继续用spring.factories注册自动配置Spring Boot 是完全感知不到的。2.3 加载顺序、去重逻辑与条件装配的联动候选类名单读出来之后Spring Boot 并不会直接创建对象而是走AutoConfigurationImportSelector内部的完整处理链去重 - 排序 - 过滤。去重逻辑用的是LinkedHashSet保证同一个自动配置类不会在最终列表里出现多次同时保持声明顺序。排序逻辑靠的是AutoConfigurationSorter。它会收集每个自动配置类上的AutoConfigureBefore、AutoConfigureAfter、AutoConfigureOrder注解做一次拓扑排序。比如数据源自动配置要优先于 MyBatis 自动配置这类依赖关系就是靠注解维护的。在新老文件切换的过渡期这部分的排序规则没有任何变化所以只要类名被正确读取到顺序行为就一致。过滤逻辑通过AutoConfigurationImportFilter提前过滤掉不满足条件的候选类比如ConditionalOnClass里指定的类不在 classpath那么这个候选类直接就划掉了不会进入后续的 bean 定义阶段。这里有个隐含的机制值得注意候选类即使被过滤掉也不会抛异常缺失的依赖只会导致自动配置的 bean 不创建。这既是 Spring Boot 自动配置“按需装配”的精髓也是很多人排查时容易忽略的点——配置类没生效不一定是注册问题可能是条件没满足。3. 迁移实操从旧文件到新文件的完整落地步骤如果你维护的是基础组件包或者公共 starter到 Spring Boot 3.x 时代还在用spring.factories注册自动配置那你的组件在别人的新项目里会直接静默失效。下面是我在一套内部基础组件包里做迁移的完整过程可以直接照着做。3.1 迁移前置检查确认当前项目是否受影响先看清楚自己项目处于哪个阶段如果你的项目是 Spring Boot 2.7 到 2.7.x自动配置同时支持两个文件spring.factories里的还能生效但启动日志会打出一段 deprecation 警告提示你迁移到新写法。如果你的项目是 Spring Boot 3.0 及以上spring.factories里跟自动配置有关的内容已经完全不生效了。如果你的项目是 Spring Boot 2.6 及以下暂时不需要迁移但建议规划升级路线。检查当前项目里有没有旧配置find . -path */META-INF/spring.factories -o -path */META-INF/spring/*.imports在项目根目录跑一下这条命令就能看到所有相关文件。重点看spring.factories里有没有org.springframework.boot.autoconfigure.EnableAutoConfiguration这个 key只有这个 key 才对应自动配置迁移其他 key比如ApplicationListener、EnvironmentPostProcessor保留在原文件即可完全不用动。3.2 手动迁移新建 imports 文件并迁移配置类操作步骤如下在src/main/resources/META-INF/spring/目录下新建文件org.springframework.boot.autoconfigure.AutoConfiguration.imports。打开src/main/resources/META-INF/spring.factories找到org.springframework.boot.autoconfigure.EnableAutoConfiguration这一行把等号后面的类名全部复制出来。按逗号切分得到类名列表清掉多余空格。把这些类名逐个写入 imports 文件每行一个不需要逗号。删除spring.factories里的EnableAutoConfiguration配置项其他 key 保持不变。一个典型的AutoConfiguration.imports文件长这样com.example.starter.RedisAutoConfiguration com.example.starter.MQAutoConfiguration com.example.starter.MetricsAutoConfiguration # 短信自动配置 # com.example.starter.SmsAutoConfiguration每个全限定类名单独一行注释以#开头空行不会影响加载。这种格式有一个很实用的好处代码 review 的时候git diff 非常清晰哪一行新增哪个类一目了然。不像旧格式改一个类名可能需要动一整行。3.3 迁移后验证如何确认新配置已生效迁移完最怕的就是“看似没问题实际没加载”。我的验证路径分为三步第一步检查启动日志。Spring Boot 启动时在DEBUG级别下会打印自动配置报告。启动参数加一行--debug或者直接在application.properties里配置debugtrue启动后控制台会输出类似这样的报告 CONDITIONS EVALUATION REPORT Positive matches: ----------------- RedisAutoConfiguration matched: - ConditionalOnClass found required classes org.springframework.data.redis.core.RedisOperations Negative matches: ----------------- SmsAutoConfiguration did not match: - ConditionalOnClass did not find required class com.example.sms.SmsClient确认你迁移的自动配置类出现在 Positive matches 里基本就能确定加载链路通了。第二步通过BeansEndpoint或 Actuator 接口检查 bean 是否创建。如果项目里开了spring-boot-starter-actuator可以调用curl http://localhost:8080/actuator/beans | grep -i redisAutoConfiguration第三步写一个最小化的单元测试做断言。在测试目录下建一个测试类SpringBootTest(classes TestApplication.class) class AutoConfigurationMigrationTest { Autowired(required false) private ApplicationContext context; Test void redisAutoConfigurationShouldBeLoaded() { String[] beanNames context.getBeanNamesForType(RedisTemplate.class); assertThat(beanNames).isNotEmpty(); } }如果这个测试通过说明自动配置成功生效迁移完成。3.4 一键迁移利用 Spring Boot 官方上报工具手动改文件最怕漏类目。Spring Boot 从 2.7 开始提供了诊断辅助升级后启动项目如果检测到spring.factories里还有旧的自动配置条目会在启动日志输出一段提示建议你启动时加一个系统参数让框架自动打印迁移清单。-Dspring.factories.autoConfiguration.imports.enabledtrue或者通过环境变量SPRING_FACTORIES_AUTOCONFIGURATION_IMPORTS_ENABLEDtrue开启后日志里会明确列出哪些类需要搬到新文件里哪些类因为条件不满足本来就没被加载。这个工具本质上是把旧的EnableAutoConfiguration条目重新读取一遍然后打印出来方便你对照迁移。它不是自动改写文件但能帮你不漏类地完成迁移。4. 双文件共存期的坑spring.factories 和 imports 同时存在怎么办如果你的项目恰好停留在 Spring Boot 2.7 到 2.7.18 之间或者你依赖的三方 starter 还没来得及升级那你会遇到“双文件共存”的情况。这个阶段不是二选一而是“两边的自动配置类会合并后一起加载”。4.1 双文件共存时的加载合并规则在 2.7 版本里getCandidateConfigurations的逻辑是先加载spring.factories里的旧配置再加载AutoConfiguration.imports里的新配置最后拼接成一个 ArrayList。这个顺序意味着什么来看实际场景假设你的项目里引了一个老版本 starter它把DataSourceAutoConfig写在自己的spring.factories里你自己项目里又通过新 imports 文件注册了同一个类。因为最终加载用的是LinkedHashSet去重重复类只会保留一次。但“保留哪一次”取决于排序逻辑如果两个自动配置类之间存在AutoConfigureBefore/AutoConfigureAfter的排序关系声明在哪个文件里并不影响排序排序只认类上的注解。比较隐蔽的问题是这样如果在老 starter 的spring.factories里把本应该作为内部辅助配置的类比如DataSourcePoolMetadataProviderConfiguration也注册成了自动配置而你自己在新 imports 文件里又注册了同名的配置类就会出现 bean 定义冲突或者条件装配顺序不符合预期的诡异问题。我的建议很简单在 2.7 版本里同一套组件库里的自动配置类要么全部走旧文件要么全部走新文件不要一半一半。混用导致的问题排查起来往往比单纯迁移更耗时。4.2 过渡版本中“同时失效”的隐藏原因还有一个容易被忽略的情况你在 2.7 项目里同时写了两个文件旧文件里的类没问题新文件里的类也没问题但启动后发现新文件里的自动配置没有加载。排查了半天发现路径写错了。AutoConfiguration.imports这个文件名不是随便起的是org.springframework.boot.autoconfigure.AutoConfiguration.imports。很多同事在META-INF/spring/目录下建文件时习惯性地敲成org.springframework.boot.autoconfigure.EnableAutoConfiguration.imports或者简写成AutoConfiguration.imports这都不会被加载。框架对文件名要求精确匹配包含包名全限定名一个字符都不能差。head 一下正确路径META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports这个文件名里的目录前缀META-INF/spring/也是固定的放到META-INF/根目录下同样不生效。4.3 IDEA 缓存与构建残留问题Java 开发绕不开 IDEA。实际处理过的案例里有两次是代码完全没问题但新写的 imports 文件就是不生效。最后发现原因如出一辙IDEA 的缓存没有刷新或者构建工具没把新增的 resources 文件打进 classpath。排查手段如下第一步IDEA 菜单File - Invalidate Caches / Restart清掉缓存重启项目。第二步如果还不行手动执行一次干净构建./gradlew clean build或 Maven 项目mvn clean package然后确认构建产物里真的包含新文件jar tf target/my-starter.jar | grep AutoConfiguration.imports如果 jar 包里没有那就是资源配置有问题检查pom.xml或build.gradle的 resources 配置是否把META-INF/spring目录排除掉了。第三步如果项目是模块化结构多模块 Maven / Gradle还要确认子模块的 resources 是否被正确合并进最终可执行 jar。Spring Boot 的可执行胖 jar 里会自动保留所有依赖 jar 里的AutoConfiguration.imports但如果你用了自定义的spring-boot-maven-plugin配置需要检查是否有excludes把META-INF/spring/**过滤掉了。5. 常见问题与排查技巧实录这个部分集中记录我在处理自动配置问题时积累的经验。很多问题初次遇到都以为是自己写错了类名实际上根因五花八门。整理成速查表形式方便你排查时对号入座。5.1 自动配置类明明写了为什么不生效症状可能原因排查方法Spring Boot 3 项目里自动配置没加载还在用spring.factories注册改用AutoConfiguration.imports确认文件名完全正确Spring Boot 2.7 项目里新文件配置没加载文件名拼错或路径错检查META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importsjar 包里有文件但运行时未生效构建工具把 resources 资源排除了jar tf查看实际产物内容配置类在 Positive matches 里但 bean 不存在类上的条件注解不满足看日志里 Negative matches 的原因补依赖或调整条件自动配置顺序错了缺少AutoConfigureBefore/AutoConfigureAfter在自动配置类上补充排序注解依赖的 starter 老版本没迁移老 jar 包里只有spring.factories配置升级 starter 版本或判断是否需要覆盖写进了 imports 文件但类名没加AutoConfiguration类缺少自动配置注解确认类上标注的是AutoConfiguration而非普通Configuration5.2 自动配置是普通Configuration还是AutoConfiguration这是从 2.7 开始变得重要的问题。过去的写法是Configuration ConditionalOnClass(SomeService.class) EnableConfigurationProperties(SomeProperties.class) public class SomeAutoConfiguration { }从 2.7 开始Spring Boot 引入了AutoConfiguration注解它本身组合了Configuration(proxyBeanMethods false)强制关掉了 CGLIB 代理并且还支持after、before属性直接声明排序关系替代一部分AutoConfigureAfter的用法AutoConfiguration(after DataSourceAutoConfiguration.class) ConditionalOnClass(SomeService.class) EnableConfigurationProperties(SomeProperties.class) public class SomeAutoConfiguration { }这里有一个实际执行层面的差别AutoConfiguration注解的解析在自动配置阶段更顺滑排序信息从注解属性里就能直接读取不需要额外反射扫描AutoConfigureAfter。虽然是同一个加载器但使用新注解会减少一次元数据解析。建议所有新写的自动配置类都换成AutoConfiguration。5.3spring.factories里其他配置项要不要迁移不用迁移。AutoConfiguration.imports只针对自动配置这一件事。spring.factories里还有大量其他 key 需要继续使用比如org.springframework.context.ApplicationContextInitializerorg.springframework.context.ApplicationListenerorg.springframework.boot.env.EnvironmentPostProcessororg.springframework.boot.diagnostics.FailureAnalyzer这些 key 直到 Spring Boot 3.x 也仍然走spring.factories加载完全不冲突。很多人升级 3.x 的时候一看到spring.factories还在就慌了其实没必要。你只需要确认EnableAutoConfiguration这个 key 下的内容已经全部搬走即可。5.4 组件发布后下游项目仍然不认新配置自己项目里迁移完还不行还得考虑“组件作为依赖供别人使用”的场景。如果组件里同时保留了旧文件和新文件但下游项目是 Spring Boot 3.x旧文件内容自动被忽略新文件内容正常加载这没问题。但有一种情况很隐蔽组件里AutoConfiguration.imports文件名写错了或者类名引用了不存在的类启动时反而可能触发类加载异常。发布组件的自检清单我给你列一下执行mvn package或gradle build。解压 jar 包或jar tf确认 imports 文件路径完全匹配。在本地建一个最小化的 Spring Boot 3 项目引入这个组件验证自动配置能正常装配。确认 pom 里没有意外将这个 imports 文件标注为testscope 或被打包插件过滤。如果组件还保留了Autoconfigure模块检查该模块的spring.factories和 imports 文件之间是否出现重复注册。5.5 一个来自生产环境的真实排查记录有一次线上服务升级 Spring Boot 版本后Redis 连接池参数全部失效但服务能正常启动。网上查了一圈发现很多人遇到的是配置前缀不对但这次明显不是。后来我专门拉日志看自动配置报告发现RedisAutoConfiguration在 Negative matches 里原因是ConditionalOnClass没找到LettuceConnection类——因为我们当时用的是 Jedis而项目里把 commons-pool2 的依赖在某些 profile 下漏掉了。这不是文件迁移导致的但排查思路被这次经历彻底打开了自动配置不生效先看条件报告别急着怀疑文件写错。日志就是最好用的排查工具java -jar app.jar --debug然后搜CONDITIONS EVALUATION REPORT。里面会清清楚楚把每个自动配置类的匹配状态和原因列出来。这个报告是我在自动配置问题上的第一排查入口。6. 给你的一套最小化自动配置 starter 模板把前面所有内容沉淀成一套可以直接抄的模板。这个模板基于 Spring Boot 3.2依赖 Maven 构建。6.1 目录结构my-starter/ ├── pom.xml └── src/main/ ├── java/com/example/starter/ │ ├── MyService.java │ ├── MyProperties.java │ └── MyAutoConfiguration.java └── resources/META-INF/ └── spring/ └── org.springframework.boot.autoconfigure.AutoConfiguration.imports注意resources/META-INF/spring/下面放的是文件名为org.springframework.boot.autoconfigure.AutoConfiguration.imports的文件不是以.imports为后缀的一堆文件。文件名里包含了完整包名很多第一次接触的人会在这里困惑。6.2 核心类代码先写业务类public class MyService { private final MyProperties properties; public MyService(MyProperties properties) { this.properties properties; } public String hello() { return Hello, properties.getName(); } }配置属性类ConfigurationProperties(prefix my.starter) public class MyProperties { /** * 服务名称默认值 my-app。 */ private String name my-app; public String getName() { return name; } public void setName(String name) { this.name name; } }自动配置类AutoConfiguration EnableConfigurationProperties(MyProperties.class) ConditionalOnClass(MyService.class) ConditionalOnProperty(prefix my.starter, name enabled, havingValue true, matchIfMissing true) public class MyAutoConfiguration { Bean ConditionalOnMissingBean public MyService myService(MyProperties properties) { return new MyService(properties); } }6.3 imports 文件内容com.example.starter.MyAutoConfiguration这一行就足够。Spring Boot 加载这个文件后会读取MyAutoConfiguration类上的注解通过EnableConfigurationProperties注册配置属性类通过ConditionalOnClass判断依赖通过ConditionalOnMissingBean保证用户自定义的MyService不被覆盖。6.4 pom 构建配置要点starter 模块的 pom 不需要引用spring-boot-maven-plugin因为它不是可执行应用被打成普通 jar 即可。但建议加上spring-boot-configuration-processor作为 optional 依赖这样下游项目能获得配置属性提示dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-configuration-processor/artifactId optionaltrue/optional /dependency还要保证resources目录下的文件默认被打进 jar 包build resources resource directorysrc/main/resources/directory filteringfalse/filtering /resource /resources /build如果项目里开了 Maven 的resource filtering记得把META-INF/spring/*.imports排除掉否则过滤时可能污染文件内容。6.5 验证模板是否正常工作在测试项目里引入这个 starter 后启动应用在application.properties里配置my.starter.nametest-name写一个 TestSpringBootTest class MyStarterTest { Autowired private MyService myService; Test void helloShouldReturnConfiguredName() { assertThat(myService.hello()).isEqualTo(Hello, test-name); } }跑通这个测试说明整个自动配置链路是通的。以后在这个模板基础上加功能就很简单了。7. 我的一些体会和建议说了这么多最后聊点个人胃口的经验。自动配置这套机制本质上解决的是“让框架替你做判断”的问题。很多人觉得它黑盒、不好排查其实只要抓住“候选类是怎么被发现、条件是怎么被判断、排序是怎么被决定”这三个核心问题整个框架在你眼里就是透明的。对于维护公共 starter 或者基础组件的开发者我认为有三件事值得刻意去做第一有条件的话在 CI 流水线里加一个“最小下游项目”的集成测试专门验证自动配置在最新版 Spring Boot 下能正确加载。这个成本不高但能在组件发布之前就把兼容性问题拦下来。第二多读 Spring Boot 的源码和自动配置报告比看一百篇二手资料都有用。第三升级依赖之前先在本地把版本号改了跑一遍那个--debug启动日志基本能暴露 90% 的自动配置问题。还有一个小技巧是线上环境建议写一个自定义的ApplicationRunner启动完成后主动输出当前自动配置报告里的 Positive matches 数量如果有波动就告警。主动量化“自动配置是否正常”比出了问题再翻日志要舒服得多。