一篇文章搞懂SpringBoot自动装配流程（超详细易懂源码流程）

前言

SpringBoot的自动装配流程？SpringBoot是如何具体实现开箱即用、按需加载和可插可替的？我们自己导入依赖会发生什么？

这些就是这篇文章的重点，希望对你有帮助

提醒：建议大家阅读类似这种源码流程时，不能把完全记住或死记硬背流程视为重点。 真正有价值的是通过这些流程，让我们弄清楚：我们日常使用的注解、配置、模块究竟在哪一步起作用、与哪些组件协作、发生了哪些链式调用。 理清这些“串联关系”，能帮助我们：明确定位、快速排查问题以及启发性能和流程优化思路。

一、简单说说SpringBoot框架

Spring Boot 是基于 Spring Framework 的快速开发框架，目的是简化 Spring 应用的开发和部署，核心作用之一就是极简配置和自动装配。
提示：本文SpringBoot是2.x版本，3.x版本整体思想一致，细节部分会有少许变化

二、具体自动装配流程（源码级别）

提示：我总结出了两次筛选和两次自定义优先，下面会有详细解释。

    开发者添加依赖（以Maven为例）
　　　　　　 ↓
添加 Spring Boot Starter（如 spring-boot-starter-web）
【启动器Starter 只是一个传递依赖的聚合包】
　　　　　　 ↓
Starter 依赖引入了核心功能模块（如 spring-web、spring-boot-autoconfigure、tomcat 等）
　　　　　　 ↓
@SpringBootApplication（入口类）【程序启动入口】
　　　　　　 ↓
@EnableAutoConfiguration【启动自动配置功能】
　　　　　　 ↓
@Import(AutoConfigurationImportSelector.class)
　　　　　　 ↓
AutoConfigurationImportSelector → 加载 META-INF/spring.factories 文件
【把所有 @EnableAutoConfiguration 声明的自动配置类类名加载到内存】
　　　　　　 ↓
统一加载一整套自动配置类（如 xxxAutoConfiguration）
【这步主要是从 spring.factories 中读取内存中的配置类类名，存储到候选列表中】
　　　　　　 ↓
根据当前项目类路径 + Maven依赖情况 + 配置属性，按需筛选需要启用的自动配置类【全局筛选】

                       ↓【按需启用这些配置类】

逐个准备执行每个自动配置类

                       ↓ 【判断配置是否启用】

每个自动配置类先判断是否适合当前环境：

├─ 如果开发者已自定义了对应的核心配置（如已有相应的Bean）
 | → 终止当前自动配置，自动配置类失效
 | → 后续该自动配置类内部的默认组件不再注册【全局自定义优先】
├─ 如果不存在开发者自定义，且环境条件全部满足
 | → 继续执行自动配置流程
　　　　　　 ↓
进入每个配置类内部，判断具体配置是否启用：
　　　　　　 ↓
每个配置类内部：
　　　　　　 ↓【局部筛选】
@ConditionalOnClass → 类路径存在某个类？（选择服务器类型会在这里进行）
　　　　　　 ↓
@ConditionalOnProperty → 配置文件中某个属性开启？
　　　　　　 ↓
@ConditionalOnMissingBean → 容器中是否已有开发者自定义 Bean？
　　　　　　 ↓
执行 @Bean 方法注册组件到 IoC 容器

├─ 没有自定义 → 注册默认 Bean
├─ 有开发者自定义 → 跳过默认，保留开发者 Bean【局部自定义优先】
　　　　　　 ↓
全部条件满足，说明需要启用这个配置
　　　　　　 ↓
真正注册 @Bean 方法，完成自动配置
【真正把自动配置生成的 Bean 注册到 IoC 容器】
├─ 如果没有 → 注册自动配置的默认 Bean
├─如果已有 → 跳过自动配置，优先保留开发者自定义
　　　　　　 ↓

      完成整个自动装配过程

相关名词解释

1. 全局筛选：这是模块级别的筛选，Spring Boot 会通过 AutoConfigurationImportSelector，根据当前类路径、依赖情况与配置属性，从 spring.factories 中加载所有候选配置类，再按需筛选出需要启用的自动配置类。
2. 局部筛选：进入是配置类内部进行第二次筛选，一个模块引入以后几乎不可能需要全部的组件，这时候就需要进行二次筛选，只激活当前实际需要的 Bean，从而实现真正的按需装配、避免资源浪费和 Bean 冲突。
3. 全局自定义优先：如果开发者手动定义了整个模块的核心配置（如 WebMvcConfigurer、Redis 配置类），那么该自动配置类会整体失效，Spring Boot 会优先保留开发者自定义的实现类。
4. 局部自定义优先：如果开发者只定义了自动配置类中的某个 Bean（如自定义一个 ObjectMapper），Spring Boot 会跳过默认注册，优先保留开发者自定义的 Bean。常见判断逻辑如 @ConditionalOnMissingBean。

三、超简略流程

1. 引入 Starter（自动装配入口依赖）
2. 启动类触发 @SpringBootApplication
3. 解析 @EnableAutoConfiguration
4. 加载 spring.factories（候选配置类列表）
5. 执行全局筛选，判断是否启用每个配置类
6. 执行全局自定义优先判断（是否已有模块配置）
7. 进入配置类内部，逐个执行局部筛选与注册
8. 注册符合条件的 Bean，完成自动装配

四、总结

自动装配并不是“全自动、全封闭”的黑盒机制，而是一种具备可控性、可扩展性、默认即合理的配置策略。它的核心在于在恰当时机、为恰当场景注册恰当的 Bean，并且始终允许开发者以最小成本进行替换与定制。
通过筛选 + 优先机制，Spring Boot 实现了：

1. 按需加载：只启用当前项目真正需要的配置；
2. 默认友好：无需配置也能开箱即用；
3. 可插可替：支持局部或全局自定义 Bean 替换；
4. 模块解耦：Starter 与配置解耦，统一导入即集成。

这套机制正是 Spring Boot 能成为“现代 Java 后端开发事实标准”的重要原因之一