Spring Boot自动配置始于@SpringBootApplication中的@EnableAutoConfiguration，通过spring.factories或AutoConfiguration.imports加载配置类，并经@Conditional系列注解条件筛选后生效，支持覆盖优先与显式排除机制。
Spring Boot 的自动配置不是黑箱，而是一套基于“条件判断 + 配置加载 + 优先级控制”的可预测机制。它不替代 Spring，而是用约定和条件把 Spring 的能力组织得更智能、更省力。
自动配置从哪里开始？
一切始于启动类上的 @SpringBootApplication。它本质是三个注解的组合：@SpringBootConfiguration（标记为配置类）、@ComponentScan（扫描业务组件）、@EnableAutoConfiguration（真正开启自动配置）。其中，@EnableAutoConfiguration 是核心开关，它通过 @Import(AutoConfigurationImportSelector.class) 把自动配置逻辑导入进来。
配置类是怎么被找出来的？
Spring Boot 不靠硬编码去写死要加载哪些配置，而是依赖标准文件来声明：
- Spring Boot 2.7 之前：读取所有 jar 包下的 META-INF/spring.factories 文件，提取
org.springframework.boot.autoconfigure.EnableAutoConfiguration键对应的类全名列表； - Spring Boot 2.7 及以后：优先读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件，里面按行列出自动配置类的完整类名。
这些文件由 starter（如 spring-boot-starter-web）自带，相当于告诉框架：“我提供了哪些自动配置能力”。框架启动时统一收集、去重、排序，形成待评估的配置类清单。
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
哪些配置会真正生效？
不是所有列出来的配置类都会被加载——它们都裹着一层“条件外衣”，也就是 @Conditional 系列注解。常见判断逻辑包括：
-
@ConditionalOnClass(DataSource.class)：只有 classpath 里真有
DataSource类（比如引入了 HikariCP 或 Druid），这个数据源配置才可能启用； -
@ConditionalOnMissingBean(DataSource.class)：只有当前 Spring 容器里还没有用户自己定义的
DataSourceBean，才会注册自动配置的默认数据源； -
@ConditionalOnProperty(name = "spring.redis.enabled", havingValue = "true")：仅当配置文件中明确写了
spring.redis.enabled=true才激活 Redis 相关配置； - @ConditionalOnWebApplication(type = Type.SERVLET)：只在 Servlet Web 应用环境下生效，比如排除掉纯命令行应用。
每个自动配置类都可能包含多个这样的条件，全部满足才会被纳入装配流程。
用户配置和自动配置谁说了算？
自动配置的设计哲学是“让开发者拥有最终决定权”。关键机制有两点：
-
覆盖优先：如果你在自己的
@Configuration类里用@Bean声明了一个DataSource，那么即使DataSourceAutoConfiguration满足所有条件，也不会注入它的dataSource()方法，因为 @ConditionalOnMissingBean 已经失效； -
显式排除：可通过
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)或spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration直接跳过某类配置。
这种设计既保证开箱即用，又保留充分定制空间，不是“自动就完事”，而是“自动但可干预”。
