springboot自动配置加载顺序需通过debug日志中的conditionevaluationreport确认真实顺序，用@autoconfigurebefore/@autoconfigureafter或@order控制优先级，并通过exclude排除冲突配置且补全依赖契约。
SpringBoot自动配置加载顺序错乱时，自定义Bean无法覆盖官方配置、@ConditionalOnBean判断失败、多个Starter间Bean重复定义——这些问题都源于配置类加载时机失控，必须从根源上控制执行序列。
确认当前自动配置加载顺序
在application.properties中添加：logging.level.org.springframework.boot.autoconfigure=DEBUG，重启应用。
启动日志末尾会输出ConditionEvaluationReport，其中Auto-configuration report部分按实际加载顺序列出所有生效/跳过的自动配置类，这是唯一可信的顺序快照。
注意：该报告只反映本次启动的真实顺序，不等于类路径字母序，也不等于@Order值表面顺序。
强制指定自定义配置优先级
方法一：用@AutoConfigureBefore精确前置
在你的自定义配置类上添加注解：【@AutoConfigureBefore({DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class})】。
这会让Spring Boot确保你的配置类在指定官方配置类之前加载，从而让@ConditionalOnMissingBean有机会命中——如果官方配置先加载，它已创建Bean，你的条件就永远不满足。
方法二：用@Order数值控制（仅适用于@Configuration类）
在配置类上标注@Order(-1)，数值越小越早加载；官方自动配置默认为0，-1能稳定抢占先机。
⚠️注意：@Order对@Bean方法无效，只作用于整个@Configuration类。
切断冲突自动配置的加载链
第一步：定位冲突源头
查看启动异常堆栈，找到报错Bean名（如dataSource）→反向查出是哪个AutoConfiguration类在注册它→打开该类源码，确认其全限定名（如org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration）。
第二步：排除干扰项
在@SpringBootApplication注解中直接排除：【@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)】。
第三步：验证排除效果
重启后检查DEBUG日志，确认被排除的类不再出现在Auto-configuration report中，且你的自定义Bean已成功注册。
第四步：补全依赖契约
若排除了DataSourceAutoConfiguration，需手动引入spring-boot-starter-jdbc或对应驱动依赖，否则@ConditionalOnClass(DataSource.class)等条件会直接跳过你的配置。
修复跨Starter的隐式依赖顺序
当同时引入mybatis-spring-boot-starter和spring-boot-starter-data-redis时，RedisAutoConfiguration可能依赖DataSource，但又晚于DataSourceAutoConfiguration加载——此时必须显式声明依赖关系。
在你的Redis相关配置类上加：【@AutoConfigureAfter(DataSourceAutoConfiguration.class)】。
这个注解会强制Spring Boot将该配置类排在DataSourceAutoConfiguration之后解析，避免@ConditionalOnBean(DataSource.class)因时机不对而失效。
这一步不可省略：没有@AutoConfigureAfter，即使你写了@ConditionalOnBean，Spring也会在DataSource还没创建时就判定条件不成立，直接跳过整个配置类。
