场景：第三方工具包里的 @Component（PPT 第 24～25 页）#

课程准备了一个第三方工具包 itheima-utils，里面有个类：

1
@Component
2
public class TokenParser {
3
    public void parse(){
4
        System.out.println("TokenParser ... parse ...");
5
    }
6
}

头上明明标着 @Component（38 篇讲过它的作用：交给 IOC 容器管理），可把它作为依赖引进”我们的项目”之后，注入 TokenParser 却失败——bean 根本不在容器里。

原因在第 27 页的问答里点破，其本质是组件扫描的范围：基于 @Component 及其衍生注解声明的 bean，要想生效必须被组件扫描注解扫描到；而 @SpringBootApplication 里的 @ComponentScan（下一节源码跟踪细看）默认只扫引导类所在包及其子包——引导类在 com.itheima，工具包在 com.example，扫不到，@Component 就白标了。

方案一：@ComponentScan 扫描指定包（PPT 第 25 页）#

最直接的做法是把工具包的包名加进扫描范围：

1
@ComponentScan({"com.example","com.itheima"})
2
@SpringBootApplication
3
public class SpringbootWebConfigApplication {
4
    //...
5
}

PPT 里把这行注释里的省略号写得很诚实：,"com.alibaba","com.google",... —— 每引入一个第三方包，就得往这个数组里补一个包名。PPT 对这种方案的评价是四个字：

性能低、使用繁琐

• 性能低：扫描范围越大，启动时要检查的类越多（每个类都要判断”是不是 @Component / 是不是要被注册”）；
• 使用繁琐：包名要一个个手写，而且你未必知道第三方包里那些要注册的类到底在哪个包（一个 jar 里可能好几个顶层包）。

方案二：@Import 导入（PPT 第 26 页）#

换个思路：既然要的是”把某些类放进 IOC 容器”，那就别靠”扫描碰运气”，而是明确地导入。PPT 给的说法是：

@Import 导入。@Import 导入的类会被 Spring 加载到 IOC 容器中。

1
@Import({TokenParser.class, HeaderConfig.class})
2
@SpringBootApplication
3
public class SpringbootWebConfig2Application {
4
    //...
5
}

PPT 把导入形式归纳为四种，第三方工具包里正好每种都有一个现成的例子（对照上面那张结构图看）：

四段代码（都来自课程的工具包源码）：

1
// ① 普通类：头上标了 @Component，但因为在 com.example 包里，光靠扫描扫不到
2
@Component
3
public class TokenParser {
4
    public void parse(){
5
        System.out.println("TokenParser ... parse ...");
6
    }
7
}

1
// ② 配置类：类上 @Configuration，方法上 @Bean，导入它就把这两个 bean 一起带进容器
2
@Configuration
3
public class HeaderConfig {
4
    @Bean
5
    public HeaderParser headerParser(){
6
        return new HeaderParser();
7
    }
8
    @Bean
9
    public HeaderGenerator headerGenerator(){
10
        return new HeaderGenerator();
11
    }
12
}

1
// ③ ImportSelector 实现类：selectImports 返回要导入的类的全类名数组
2
public class MyImportSelector implements ImportSelector {
3
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
4
        return new String[]{"com.example.HeaderConfig"};
5
    }
6
}

1
// ④ @EnableXxx 注解：把 @Import 封装进一个自定义注解里，用起来最省事
2
@Retention(RetentionPolicy.RUNTIME)
3
@Target(ElementType.TYPE)
4
@Import(MyImportSelector.class)
5
public @interface EnableHeaderConfig {
6
}

对方案二的评价，PPT 用了两个词：方便、优雅——不用猜包名、不用维护一长串扫描路径，第三方想让你用哪些类，自己用 @Import / @EnableXxx 说清楚就好。

必答问答（PPT 第 27 页）#

@SpringBootApplication 的三个组成部分（PPT 第 29 页）#

起点是我们天天见的引导类：

1
@SpringBootApplication
2
public class SpringbootWebConfigApplication {
3
    public static void main(String[] args) {
4
        SpringApplication.run(SpringbootWebConfigApplication.class, args);
5
    }
6
}

PPT 说它是”该注解标识在 SpringBoot 工程引导类上，是 SpringBoot 中最最最重要的注解”，并且”由三个部分组成”：

