要快速定位springboot自动配置失效原因，必须启用debug日志或actuator的/actuator/conditions端点；在application.properties中添加logging.level.org.springframework.boot.autoconfigure=debug并重启应用，启动后查看conditions evaluation report中的positivematches和negativematches，或通过/actuator/conditions端点获取结构化条件结果，结合源码确认@conditionalonproperty等注解的实际配置前缀。
要快速定位SpringBoot自动配置为何没生效、哪个条件卡住了，必须打开条件评估日志——它会逐条告诉你每个AutoConfiguration类为什么被加载或跳过。
启用DEBUG级自动配置日志
在application.properties中添加一行：
logging.level.org.springframework.boot.autoconfigure=DEBUG
这行配置会让SpringBoot在启动时打印所有自动配置类的条件判断过程。不加这行，你永远看不到为什么RabbitMQ配置没加载、DataSource没创建。
【必须重启应用才能生效】 修改配置后不重启，日志不会刷新，旧日志里根本找不到ConditionEvaluationReport。
从启动日志里抓取ConditionEvaluationReport
启动完成后，滚动日志直到看到以“CONDITIONS EVALUATION REPORT”开头的大段输出。
它分两块：positiveMatches（满足条件、已加载的配置）和negativeMatches（不满足条件、被跳过的配置）。
比如看到这一行：
"RabbitAutoConfiguration": [ { "condition": "OnClassCondition", "message": "@ConditionalOnClass did not find required class 'com.rabbitmq.client.ConnectionFactory'" }
说明项目缺spring-boot-starter-amqp依赖——不是配置写错了，是jar包根本没引入。
用Actuator端点查实时条件状态
方法一：通过HTTP接口查看
① 添加actuator依赖：
② 在application.yml中暴露端点：
management:
endpoints:
web:
exposure:
include: conditions
③ 启动后访问 http://localhost:8080/actuator/conditions，返回结构化JSON，可直接搜索关键词如“Redis”“Jdbc”。
方法二：用IDEA的Spring Boot Actuator工具窗（如果装了Spring Boot插件）→ 点击“Conditions”标签页，比翻控制台日志快得多。
【注意】/actuator/conditions只反映当前运行态的条件结果，不包含启动阶段已被销毁的临时条件判断。
结合源码看条件注解含义
当你在negativeMatches里看到"OnPropertyCondition"失败，就去对应AutoConfiguration类上找@ConditionalOnProperty注解。
例如HttpEncodingAutoConfiguration要求server.servlet.encoding.enabled=true，但你的配置里写了spring.http.encoding.enabled=false——两个属性名不同，条件自然不匹配。
这时不能瞎猜，得打开该AutoConfiguration类源码，看它读的是哪个Properties类、绑定的是哪组配置前缀。
真正关键的是：所有xxxProperties类都定义了@ConfigurationProperties(prefix = "xxx")，这个prefix才是配置文件里要写的前缀。
