spring boot 3.x将自动配置拆分为spring-boot-autoconfigure-core与spring-boot-autoconfigure，废弃spring.factories改用imports文件，条件注解由javax.sql.datasource升级为jakarta.sql.datasource，并新增jakartaclasscondition过滤器。
要对比SpringBoot不同版本自动配置源码结构变化，必须从Spring Boot 2.x与3.x的底层项目组织逻辑入手——因为2.7.x和3.2.x的自动配置模块已不在同一套构建体系下，【spring-boot-autoconfigure模块在3.x中被重构为独立的spring-boot-autoconfigure-core + spring-boot-autoconfigure】，直接按路径比对旧包会漏掉关键拆分点。
定位自动配置核心模块位置
进入对应版本的GitHub release页面，比如v2.7.18和v3.2.0，分别打开spring-boot-project目录。
在Spring Boot 2.x中，自动配置全部集中在spring-boot-autoconfigure子模块内，其src/main/java/org/springframework/boot/autoconfigure/下是扁平化包结构，所有starter的AutoConfiguration类（如DataSourceAutoConfiguration）都直接放在该路径下。
Spring Boot 3.x则将自动配置能力拆成两层：spring-boot-autoconfigure-core提供条件注解、条件评估器等基础设施，而spring-boot-autoconfigure仅保留具体场景的配置类；【必须同时检出这两个模块才能还原完整自动配置链】。
对比META-INF/spring/下的注册机制
方法一：检查spring.factories（仅2.x存在）
Spring Boot 2.x通过META-INF/spring.factories文件声明自动配置类，格式为org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
方法二：检查org.springframework.boot.autoconfigure.AutoConfiguration.imports（3.x唯一入口）
Spring Boot 3.x废弃spring.factories，改用纯文本imports文件，每行一个全限定类名，无键值对、无换行符转义；【若项目中仍保留spring.factories，3.x启动时会静默忽略，不报错也不加载】。
这一步不能靠IDE搜索判断，必须解压target/classes/META-INF/spring/确认实际打包内容。
追踪自动配置类的条件装配逻辑演进
第一步：打开DataSourceAutoConfiguration类
第二步：观察@ConditionalOnClass注解参数变化
Spring Boot 2.x中常见写法是@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })，依赖javax.sql.DataSource；Spring Boot 3.x中对应类变为jakarta.sql.DataSource，且EmbeddedDatabaseType已被移入spring-boot-autoconfigure-core的内部枚举。
第三步：检查条件评估器实现类
2.x使用AutoConfigureAfter、AutoConfigureBefore控制顺序，3.x引入AutoConfigurationImportSelector的增强版，其getAutoConfigurationEntry方法返回AutoConfigurationEntry对象，其中包含经过Filter过滤后的候选列表——这个Filter链在3.x中新增了JakartaClassCondition，专门拦截javax.*类引用。