前两个正好解释了前面所有”为什么”：引导类自己是个配置类（所以 88 篇里把 @Bean 写在引导类上也能生效），默认扫描范围是”引导类所在包及其子包”（所以第三方包里的 @Component 扫描不到）。真正实现自动配置的是第三个。

（图里还能看到引导类上的 @ComponentScan 带了两个 excludeFilters——TypeExcludeFilter 与 AutoConfigurationExcludeFilter。它们是”防止重复注册”用的过滤器，PPT 没展开，这里知道有这么回事就行。）

从 @EnableAutoConfiguration 一路读到 imports 文件（PPT 第 30 页）#

点开 @EnableAutoConfiguration，关键就一行：它头上写着 @Import(AutoConfigurationImportSelector.class)——用的是上一节方案二里的第三种导入形式。也就是说，SpringBoot 的自动配置是靠 @Import 导入一个 ImportSelector 实现类来完成的。

那个实现类 AutoConfigurationImportSelector 的核心方法 selectImports(...) 返回 String[]，方法体做的事可以概括成三步（方法与报错信息都来自 Spring Boot 3.x 源码，PPT 第 30 页把这几处圈出来过）：

1
// AutoConfigurationImportSelector 里的关键代码（摘录，方法名与 PPT 截图一致）
2
public String[] selectImports(AnnotationMetadata annotationMetadata) {
3
    if (!isEnabled(annotationMetadata)) {
4
        return NO_IMPORTS;
5
    }
6
    // ② 准备"待导入"的自动配置类名单
7
    AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(annotationMetadata);
8
    // ③ 返回全类名数组
9
    return StringUtils.toStringArray(autoConfigurationEntry.getConfigurations());
10
}
11

12
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
13
    // ① 从约定的文件里读取自动配置类的全类名
14
    List<String> configurations = ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()).getCandidates();
15
    Assert.notEmpty(configurations, "No auto configuration classes found in "
16
            + "META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. ...");
17
    return configurations;
18
}

第 ① 步里那个约定的文件就是这条链路上最关键的落点：

1
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

它躺在 spring-boot-autoconfigure 这个 jar 包里：

“全部注册到 IOC 容器？“——不（PPT 第 30、32 页）#

名单读到手了，是不是就照单全收、一个个注册成 bean？PPT 第 30 页在 selectImports 旁边打了个大大的问号：

全部注册为 IOC 容器的 bean ???

第 32 页给出答案：

NO! …… SpringBoot 会根据 @Conditional 注解条件装配。

理由不难想：那份 imports 名单里躺着上百个自动配置类，覆盖 JPA、MongoDB、Redis、Neo4j、LDAP……我们的工程里根本没有这些东西的依赖。要是全注册，要么启动就报错，要么容器里塞满一堆用不上的 bean。所以真正的流程是——先按条件判断，满足了才注册。判断用的就是下一节的 @Conditional。

本机实测：@ConditionalOnMissingBean 到底管什么#

“没有对应的 bean 才注册”这句话，最好的验证办法就是自己先造一个同类型的 bean，看自动配置的那个方法还执不执行。本机的实验工程正好有一个现成的自动配置类（90 篇要写的那个阿里云 OSS starter，它的 @Bean 上就带着 @ConditionalOnMissingBean），于是往工程里加了一个配置类：

1
@Configuration
2
public class MyConfig {
3
    @Bean
4
    public AliyunOSSOperator aliyunOSSOperator() {
5
        System.out.println("[实验] 自定义的 AliyunOSSOperator bean 被创建");
6
        return new AliyunOSSOperator(null);
7
    }
8
}

重启之后的本机实测结果：

1
INFO  ... : Starting SpringbootAutoconfigurationTestApplication v0.0.1-SNAPSHOT ...
2
INFO  ... : Tomcat initialized with port 8080 (http)
3
[实验] 自定义的 AliyunOSSOperator bean 被创建
4
INFO  ... : Tomcat started on port 8080 (http) with context path ''
5
INFO  ... : Started SpringbootAutoconfigurationTestApplication in 2.084 seconds (process running for 2.539)

三条结论：

1. 控制台出现了 [实验] 自定义的 AliyunOSSOperator bean 被创建——用户自己定义的那个 bean 正常创建了；
2. 应用正常启动，/check 接口依然能注入 AliyunOSSOperator，没有出现 NoUniqueBeanDefinitionException（“同类型 bean 有两个，我该注入哪个”的错误）；
3. 由此反推：自动配置类里那个带 @ConditionalOnMissingBean 的 @Bean 方法没有执行——容器里已经有 AliyunOSSOperator 了（用户自己定义的），自动配置就让位了。否则容器里会有两个同类型 bean，注入必然报错。

