SpringBoot自动配置失败需先区分ClassNotFoundException（类未加载）与BeanCreationException（配置失效），再通过jar包检查、debug日志分析条件匹配结果，最后按缺依赖、条件冲突或误排除三类原因针对性修复。
SpringBoot自动配置失败时控制台报“找不到类”，不是类路径缺失就是条件注解未满足，必须立刻区分是ClassNotFoundException还是BeanDefinitionRegistryException——前者说明类压根没加载进JVM，后者才真正属于自动配置失效范畴。
第一步：确认错误类型是真·类找不到还是假·类找不到
打开启动日志，定位最末尾的异常栈顶行。如果看到java.lang.ClassNotFoundException或NoClassDefFoundError，说明该类确实不在classpath中；如果看到UnsatisfiedDependencyException、NoSuchBeanDefinitionException或Caused by: org.springframework.beans.factory.BeanCreationException，那实际是自动配置类被跳过，但依赖它的Bean初始化失败了。
注意：【ClassNotFoundException和BeanCreationException的修复路径完全不同，混为一谈会浪费30分钟以上】
第二步：查类是否真的在jar包里
根据上一步判断出的类名（例如com.alibaba.druid.pool.DruidDataSource），执行以下操作：
进入项目target目录 → 找到生成的jar包 → 用jar -tf xxx.jar | grep DruidDataSource，看输出里是否有该类全限定名。
没有？说明依赖根本没打进包里。有？说明类存在，问题出在自动配置的触发逻辑上。
若使用Maven，检查pom.xml中对应starter是否用了
第三步：验证自动配置类是否进入候选列表
在application.properties中添加：
debug=true
重启应用，搜索日志中AUTO-CONFIGURATION REPORT开头的区块。找到你关心的自动配置类（如DruidDataSourceAutoConfiguration），观察其状态是matched（匹配成功）还是excluded（被排除）或did not match（条件不满足）。
如果状态是did not match，展开下面的Conditions Evaluations部分，逐条查看@ConditionalOnClass、@ConditionalOnMissingBean等注解的评估结果。其中标为false的那一条，就是真正的拦路虎。
第四步：针对性补漏
方法一：缺类就加依赖
比如日志显示@ConditionalOnClass要求的com.zaxxer.hikari.HikariDataSource不存在，而你又想用HikariCP，那就必须引入spring-boot-starter-jdbc或直接加hikari-cp依赖。
方法二：条件冲突就删Bean
如果日志提示@ConditionalOnMissingBean不满足，说明你自己在@Configuration类里手动new了一个同类型Bean。要么删掉这个Bean定义，要么给它加上@Primary，或者改用@Bean(name = "xxx")显式命名避开冲突。
方法三：排除项误杀就检查exclude参数
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)这种写法会直接砍掉整个数据源自动配置链。确认exclude列表里没有误删你实际需要的配置类。
