排查Spring Boot自动配置类误加载需启用--debug获取条件评估报告，查看matched/did not match详情；检查日志中Condition evaluation树形输出；验证是否被@Import强制导入、exclude配置错误或依赖冲突；特别注意@ConditionalOnMissingBean对Bean类型、名称、作用域的严格匹配。
排查Spring Boot自动配置类为何在条件不满足时仍被加载，关键在于定位真实生效的配置类及其条件评估过程，而不是只看类是否存在或是否被扫描到。
启动时启用自动配置报告
在应用启动命令末尾添加 --debug 参数，例如：java -jar myapp.jar --debug。
这会强制Spring Boot输出完整的自动配置报告，包含所有候选配置类的评估结果。
报告中每个配置类下方会明确标注 matched（条件满足）或 did not match（条件不满足），并列出具体失败原因，比如 @ConditionalOnClass did not find required class 'javax.sql.DataSource'。
查看日志中条件评估的原始输出
启动后搜索日志关键词 Condition evaluation，它通常出现在INFO级别日志中，位于Spring Boot Banner打印之后、上下文刷新之前。
这一段日志以树形结构展开，逐个列出每个自动配置类的条件判断路径，包括嵌套条件（如@ConditionalOnClass内嵌@ConditionalOnProperty）。
【注意】 如果日志里没看到任何 Condition evaluation 内容，说明你没加 --debug，或者日志级别被调高（如设为WARN），必须确保日志框架输出INFO及以上级别。
确认自动配置类是否真的被加载
方法一：检查日志中是否有 Registering bean definition for + 配置类全限定名，例如 Registering bean definition for 'org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration'。
方法二：在IDE中对目标配置类（如DataSourceAutoConfiguration）打断点，运行调试模式，观察其@Configuration类的静态块或@PostConstruct方法是否执行——未执行说明条件未通过，根本没进加载流程。
方法三：启动后访问 /actuator/configprops 或 /actuator/env（需引入spring-boot-starter-actuator并暴露端点），查看实际注册的Bean和配置属性，反向验证哪些自动配置生效了。
分析条件不满足却仍加载的典型场景
第一步：确认该配置类是否被其他配置类通过@Import显式导入——这种导入绕过所有@Conditional注解，直接强制加载。
第二步：检查是否使用了@EnableAutoConfiguration(exclude = ...)但排除的是错误的类名，导致本应排除的配置类反而被加载。
第三步：验证Maven依赖是否引入了多个版本的Starter（如同时存在spring-boot-starter-jdbc和mybatis-spring-boot-starter），它们各自的自动配置类可能互相触发条件，造成意外加载链。
【关键点】 @ConditionalOnMissingBean 类型的条件极易被误判：如果用户定义的Bean类型与自动配置期望的Bean类型不完全一致（如返回类型是接口但实现类不同），条件仍可能通过，导致自动配置加载——此时要核对Bean的类型、名称、作用域三者是否严格匹配。