这正是”自动配置只在缺少时才补上”的硬证据：自动配置是”兜底”，不是”抢活”——用户定义了就用用户的（这也是为什么你在项目里可以放心地覆盖掉某个自动配置的默认 bean）。

必答问答（PPT 第 33 页）#

一、知识回顾（读完直接做下面的实践题）#

1. SpringBoot 的两个核心：起步依赖（解决依赖繁琐）+ 自动配置（解决配置繁琐）；PPT 给这一节贴的三个标签是”熟练使用 / 面试高频 / 汲取思想”
2. 起步依赖的原理：依赖传递——spring-boot-starter-web 自己的价值不在代码，而在 pom.xml 里写了一串它需要的坐标（spring-boot-starter、spring-boot-starter-json、spring-boot-starter-tomcat→spring-web/spring-webmvc/jackson…），引一个就全带进来；版本由 spring-boot-starter-parent 统一管理
3. 自动配置的定义：当 Spring 项目启动后，一些配置类、bean 对象自动存入 IOC 容器，不需要我们手动声明，从而简化开发、省去繁琐的配置操作（例子：没写过 Gson 的 bean 定义，却可以 @Autowired private Gson gson;）
4. 第三方 @Component 不生效的原因：@Component 及衍生注解声明的 bean 要生效，必须被组件扫描注解扫描到；@ComponentScan 默认只扫引导类所在包及其子包，第三方类的包（如 com.example）不在范围内
5. 两套实现方案与 @Import 的四种导入形式：方案一是 @ComponentScan 扫描指定包（@ComponentScan({"com.example","com.itheima"})）——性能低、使用繁琐（每引一个包都要加）；方案二是 @Import 导入——方便、优雅，四种形式是导入普通类（TokenParser）、导入配置类（HeaderConfig，类上 @Configuration + 方法上 @Bean）、导入 ImportSelector 实现类（MyImportSelector，selectImports() 返回全类名数组）、@EnableXxx 注解（EnableHeaderConfig，注解头上 @Import(...)，用起来最省事）
6. @SpringBootApplication 的三个组成部分：@SpringBootConfiguration（与 @Configuration 作用相同，声明当前是配置类）、@ComponentScan（组件扫描，默认扫引导类所在包及其子包）、@EnableAutoConfiguration（自动配置的核心注解）
7. 自动配置的源码链条：@EnableAutoConfiguration 里 @Import(AutoConfigurationImportSelector.class) → AutoConfigurationImportSelector.selectImports(...) → 读 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 拿到一批 XxxAutoConfiguration 全类名 → 按 @Conditional 条件装配后才注册 bean
8. 版本差异：2.7.0 之前自动配置类定义在 spring.factories 文件里；2.7 之后改用 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（本机 Spring Boot 3.2.x 走的就是 imports 这套，spring.factories 是历史写法）
9. @Conditional：作用是按照一定的条件进行判断，满足给定条件后才注册对应的 bean 到 IOC 容器；位置是方法、类；三个常用衍生注解——@ConditionalOnClass（有对应字节码才注册）、@ConditionalOnMissingBean（按类型或名称判断，没有对应 bean 才注册）、@ConditionalOnProperty（配置文件中有对应属性和值才注册）
10. 本机实测：自己定义一个同类型的 AliyunOSSOperator bean 后重启——控制台打印了 [实验] 自定义的 AliyunOSSOperator bean 被创建，应用正常启动、/check 依然能注入，没有 NoUniqueBeanDefinitionException；反推自动配置类里带 @ConditionalOnMissingBean 的那个 @Bean 方法没有执行（自动配置是兜底，用户定义了就让位）

二、裸写题#

