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:
  level:
    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依赖：

  org.springframework.boot
  spring-boot-starter-actuator

并在application.yml中暴露端点：

management:
  endpoints:
    web:
      exposure:
        include: health,conditions,beans

启动成功后访问http://localhost:8080/actuator/conditions，页面将清晰列出所有自动配置类的匹配状态与失败原因。