自动配置——"Boot"之所以是 Boot

3.1starter 是什么

starter 是一组精选的传递依赖描述符，把一个功能切片需要的 jar 一次拉齐。

以 spring-boot-starter-web 为例：它拉入 spring-webmvc、内嵌 Tomcat、Jackson 等，classpath 上有了这些类，自动配置里的 @ConditionalOnClass 才能命中相应的装配逻辑。starter 和自动配置是配套的两半：starter 负责把类放到 classpath，自动配置据此决策是否装配。

starter 本身通常只有一个 pom.xml，不含任何 Java 代码——装配代码在 spring-boot-autoconfigure 里，与 starter 分离正是为了让工程师能在不用 starter 的情况下单独声明依赖，而自动配置仍然生效。

3.2@SpringBootApplication 展开

@SpringBootApplication 是三个注解的组合别名，展开后等价于：

// @SpringBootApplication 等价于同时标注以下三个注解：
@SpringBootConfiguration      // @Configuration 的别名，声明主类为配置类
@EnableAutoConfiguration      // 触发自动配置发现流程（见 3.3）
@ComponentScan                // 以主类所在包为根包扫描组件
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

@ComponentScan 的扫描根包是主类所在包——这是"主类要放在最外层包"的根本原因：若主类嵌套在子包中，同级或上层的 @Component 就不在扫描范围内。

@EnableAutoConfiguration 通过 @Import(AutoConfigurationImportSelector.class) 挂载导入选择器，这是整个自动配置发现机制的入口，第 3.3 节将沿这条链深入。

3.3自动配置如何被发现（机制核心）

AutoConfigurationImportSelector 实现的是 DeferredImportSelector，而非普通 ImportSelector。这一细节至关重要：ConfigurationClassPostProcessor（第 1 章的 BFPP）在处理所有 @Configuration 类时，会把 DeferredImportSelector 的调用推迟到当前轮次所有普通配置类都处理完之后才执行——这正是"用户配置先注册、自动配置后处理"的机制起点（3.5 节进一步展开）。

AutoConfigurationImportSelector.getCandidateConfigurations() 内部调用 ImportCandidates.load(AutoConfiguration.class, classLoader)，从 classpath 上所有 jar 的以下文件中读取候选类名：

# Spring Boot 4.0.x — 自动配置类注册文件
# 2.7 起取代旧的 spring.factories 中的 EnableAutoConfiguration 键
# 每行一个全限定类名
org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration
# ... 共约 140+ 行

3.4@Conditional 筛选

候选类名列表在真正解析之前还要经过两轮筛选：

第一轮（快速剪枝）：AutoConfigurationImportFilter 对候选列表做 classpath 级快速扫描。其中 OnClassCondition、OnBeanCondition、OnWebApplicationCondition 三个实现会检查 .imports 文件同目录的 ConditionalOnClass.index 等 AOT 索引文件，把 classpath 上明显缺失依赖的候选类一次性排除，避免后续解析大量必然不命中的配置类。

第二轮（逐类求值）：通过过滤的候选类被 ConfigurationClassPostProcessor 正式解析，此时注解上的 @ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty 等按 Condition 接口逐个求值，不满足的类整体跳过。

以下是一个简化的自动配置类结构，模仿 DataSourceAutoConfiguration 的风格：

package com.example.autoconfigure;

import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.boot.autoconfigure.condition.ConditionalOnClass;
import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.context.annotation.Bean;
import javax.sql.DataSource;

@AutoConfiguration                          // 声明为自动配置类（包含 @Configuration）
@ConditionalOnClass(DataSource.class)       // classpath 上有 DataSource 才生效
public class MyDataSourceAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean               // 用户已定义 DataSource Bean 时退让
    public DataSource dataSource() {
        // 示意：返回一个默认 DataSource 实现
        return buildDefaultDataSource();
    }

    private DataSource buildDefaultDataSource() {
        // ...
        return null;
    }
}

常用 @ConditionalOnXxx 对照

3.5用户优先 = 排序（揭穿机制）

"用户 Bean 总赢"并非 @ConditionalOnMissingBean 拥有什么特殊的"用户优先"语义——背后是严格的时序保证，可以分解为两个关键事实：

事实一：自动配置类被 AutoConfigurationSorter 排到最后解析。 DeferredImportSelector 的回调在同一轮 ConfigurationClassPostProcessor 处理中最后执行，这保证工程师写的 @Configuration 类（及其 @Bean 方法）对应的 BeanDefinition 先于任何自动配置类注册进容器。

事实二：OnBeanCondition 是 ConfigurationCondition，在 REGISTER_BEAN 阶段求值。 @Conditional 有两个求值时机：PARSE_CONFIGURATION（解析 @Configuration 结构时）和 REGISTER_BEAN（向容器注册 BeanDefinition 时）。OnBeanCondition 选择 REGISTER_BEAN 阶段，此时用户的 BeanDefinition 已在注册表中。自动配置类的 @Bean @ConditionalOnMissingBean 方法在求值时看到"该类型已有注册"，条件不成立，直接跳过。

这两个事实叠加，产生了"用户 Bean 赢"的效果——不是魔法，是 排序 + 条件求值时机 的精确配合。