• 2-1 让第三方工具包里的类真正进容器（两种方案） 需求：工程引了一个第三方工具包，里面有个工具类头上标着”交给容器管理”的注解，可它在 com.example 包下，而我们的引导类在 com.itheima 包下——注入它时报”找不到这个 bean”。 要求： ① 用第一种方案（扩大扫描范围）解决，写出要加在哪、加什么，并说明它的两个缺点； ② 用第二种方案（导入）解决，写出两种写法：直接把工具类和它的配置类导入；以及用一个自定义注解把导入包起来（用起来最省事的那种形式）； ③ 说明这个工具包里那个”返回要导入的类全类名数组”的类叫什么角色、它的方法返回什么类型； ④ 回答：为什么第三方包里标了”交给容器管理”注解的类会失效？ （写作区见练习文件 test_89_自动配置原理.txt 的题目2-1。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：先想”类是怎么进容器的”——要么被扫描到，要么被明确导入；扫描的默认范围是引导类所在包及其子包，所以打破僵局只有”把范围撑大”或”点名导入”两条路 二级 · 方法：方案一 @ComponentScan({"包名1","包名2"})（加在引导类上，注意它会覆盖默认扫描范围，所以要带上自己项目的包名）；方案二 @Import({A.class, B.class})，四种形式是普通类 / 配置类 / ImportSelector 实现类 / @EnableXxx 注解；自定义注解的写法照 @Retention(RUNTIME) + @Target(TYPE) + @Import(...) 三件事 三级 · 骨架：① @____({"com.example","com.itheima"}) + @SpringBootApplication；② @____({TokenParser.class, HeaderConfig.class})；自定义注解 public @interface EnableHeaderConfig { } 头上写 @____(MyImportSelector.class)；③ public class MyImportSelector implements ____ { public String[] ____(AnnotationMetadata m) { return new String[]{"____"}; } }

  参考答案（做完再点开）

  ① 扩大扫描范围（方案一）：

  1
  @ComponentScan({"com.example","com.itheima"})   // 第三方包 + 自己项目的包都要写上
  2
  @SpringBootApplication
  3
  public class SpringbootWebConfigApplication {
  4
      //...
  5
  }

  两个缺点：性能低（扫描范围越大，启动时要检查的类越多）、使用繁琐（每引入一个第三方包都得往数组里补一个包名，而且未必知道要注册的类在哪个包）。 ② 点名导入（方案二）：

  1
  // 写法一：直接把类和配置类导入
  2
  @Import({TokenParser.class, HeaderConfig.class})
  3
  @SpringBootApplication
  4
  public class SpringbootWebConfig2Application {
  5
      //...
  6
  }
  7
  
  8
  // 写法二：自定义注解把导入包起来（使用方只贴一个注解）
  9
  @Retention(RetentionPolicy.RUNTIME)
  10
  @Target(ElementType.TYPE)
  11
  @Import(MyImportSelector.class)
  12
  public @interface EnableHeaderConfig {
  13
  }
  14
  
  15
  // 使用：
  16
  @EnableHeaderConfig
  17
  @SpringBootApplication
  18
  public class SpringbootWebConfig2Application { }

  显示更多显示更少

  ③ 那个类实现的是 ImportSelector 接口，方法名是 selectImports，返回 String[]（要导入的类的全类名数组）：

  1
  public class MyImportSelector implements ImportSelector {
  2
      public String[] selectImports(AnnotationMetadata importingClassMetadata) {
  3
          return new String[]{"com.example.HeaderConfig"};
  4
      }
  5
  }

  ④ 因为”交给容器管理”这个注解（@Component 及其衍生注解）只在被组件扫描扫到时才生效；默认扫描范围是引导类所在包及其子包，com.example 不在其中，所以那个类虽然标了注解，容器里却没有它。 自查：三种写法随便留一种、启动一次，注入不再报错就说明生效了；把导入全删掉，报错的是 NoSuchBeanDefinitionException 之类的”找不到 bean”。

