Spring Boot 源码主线：启动、配置加载与自动配置

Spring Boot 没有替代 Spring。它通过约定、自动配置和依赖管理，降低了创建 Spring 应用的装配成本。理解源码时，应把重点放在“它如何准备并启动 ApplicationContext”。

SpringApplication.run() 主流程

启动流程可以概括为：

创建 SpringApplication
  -> 推断应用类型
  -> 加载初始化器和监听器
  -> 准备 Environment
  -> 创建 ApplicationContext
  -> 加载 BeanDefinition
  -> refresh()
  -> 执行 Runner

真正创建 Bean 的核心仍然是 Spring 的 refresh()。Spring Boot 主要负责在调用它之前准备环境、上下文、配置类和监听器。

配置文件如何加载

配置最终会进入 Environment，并以多个 PropertySource 的形式保存。命令行参数、系统属性、环境变量、配置文件等具有不同优先级。

阅读时重点关注三个问题：

1. 配置源何时被发现和加载。
2. 多个配置源如何排序和覆盖。
3. 属性如何绑定到 @ConfigurationProperties 对象。

理解 Environment 后，Profile、多环境配置和外部化配置就不再神秘。

自动配置的本质

@SpringBootApplication 组合了配置类、组件扫描和自动配置入口。自动配置不是无条件创建 Bean，而是大量条件判断的集合：

• 类路径上是否存在某个类。
• 容器里是否缺少某个 Bean。
• 配置项是否启用某项功能。
• 当前是否为 Web 应用。

因此自动配置遵循“框架给默认值，用户定义优先”的原则。排查问题时，应检查自动配置报告和条件为何匹配或未匹配。

Starter 与 SPI

Starter 是一组面向场景的依赖和自动配置约定。自定义 Starter 通常包含：

1. 配置属性类。
2. 自动配置类。
3. 条件注解。
4. 自动配置导入声明。
5. 可选的业务门面或客户端。

Java SPI 根据接口查找实现，Spring Boot 的导入机制也体现了“约定位置发现扩展”的思想，但会进一步结合条件装配和容器生命周期。

事件发布与监听

Spring Boot 在启动不同阶段发布事件，监听器可以在 Environment、Context 创建和应用就绪等阶段介入。事件机制降低了启动器与扩展逻辑的直接耦合。

Redis、MyBatis 等整合为什么简单

以 Redis 或 MyBatis 为例，Starter 引入依赖后，自动配置会读取属性、判断类路径与 Bean 条件，再创建客户端、连接工厂或模板对象。所谓“开箱即用”，本质是把重复的 JavaConfig 固化为带条件的配置类。

总结

Spring Boot 源码主线是：SpringApplication 编排启动，Environment 统一配置，事件监听器提供阶段扩展，自动配置按条件注册 Bean，Starter 负责交付依赖与约定。最终的对象创建和生命周期管理仍由 Spring 容器完成。