Spring Boot 自动配置原理基本理解

本文将从依赖引入、运行时筛选、Bean 创建到配置绑定，全链路拆解 Spring Boot 自动配置的底层逻辑，帮你彻底搞懂 "约定大于配置" 的精髓。

一、先破误区：引入 Web 启动器≠只引入 Web 相关配置

很多开发者刚接触 Spring Boot 时都会有一个疑问：为什么我只引入了spring-boot-starter-web，项目里却出现了一堆看似和 Web 无关的自动配置类？

其实这是一个典型的认知误区，我们先看依赖树：

复制代码

org.springframework.boot:spring-boot-starter-web:2.7.6
└── org.springframework.boot:spring-boot-starter:2.7.6 (omitted for duplicate)
    └── org.springframework.boot:spring-boot-autoconfigure:2.7.6

从依赖传递关系可以清晰看到：

引入spring-boot-starter-web时，会自动传递依赖spring-boot-starter
spring-boot-starter又会引入核心自动配置包spring-boot-autoconfigure

这个spring-boot-autoconfigure包里包含了 Spring Boot 官方提供的152 个自动配置类，覆盖了 Web、缓存、数据库、消息队列等几乎所有场景。

⚠️ 关键认知：此时只是把包含 152 个候选自动配置类的 Jar 包 "放进" 了项目，类文件并未被加载和执行，它们只是作为 "候选配置池" 存在，程序还未真正运行。

二、运行时筛选：EnableAutoConfiguration 如何 "按需加载"

当我们点击运行，启动类的main方法执行SpringApplication.run()时，自动配置才真正开始工作。核心是@EnableAutoConfiguration注解（通过@SpringBootApplication间接引入），它的工作流程分为四步：

1. 读取候选列表

@EnableAutoConfiguration内部的AutoConfigurationImportSelector会读取spring-boot-autoconfigure.jar中META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，拿到 152 个候选自动配置类的全类名，例如：

org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration

2. 第一轮筛选：去重与排除

排除开发者通过@SpringBootApplication(exclude = ...)手动排除的自动配置类
去除重复的自动配置类，确保每个类只处理一次

3. 第二轮筛选：条件注解校验（核心）

这是自动配置 "按需加载" 的关键，Spring Boot 会对剩余候选类逐个校验类上的条件注解：

@ConditionalOnClass：检查类路径是否存在指定依赖（例如存在spring-webmvc才加载WebMvcAutoConfiguration）
@ConditionalOnWebApplication：仅在 Web 应用环境下才加载 Web 相关配置
@ConditionalOnMissingBean：仅当容器中没有自定义 Bean 时，才加载自动配置的默认 Bean
@ConditionalOnProperty：根据配置文件中的属性值决定是否加载

只有全部条件满足的自动配置类，才会进入 "待加载列表"。例如在纯 Web 项目中：

DispatcherServletAutoConfiguration、WebMvcAutoConfiguration等 Web 相关配置会被保留
RedisAutoConfiguration、JdbcTemplateAutoConfiguration等因缺少对应依赖，会被直接排除

4. 标记待加载

筛选完成后，Spring 会将 "待加载列表" 中的自动配置类标记为 "需要导入到容器"，为后续加载做准备。

三、加载到容器后：自动配置类到底做了什么？

当满足条件的自动配置类被加载到 IoC 容器后，并非直接结束，而是会执行一系列核心操作，最终实现 "零配置" 的功能落地：

1. 执行 @Bean 方法，创建核心功能 Bean

自动配置类的本质是一个 Java 配置类，内部通过@Bean方法定义了框架所需的核心组件，这是自动配置的核心价值所在：

DispatcherServletAutoConfiguration会执行dispatcherServlet()方法，创建前端控制器DispatcherServlet Bean
WebMvcAutoConfiguration会执行viewResolver()方法，创建视图解析器InternalResourceViewResolver Bean
ServerAutoConfiguration会执行tomcatWebServerFactory()方法，创建 Tomcat 服务器工厂 Bean

这些@Bean方法执行时，会自动从容器中获取依赖，为 Bean 注入必要的属性（如端口、上下文路径）。

2. 绑定自定义配置，动态调整 Bean 属性

自动配置类会通过@EnableConfigurationProperties关联对应的xxxProperties类（如ServerProperties、WebMvcProperties），完成配置绑定：

从application.yml或application.properties中读取你自定义的配置（如server.port=8081、spring.mvc.view.prefix=/WEB-INF/）
将这些配置值绑定到xxxProperties Bean 的属性上
自动配置类在创建功能 Bean 时，会读取这些属性值，动态调整 Bean 的行为（例如将 Tomcat 端口从默认 8080 改为 8081）

3. 依赖注入，完成组件关联

容器中已经有了自动配置类创建的框架 Bean（如DispatcherServlet、ViewResolver），也有你自己编写的业务 Bean（如@Controller、@Service）：

Spring 会按照依赖注入规则（@Autowired、@Resource等），将框架 Bean 注入到你的业务 Bean 中
同时，框架内部也会完成 Bean 之间的依赖注入（例如DispatcherServlet会注入HandlerMapping Bean）

四、Web 场景实战：从自动配置到请求处理

我们以 Web 场景为例，完整走一遍自动配置的落地流程：

加载WebMvcAutoConfiguration到容器
- 解析@EnableConfigurationProperties(WebMvcProperties.class)，绑定spring.mvc相关配置
- 执行requestMappingHandlerAdapter()方法，创建处理@RequestMapping注解的核心组件
- 执行viewResolver()方法，创建视图解析器
注入到DispatcherServlet
- 自动配置创建的HandlerMapping、ViewResolver等 Bean 被注入到DispatcherServlet中
Tomcat 启动，处理请求
- Tomcat 启动后，DispatcherServlet接管所有 HTTP 请求
- 通过注入的组件，完成请求映射、视图渲染等核心逻辑

五、总结：Spring Boot 自动配置的精髓

Spring Boot 的自动配置，本质上是一套 "候选引入 → 按需筛选 → 自动创建 → 配置绑定" 的闭环逻辑：

候选引入：通过启动器依赖传递，引入包含所有场景自动配置类的 Jar 包
按需筛选：运行时通过条件注解，筛选出与当前项目环境匹配的自动配置类
自动创建 ：执行自动配置类中的@Bean方法，创建框架所需的核心组件
配置绑定 ：将application.yml中的自定义配置绑定到属性类，动态调整组件行为

最终，开发者只需要导入启动器、修改配置文件，就能完成对应功能的开发，真正实现了 "约定大于配置" 的设计理念。

💡 一句话总结：Spring Boot 自动配置，就是让框架替你完成了原本需要手动编写的 XML 配置和 Bean 创建，让你专注于业务开发。