• 2-2 手写一个自动配置类，并让它被 SpringBoot 认出来 需求：你做了一个公共组件，想让别的工程”引了依赖就能直接用”。要求： ① 写一个自动配置类（放在你自己的包下），让它做三件事——把配置参数对象启用起来（能读取指定前缀的配置项）、声明组件的工具类 bean、并且尊重使用方（使用方自己定义了就不要再补）； ② 写清楚这个自动配置类应该登记在哪个文件的完整路径（放到你工程的 resources 下的哪个目录、文件叫什么名字）； ③ 那个文件里写什么内容？ ④ 回答：如果自动配置类里不写”尊重使用方”那个注解会怎样？ （写作区见练习文件 test_89_自动配置原理.txt 的题目2-2。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：自动配置类本身就是”配置类”，所以它有 @Configuration 和 @Bean；参数对象一般是”绑定某个前缀的配置项”的类，需要用专门的注解把参数类启用成 bean（而不是给它加 @Component）；“尊重使用方”就是条件装配里的那一个；②③ 是本节最需要背下来的那条路径与文件 二级 · 方法：类上 @Configuration + @EnableConfigurationProperties(XxxProperties.class)；方法上 @Bean + @ConditionalOnMissingBean；文件路径 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（注意是 META-INF/spring/，不是 META-INF/）；文件内容 = 一行自动配置类的全类名；老版本（2.7 之前）这个名单写在 META-INF/spring.factories 里 三级 · 骨架：

  1
  @____(OssProperties.class)
  2
  @____
  3
  public class OssAutoConfiguration {
  4
      @____
  5
      @____
  6
      public OssOperator ossOperator(OssProperties props) {
  7
          return new OssOperator(props);
  8
      }
  9
  }

  ② 的路径：src/main/resources/____/____/org.springframework.boot.autoconfigure.____.imports

  参考答案（做完再点开）

  ① 自动配置类：

  1
  package com.example.oss;
  2
  
  3
  import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
  4
  import org.springframework.boot.context.properties.EnableConfigurationProperties;
  5
  import org.springframework.context.annotation.Bean;
  6
  import org.springframework.context.annotation.Configuration;
  7
  
  8
  @EnableConfigurationProperties(OssProperties.class)   // 让参数类成为 bean，并绑定配置文件里的值
  9
  @Configuration                                          // 自动配置类本身也是配置类
  10
  public class OssAutoConfiguration {
  11
  
  12
      @Bean
  13
      @ConditionalOnMissingBean                           // 使用方自己定义了就不要再补
  14
      public OssOperator ossOperator(OssProperties props) {
  15
          return new OssOperator(props);
  16
      }
  17
  }

  显示更多显示更少

  ② 文件放在 src/main/resources/META-INF/spring/ 目录下，文件名固定为 org.springframework.boot.autoconfigure.AutoConfiguration.imports，完整路径就是：

  1
  src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

  ③ 内容只有一行——自动配置类的全类名：

  1
  com.example.oss.OssAutoConfiguration

  ④ 不写 @ConditionalOnMissingBean 的话，使用方只要自己定义过一个同类型的 bean，容器里就会出现两个同类型 bean：注入时报 NoUniqueBeanDefinitionException（“同类型 bean 有多个，我该注入哪个”）——自动配置从”兜底”变成了”抢活”。本机实测的反面就是这个：加上它之后，自定义 bean 创建了、自动配置的那个方法没执行、应用正常启动。 自查：写好后把工程打成 jar / 装进本地仓库，在另一个工程里引进来启动——不用写任何 @Configuration 就能注入 OssOperator，就说明这条链路通了（90 篇会完整做一遍）。 老版本对照：2.7.0 之前这份名单写在 META-INF/spring.factories 里（按 org.springframework.boot.autoconfigure.EnableAutoConfiguration= 的键写），现在读的是 .imports。

