springboot启动失败应先定位caused by根异常，再判断是否为autoconfiguration类触发，接着启用debug日志，检查依赖、配置属性及类路径条件，最后通过actuator/conditions端点验证。
SpringBoot项目启动失败时控制台满屏红色堆栈，但真正导致失败的那行异常往往藏在最底部的Caused by里，不往上翻三屏根本找不到根源。
第一步：定位根异常位置
启动应用后，立即滚动控制台日志到最上方，找到第一处以Caused by:开头的行——这行才是真正的失败起点，其他都是它引发的连锁反应。
如果看到类似APPLICATION FAILED TO START的横线分隔块，直接跳到该区块内最后一段Caused by，忽略上面所有Nested exception is嵌套提示。
这一步操作起来很简单，直接把文件拖进去就行。
第二步：判断是否为自动配置类触发失败
查看根异常的类名和包路径，重点识别是否含以下关键词：
• AutoConfiguration（如DataSourceAutoConfiguration）
• org.springframework.boot.autoconfigure开头的包名
• @ConditionalOn相关报错（如ConditionalOnClass、ConditionalOnProperty未满足）
如果异常堆栈中出现org.springframework.boot.autoconfigure且紧跟着Failed to configure a DataSource或Could not load class，基本可锁定是自动配置失效问题。
第三步：启用自动配置调试日志
方法一：启动时加JVM参数
-Dlogging.level.org.springframework.boot.autoconfigure=DEBUG
方法二：在application.yml中添加
logging:<br> level:<br> org.springframework.boot.autoconfigure: DEBUG
启动后会输出详细的自动配置报告，列出每个配置类是否生效、被跳过及原因。重点关注Exclusions（被手动排除的类）和Unconditional classes（无条件加载的类）两栏。
【注意】必须在启动前配置，运行中修改不生效。
第四步：检查自动配置前置条件是否满足
步骤一：确认对应依赖是否引入
例如报错Failed to configure a DataSource，检查pom.xml是否包含spring-boot-starter-jdbc或spring-boot-starter-data-jpa，缺一则自动配置类不会被加载。
步骤二：确认配置属性是否存在且拼写正确
比如@ConditionalOnProperty(name = "spring.redis.host")要求spring.redis.host必须存在，若只写了spring.redis.hostname，该配置就会静默跳过。
步骤三：确认类路径中是否存在条件依赖的类
如@ConditionalOnClass(DataSource.class)，需确保javax.sql.DataSource在classpath中——若用的是Jakarta EE 9+（jakarta.sql.DataSource），而项目仍引用旧版Spring Boot 2.x，则会因类不存在导致配置跳过。
【关键前提】Spring Boot 3.x要求JDK 17+且使用Jakarta EE命名空间，Spring Boot 2.x用的是Java EE命名空间，二者不可混用。
第五步：验证Actuator端点诊断信息
在pom.xml中添加Actuator依赖：
<dependency><br> <groupid>org.springframework.boot</groupid><br> <artifactid>spring-boot-starter-actuator</artifactid><br></dependency>
并在application.yml中暴露端点：
management:<br> endpoints:<br> web:<br> exposure:<br> include: health,conditions,beans
启动成功后访问http://localhost:8080/actuator/conditions，页面将清晰列出所有自动配置类的匹配状态与失败原因。
