spring boot自动配置基于@enableautoconfiguration触发，通过autoconfigurationimportselector读取meta-inf/spring/org.springframework.boot.autoconfigure.autoconfiguration.imports文件加载配置类，这些@configuration类借助@conditional系列注解按条件装配bean，于refresh()阶段由conditionevaluator实时评估并生效。
Spring Boot 的自动配置不是黑箱，而是基于一套清晰、可追溯的机制运行的。核心就三点：谁来触发、加载哪些配置类、按什么条件决定是否生效。
触发入口：@EnableAutoConfiguration 是关键开关
@SpringBootApplication 注解里藏着 @EnableAutoConfiguration，它才是真正开启自动配置的“总闸”。这个注解本身不干活，而是通过 @Import(AutoConfigurationImportSelector.class) 把控制权交给选择器。
- AutoConfigurationImportSelector 实现了 DeferredImportSelector，会在 Spring 容器刷新前被调用
- 它不硬编码配置类，而是去读取所有 jar 包中 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件（Spring Boot 2.7+ 主流方式）或兼容旧版的 META-INF/spring.factories
- 比如 spring-boot-autoconfigure.jar 里就列着 DataSourceAutoConfiguration、WebMvcAutoConfiguration 等上百个配置类
配置类本质：带条件的 JavaConfig
每个自动配置类都是一个普通的 @Configuration 类，但都加了 @Conditional 系列注解，相当于给 Bean 加了“上岗条件”。
- @ConditionalOnClass(DataSource.class)：只有项目里真有 DataSource 这个类（比如引入了 mysql-connector-java），这个配置才可能参与
- @ConditionalOnMissingBean(DataSource.class)：只有你没自己定义 DataSource Bean，它才出手创建默认的 HikariDataSource
- @ConditionalOnProperty(prefix = "spring.redis", name = "enabled", havingValue = "true")：配置文件里写了 spring.redis.enabled=true 才激活 Redis 相关 Bean
- 多个条件是“与”关系，全部满足才装配；一个不满足就跳过，完全静默
执行时机：在容器刷新阶段集中判断
SpringApplication.run() 走到 refresh() 这一步时，会把所有从 imports 文件里读出来的配置类，挨个解析其上的 @Conditional 注解。
- 框架内部会构造 ConditionEvaluator，对每个条件做实时评估（查 classpath、查 IOC 容器、读 Environment 属性等）
- 评估通过的配置类，才会真正执行其中的 @Bean 方法，把默认 Bean 注入容器
- 用户自定义的 @Configuration 类和 @Bean 方法，和自动配置类在同一阶段竞争，但优先级更高（比如你写了自己的 DataSource Bean，@ConditionalOnMissingBean 就让它失效）
调试与验证：别靠猜，用 --debug 看真相
启动时加上 --debug 参数，控制台会输出详细的匹配报告：
- Positive matches：列出所有生效的自动配置类（比如 DataSourceAutoConfiguration matched）
- Negative matches：列出被跳过的配置类及原因（比如 RedisAutoConfiguration did not match because @ConditionalOnClass did not find required class 'redis.clients.jedis.Jedis'）
- 这比翻源码快得多，是排查“为什么没配上”的第一手依据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