• 2-3 把自动配置这条链路讲给别人听 需求：面试官问：“SpringBoot 的自动配置是怎么实现的？“请按启动顺序把链路讲一遍，讲到”为什么名单里的类不会全部注册”为止。 要求（写在回答里）： ① 引导类上那个注解由哪三部分组成，各自干什么； ② 自动配置是从哪一行 @Import 开始的，被导入的是个什么角色； ③ 名单文件的确切路径与文件名，以及老版本的替代方案； ④ 名单到手之后为什么不能”照单全收”，靠什么决定注册与否； ⑤ 用一句话说明自动配置和”用户自己定义的 bean”是什么关系。 （写作区见练习文件 test_89_自动配置原理.txt 的题目2-3。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：按”入口注解 → 导入选择器 → 读名单文件 → 条件筛选 → 注册”五步走，每步只讲一个关键词；⑤ 的答案藏在 @ConditionalOnMissingBean 的名字里 二级 · 方法：关键词——@SpringBootConfiguration / @ComponentScan / @EnableAutoConfiguration；AutoConfigurationImportSelector（ImportSelector 实现类）；META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（老版本 spring.factories）；@Conditional 家族（@ConditionalOnClass / @ConditionalOnMissingBean / @ConditionalOnProperty） 三级 · 骨架：① @SpringBootApplication = @____（配置类）+ @____（组件扫描，默认扫引导类所在包及子包）+ @____（自动配置核心）；② @EnableAutoConfiguration 里 @Import(____.class)；③ 路径 META-INF/spring/org.springframework.boot.autoconfigure.____.imports；④ 靠 @____ 条件装配；⑤ 自动配置是”____“，用户自己定义了就让位

  参考答案（做完再点开）

  ① @SpringBootApplication 由三部分组成：@SpringBootConfiguration（与 @Configuration 作用相同，声明引导类本身也是配置类）、@ComponentScan（组件扫描，默认扫描引导类所在包及其子包）、@EnableAutoConfiguration（自动配置的核心注解）。 ② 从 @EnableAutoConfiguration 开始：它里面写着 @Import(AutoConfigurationImportSelector.class)——被导入的是一个 ImportSelector 的实现类，也就是 @Import 四种形式里的第三种；真正干活的是它的 selectImports(...) 方法（返回 String[]）。 ③ 名单文件的确切路径与文件名：

  1
  META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

  它在 spring-boot-autoconfigure 这个 jar 包里，一行一个 XxxAutoConfiguration 全类名。2.7.0 之前这些自动配置类定义在 spring.factories 里，属于历史写法（本机 Spring Boot 3.2.x 走的是 .imports）。 ④ 不能照单全收：名单里躺着上百个自动配置类（JPA、MongoDB、Redis、Neo4j、LDAP……），工程里根本没引这些依赖，全注册要么启动报错要么塞一堆没用的 bean。真正决定注册与否的是 @Conditional 及其衍生注解（条件装配）：@ConditionalOnClass（环境里有对应字节码才注册，常加在类上）、@ConditionalOnMissingBean（没有对应 bean 才注册，常加在方法上）、@ConditionalOnProperty（配置文件里有对应属性和值才注册）。满足条件的才注册进 IOC 容器。 ⑤ 自动配置是”兜底”，不是”抢活”：容器里已经有同类型的 bean（用户自己用 @Component / @Bean 声明的）时，带 @ConditionalOnMissingBean 的自动配置方法就不执行——用户说了算。本机实测过这一幕：自定义的 AliyunOSSOperator 被创建、自动配置的那个 @Bean 没执行、应用正常启动且能正常注入。

三、综合题#

