SpringBoot自动配置加载失败时，需从类路径、配置属性、包扫描三方面排查：检查starter依赖是否缺失或被排除；启用DEBUG日志或/actuator/conditions端点定位条件不满足原因；确认@SpringBootApplication未exclude关键配置、@ComponentScan未误扫spring包、主类位于根包。
SpringBoot自动配置加载失败时，应用常报错如“Failed to configure a DataSource”或启动后缺少预期Bean，不是依赖没加就是条件没满足，排查必须从类路径、配置、扫描范围三处下手。
检查依赖是否缺失
自动配置类大多靠@ConditionalOnClass触发，如果关键类不在类路径，整个配置直接跳过——比如没加spring-boot-starter-data-jpa，JpaAutoConfiguration连加载都不会加载。
打开pom.xml，确认已声明对应starter：用JDBC就加spring-boot-starter-jdbc，用Redis就加spring-boot-starter-data-redis，不能只靠IDE自动补全依赖名，要核对Maven中央仓库实际坐标。
执行mvn dependency:tree -Dincludes=org.springframework.boot，搜索目标starter是否真实出现在依赖树顶层，避免被其他模块的exclusion意外剔除。
验证配置属性是否满足条件
方法一：启用DEBUG日志定位跳过原因
在application.properties中加入logging.level.org.springframework.boot.autoconfigure=DEBUG，重启后控制台会打印每条自动配置的匹配结果，例如“DataSourceAutoConfiguration did not match due to @ConditionalOnProperty missing”。
方法二：调用/actuator/conditions端点（需引入spring-boot-starter-actuator）
访问http://localhost:8080/actuator/conditions?name=DataSourceAutoConfiguration，返回JSON里会明确写出哪条@ConditionalOnProperty未生效，比如spring.datasource.url为空或spring.datasource.type未设置。
将 Spring Boot 2.7 项目升级到 Spring Boot 3.5 的实战流程，覆盖版本基线、依赖坐标替换、Jakarta 迁移、配置兼容、异步上下文传递改造与验证门禁。用于企业多模块 Maven 项目升级与排障。
【注意】某些配置项（如driver-class-name）虽非强制，但若url是mysql协议却缺驱动类，HikariCP初始化会失败，导致后续所有数据源相关自动配置链式失效。
排查包扫描与排除干扰
第一步：确认@SpringBootApplication未显式exclude关键配置
检查主类注解是否含exclude参数，例如@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)，这种写法会直接切断整个数据源配置链，即使配置全对也无Bean注册。
第二步：检查@ComponentScan是否误扫自动配置包
若手动写了@ComponentScan("com.example")，而该路径下恰好包含org.springframework.boot.autoconfigure子包（极少见但可能），会导致自动配置类被当作普通组件重复注册或冲突。应改用@SpringBootApplication(scanBasePackages = "com.example")，它默认不扫描spring包。
第三步：验证主启动类位置
主类必须位于根包（如com.example），不能放在com.example.util或com.example.config等子包下——否则@ComponentScan默认只扫其子包，而自定义配置类若在com.example.service，就会被漏掉。