• 3-1 走一遍自动配置的完整链路，并亲手验证”条件装配” 这一题把 PPT 第 29～31 页的源码跟踪与本章的实测串成一条线来做。

  1. 打开一个 SpringBoot 工程，点进引导类上的 @SpringBootApplication，把它头上的三个组成部分抄下来（对着 IDEA 里的源码看，不要背）；
  2. 点进 @EnableAutoConfiguration，找到里面那行 @Import(...)，写下被导入的类名；再点进这个类，找到 selectImports(...) 方法，看它最终是从哪个方法、哪个文件里拿到自动配置类名单的；
  3. 在本机 Maven 仓库里找到 spring-boot-autoconfigure 的 jar（或直接在 IDEA 的 External Libraries 里展开它），打开 META-INF/spring/ 目录，记下你看到的两个文件的名字；把 .imports 文件打开，抄下任意三行（只看，不要改依赖包里的文件）；
  4. 从这三行里挑一个自动配置类，点进去看它类上和 @Bean 方法上有没有 @Conditional 系列的注解，各是什么、判断条件是什么；
  5. 动手做条件装配实验：在你的工程里自己定义一个与某个自动配置类同类型的 bean（写在 @Configuration 配置类里），启动应用；
  6. 记录：控制台有没有出现你自己那句打印？应用启动了吗？接口还能正常注入这个 bean 吗？有没有出现”同类型 bean 有两个”的报错？
  7. 收尾：把你加的那个配置类删掉（或注释掉），说明第 6 步的现象证明了什么；
  8. 回答两个问题：① 本机 Spring Boot 是哪个版本、读的是 .imports 还是 spring.factories？② 如果工程里根本没有引某个库的依赖，名单里的那个自动配置类还会生效吗？靠哪个注解挡住的？

  （练习文件 test_89_自动配置原理.txt 的”综合题”一段里按这 8 步给了写作区。）

  涉及知识点

  知识点	在这里的应用
  @SpringBootApplication 三部分（PPT 29）	第 1 步——从引导类的注解源码里读出来
  AutoConfigurationImportSelector 与 imports 文件（PPT 30）	第 2、3 步——点名导入 → 选择器 → 名单文件
  版本差异（PPT 30 注意 + ）	第 3、8 步——本机 3.2.x 读 .imports，spring.factories 是历史写法
  @Conditional 三兄弟（PPT 31）	第 4、8 步——类上用 Class 判断、方法上用 MissingBean 判断
  本机实测	第 5～7 步——自定义 bean 创建了、自动配置的没执行、应用正常启动

  提示（先自己想，实在想不出再点开）

  一级 · 思路：先”读”再”跑”——前四步都只是读源码和 jar 里的文件（不许背），第 5 步才动手；动手时只加一个自己造的同类 bean，观察”自动配置让不让位” 二级 · 方法：三部分注解 @SpringBootConfiguration / @ComponentScan / @EnableAutoConfiguration；被导入的类是 AutoConfigurationImportSelector；读名单的方法是 getCandidateConfigurations(...)，用的是 ImportCandidates.load(...)；jar 里两个文件是 spring.factories 与 org.springframework.boot.autoconfigure.AutoConfiguration.imports；同类型 bean 用 @Bean 在 @Configuration 类里声明；注入报错关键词 NoUniqueBeanDefinitionException 三级 · 骨架：① @SpringBootApplication = @____ + @____ + @____；② @Import(____.class)；③ 文件路径 META-INF/spring/org.springframework.boot.autoconfigure.____.imports；⑤ @____ public class MyConfig { @____ public 同类型 xxx() { System.out.println("我定义的被创建了"); return ...; } }；⑧ ①本机是 ____ 版本 → 读 ____

  参考答案（做完再点开）

  1. 三部分：@SpringBootConfiguration（声明引导类也是配置类）、@ComponentScan（组件扫描，默认扫引导类所在包及其子包）、@EnableAutoConfiguration（自动配置核心）。源码里还能看到 @ComponentScan 带了两个排除过滤器（TypeExcludeFilter、AutoConfigurationExcludeFilter），课上不展开。
  2. @Import(AutoConfigurationImportSelector.class)；selectImports(...) 里先判断是否启用，再调 getAutoConfigurationEntry(...)，真正的名单来自 getCandidateConfigurations(...)——它用 ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()).getCandidates() 从约定文件里读，并有 Assert.notEmpty(...) 兜底（报错信息里直接写着那个文件路径）。
  3. META-INF/spring/ 下能看到 org.springframework.boot.autoconfigure.AutoConfiguration.imports 和 spring.factories（后者是历史遗留）；.imports 文件一行一个全类名，例如 org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration、...data.redis.RedisAutoConfiguration、...data.mongodb.MongoDataAutoConfiguration 等等（抄自己看到的即可）。
  4. 例如 GsonAutoConfiguration：类上是 @ConditionalOnClass(Gson.class)（环境里有 Gson 的字节码才处理这个自动配置类），@Bean 方法上是 @ConditionalOnMissingBean（容器里没有 Gson 才补一个）。这正好解释”为什么引了依赖就能直接注入 Gson”。
  5. 实验代码（本机实测用的就是这个形状）：

  1
  @Configuration
  2
  public class MyConfig {
  3
      @Bean
  4
      public AliyunOSSOperator aliyunOSSOperator() {
  5
          System.out.println("[实验] 自定义的 AliyunOSSOperator bean 被创建");
  6
          return new AliyunOSSOperator(null);
  7
      }
  8
  }

  6. 本机实测：控制台出现了 [实验] 自定义的 AliyunOSSOperator bean 被创建；应用正常启动（Tomcat started on port 8080、Started SpringbootAutoconfigurationTestApplication in 2.084 seconds）；/check 依然能注入；没有 NoUniqueBeanDefinitionException。
  7. 删掉/注释掉自己那个配置类后，注入的 bean 换成自动配置提供的那个（本机 /check 返回 AliyunOSSOperator 已自动装配: true , 实例: com.aliyun.oss.AliyunOSSOperator@38ec98ee）——第 6 步的现象说明自动配置类里带 @ConditionalOnMissingBean 的 @Bean 方法没有执行，让位给了用户自己定义的 bean。
  8. 两个回答： ① 本机是 Spring Boot 3.2.x（启动日志里是 :: Spring Boot :: (v3.2.10)），读的是 .imports；2.7.0 之前才是 spring.factories，那是历史写法。 ② 不会生效。挡它的是 @ConditionalOnClass 这类条件注解——工程里没引那个库，字节码文件不存在，条件不满足，那个自动配置类整体就不处理；即使类条件满足，方法上还有 @ConditionalOnMissingBean / @ConditionalOnProperty 把关。所以名单里有几百个自动配置类，真正注册进容器的只有当前工程用得上的那一小批。