企业官网建设流程全解析

1. 自动装配到底“自动”了什么

先说一个我自己的真实经历。早几年接手公司内部某个老项目，代码里横七竖八堆着各种 @Configuration 类，启动类挨个 @Import。新同事入职，想在某个业务模块里加一个缓存配置，得先翻遍启动类、翻遍所有配置类，搞清楚谁被谁引用了，才敢动手。后来这个项目拆成 Spring Boot 架构，这些手工导入的配置全部删掉，剩下的事情交给自动装配来做，代码清爽了一个量级。

很多人在简历上写“熟悉 Spring Boot 自动装配”，但实际问起来，只能说出“就是根据条件自动加载配置类”这样一句结论。再往下问：自动装配的候选清单从哪来？条件判断在哪里执行？为什么写了 @ConditionalOnClass 之后配置类就一定不加载了？多数人答不上来。恰恰是这些细节，决定了你排查问题的速度，也决定了你能不能自己写一个靠谱的 Starter。

Spring Boot 的自动装配机制，本质上解决的是“配置从哪来、配置怎么生效、配置什么时候不生效”这三件事。传统 Spring 项目里，“配置从哪来”靠开发人员手工 @Import 或扫描组件配置；Spring Boot 把它变成“从 classpath 下的固定文件里读候选清单，再把清单里的配置类逐个做条件判断，能通过的才进入容器”。这套机制和 Starter 相辅相成：Starter 负责把依赖收拢起来，自动装配负责让依赖根据环境“按需生效”。

适合读这篇文章的人，我给个明确的分层。刚看完 Spring Boot 基础教程、想把原理弄通透的开发者，这篇文章能帮你建立一条完整链路；写过几个 Starter、但总是出现“配置没生效”问题的中级工程师，这篇文章里的排查手段和避坑记录可以直接抄；准备面试的人，把第 4 节和第 8 节的内容理顺，基本能应付掉绝大多数深挖型问题。

2. 自动装配背后的三个地基注解

2.1 @Configuration 只是换个姿势注册

很多人把 @Configuration 单纯理解为“IoC 容器里的配置类”，这个理解没错，但不够。在自动装配语境下，@Configuration 代表的是一个候选的“装配单元”。Spring Boot 的自动装配并不认识你的业务类，它只认带 @Configuration 的类，因为这类类里可以定义 @Bean 方法，也可以 @Import 别的配置。

这里有一个隐藏的差异值得注意：CGLIB 代理。@Configuration 类默认被 CGLIB 增强，因此类内部 @Bean 方法之间的调用走的不是普通 Java 方法调用，而是容器里的 Bean 引用。Spring Boot 的自动配置类全都标注了 @Configuration(proxyBeanMethods = false)，原因很实际——自动配置类内部很少需要依赖同一个类里其他 @Bean 方法，关掉代理可以减少启动时间。你自己写自动配置类时，建议保持 proxyBeanMethods = false，除非确实需要方法内部互相调用。

2.2 @Conditional 是“按需加载”的开关

自动装配如果只是把一堆配置类塞进容器，那和手工 @Import 没有任何区别，还会因为环境不同而报错。比如你引入了某个数据库连接池的 Starter，但项目里根本没有配数据源，自动配置类如果无条件生效，启动就会直接抛异常。

Spring Boot 用 @Conditional 家族解决这个问题。@ConditionalOnClass 判断 classpath 下有没有某个类，@ConditionalOnMissingBean 判断容器里有没有某个 Bean，@ConditionalOnProperty 判断配置项是否满足要求。这些条件注解全部落在配置类或 @Bean 方法上，判定结果为 false 的装配单元会被整体跳过。

条件注解的执行时机很多人没搞清楚。它不是在 Bean 实例化阶段执行，而是在容器刷新早期、配置类注册阶段执行。这意味着条件判断的结果和 Bean 创建无关，只和当前 Environment、类加载器里有什么、已经注册了哪些 BeanDefinition 有关。理解这一点，你才能明白为什么配置类里不能随便写初始化逻辑——初始化发生在条件判断之后，一旦条件通过，配置类里的 @Bean 方法就会继续走正常创建流程。

2.3 @ConfigurationProperties 给自动配置提供“可调参数”

自动配置类通常需要一个配置项映射类，把 application.properties 或 application.yml 里的属性绑定到 Java 对象上。比如 spring.datasource.url、spring.redis.host 这些，就是通过 @ConfigurationProperties 绑定的。

这一层设计很巧妙：自动配置类本身写死默认值，外部配置通过绑定机制覆盖默认值。Spring Boot 在绑定过程中还支持类型转换、校验、列表绑定等能力。写过 Starter 的人都知道，属性类命名一般放在 autoconfigure 模块里，类上标注 @ConfigurationProperties(prefix = "xxx")，再通过 @EnableConfigurationProperties 或者 @ConfigurationPropertiesScan 注册到容器。

绑定过程有一个优先级问题值得单独提。Environment 里的配置来源有多层，命令行参数高于环境变量，环境变量高于 application.yml，application.yml 又高于默认属性。自动配置类读取属性值时，走的正是 Environment 的 PropertyResolver，所以优先级体系天然生效。这也是为什么命令行里临时改端口、改数据源，不需要改配置文件的原因。

3. 装配清单从哪里来：AutoConfiguration.imports 的演进

3.1 Spring Boot 2.7 之前的 spring.factories

自动装配要处理“哪些配置类参与候选”，这套清单在 Spring Boot 2.7 之前写在 META-INF/spring.factories 文件里。文件内容是键值对形式，其中有一个特别长的 key：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.example.autoconfigure.XXXAutoConfiguration,\ com.example.autoconfigure.YYYAutoConfiguration

Spring Boot 启动时通过 SpringFactoriesLoader 读取这个文件，把对应的类加载成候选配置列表。spring.factories 同时承担了其他职责，比如 ApplicationContextInitializer、ApplicationListener，都用同一个文件。它是一个通用机制，能加载什么取决于你用什么 key 查。

这套方案的缺点随着 Starter 增多逐渐暴露：文件内容几乎全是自动配置类的全限定名，IDE 无法感知结构，也很难做编译期检查；而且所有自动配置类都挂在同一个 key 下，调试时想在项目里快速找到当前生效的配置，得频繁翻 jar 包。

3.2 新的 AutoConfiguration.imports 文件

Spring Boot 2.7 引入了 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件，专门用来放自动配置类列表。文件格式更直白，每行一个类：

com.example.autoconfigure.HelloServiceAutoConfiguration com.example.autoconfigure.HelloProperties

这个文件不再被 SpringFactoriesLoader 读取，而是由新的 AutoConfigurationImportSelector 分支逻辑处理，类型安全性和可读性都更好。Spring Boot 3.0 起，spring.factories 方式已被彻底移除，所有作者的 Starter 都必须改成新格式。我在公司维护的两个内部 starter，当时从 2.6 升到 2.7，改文件这一项是影响最直接的。

Spring Boot 3.x 还有一个相关变化：javax 包名换成了 jakarta。自动配置类里如果有对 Servlet 相关类的条件判断，注意 @ConditionalOnClass 里的类名要跟着改。这个坑在升级老项目时特别容易遇到。

3.3 classpath 扫描与 jar 包内的查找规则

AutoConfiguration.imports 文件是相对固定路径：META-INF/spring/ 目录下。Spring Boot 启动时，会扫描所有位于 classpath 下的 jar 包，在这个路径下找同名文件。

扫描过程有一点容易误解：它不是扫描当前项目 src/main/resources 下的单个文件，而是遍历所有 jar。每个 jar 里可以有自己的 META-INF/spring/AutoConfiguration.imports，汇总起来就是全项目的候选配置清单。正因为是遍历所有 jar，所以依赖引入顺序不会影响文件是否被发现，只会影响最终候选配置 List 的先后顺序。

排序规则在 Spring Boot 中由 @AutoConfigureOrder、@AutoConfigureBefore、@AutoConfigureAfter 三个注解控制。自动配置类之间经常存在先后依赖，比如缓存自动配置需要先有事务管理器支持，就需要显式声明顺序。如果没有声明顺序，默认顺序以类名、加载顺序兜底，出现循环依赖时 Spring Boot 会给出明确报错。

实际项目中我们更关心怎么让候选清单可追踪。Spring Boot 的 debug 模式会打印条件评估报告，第 8 节详细说。这里先给一个命令行参数，启动时加：

--debug

或者在 application.properties 里写：

debug=true

启动日志里就会出现一个名为“CONDITIONS EVALUATION REPORT”的大段输出，Positive matches 显示哪些自动配置生效，Negative matches 显示哪些没生效以及原因。排查自动装配问题，这个报告是最快的入口。

4. 自动装配的完整执行链路

4.1 AutoConfigurationImportSelector 是如何被激活的

自动装配的真正入口是 @EnableAutoConfiguration，而 @SpringBootApplication 里已经包含了这个注解。@EnableAutoConfiguration 通过 @Import 引入了 AutoConfigurationImportSelector，这是一个 ImportSelector 实现，作用是返回需要注册的配置类名数组。

和普通 ImportSelector 不同，AutoConfigurationImportSelector 还实现了 DeferredImportSelector。普通 ImportSelector 的结果会立即处理，而 DeferredImportSelector 的结果会推迟到所有配置类解析完成之后再处理。为什么必须这么做？因为自动配置经常需要根据项目里已有的 @Bean 做条件判断，如果执行太早，容器里还没有业务配置类注册完，@ConditionalOnMissingBean 的判断结果就会失真。推迟处理可以最大化地保证判断准确。

Spring Boot 还把 DeferredImportSelector 的返回结果做了分组，AutoConfigurationGroup 负责收集所有自动配置类，统一去重、排序、过滤，然后一次性注册。这一步是自动装配和普通配置类解析流程最不一样的环节。

4.2 读取候选清单与去重排序

AutoConfigurationImportSelector 的 getCandidateConfigurations 方法，会通过 ImportCandidates.load 读取 AutoConfiguration.imports 里的每一项。默认加载机制大致是：

ImportCandidates.load(AutoConfiguration.class, getClass().getClassLoader())

加载完成后，完整的装配流程可以拆成四步。第一步读取所有候选配置类名，可能来自多个 jar，所以候选清单很长；第二步通过 AutoConfigurationSorter 排序，排序依据是 @AutoConfigureOrder、@AutoConfigureBefore、@AutoConfigureAfter 注解；第三步去重，候选清单里可能出现同名类，比如同一个 Starter 被引入两次，必须确保一个全限定名只出现一次；第四步交给条件评估器做过滤，能通过 @Conditional 检查的配置类才会最终注册。

去重和排序这两步最容易被忽视。排序上有时候你会在日志里看到“The auto-configuration class X is annotated with @AutoConfigureAfter but a matching class Y could not be found”这类警告，它不致命，但说明配置类之间的顺序声明有一方不存在，可能引发后续 Bean 冲突。

4.3 条件装配阶段与缓存

候选配置类经过排序去重后，Spring Boot 会针对每个类执行条件评估。评估的核心组件是 ConditionEvaluator，它会把类上的 @Conditional 注解统一收集起来，逐个判断。

这里有个性能细节值得一提。Spring Boot 对条件判断是做了缓存的。同一个配置类可能被多个条件注解关注，而 AnnotationMetadata 和类是否存在这类结果，会在启动过程中被反复查询。Spring 内置的 MetadataReaderFactory 和 ConfigurationClassParser 都有缓存机制，避免同一个类重复做 ASM 元数据读取。如果你在自动配置类里用条件注解，条件本身不应该有复杂逻辑，因为每一次评估都发生在启动阶段，而且要遍历大量类，条件过重会拖慢启动速度。

整个自动装配阶段结束后，最终留下的配置类会被纳入 ConfigurationClassParser 的正常处理流程，解析 @Bean、@Import、@PropertySource 等注解，注册 BeanDefinition，等待后续实例化。自动装配机制到这里就闭环了：从候选到筛选、从排序到注册，全程框架自动完成。

5. 手写一个自定义 Starter（上）：结构与核心代码

5.1 为什么我建议拆成 autoconfigure 和 starter 两个模块

从工程规范上讲，Starter 推荐拆成两个 Maven 模块。一个模块叫 xxx-spring-boot-autoconfigure，放置自动配置类、属性类、条件注解；另一个模块叫 xxx-spring-boot-starter，它的 pom 里只依赖 autoconfigure 模块以及其他必须的业务依赖，源码可以是空的。

这样做的好处很直接：业务方如果只想用 autoconfigure 里的某些自动配置而不想引入完整 Starter，可以只依赖前者；而 Starter 作为面向使用者的门面，聚合了所有依赖，使用者只需要引入一个 starter，就能把该模块的可选依赖全部带进来。Starter 本质就是依赖聚合，这是它和普通 jar 最不一样的地方。

5.2 自动配置类改造示例

假设我们要做一个基于 Redis 的分布式锁 Starter，命名我用模拟项目名 hello-spring-boot-starter。先创建自动配置类 HelloLockAutoConfiguration：

package cn.demo.lock; import org.springframework.boot.autoconfigure.AutoConfiguration; import org.springframework.boot.autoconfigure.condition.ConditionalOnClass; import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean; import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty; import org.springframework.boot.context.properties.EnableConfigurationProperties; import org.springframework.context.annotation.Bean; @AutoConfiguration @ConditionalOnClass(RedisLockClient.class) @ConditionalOnProperty(prefix = "hello.lock", name = "enabled", havingValue = "true", matchIfMissing = true) @EnableConfigurationProperties(HelloLockProperties.class) public class HelloLockAutoConfiguration { @Bean @ConditionalOnMissingBean(RedisLockClient.class) public RedisLockClient redisLockClient(HelloLockProperties properties) { return new RedisLockClient(properties.getNamespace(), properties.getTimeout()); } }

注意几个关键点。@AutoConfiguration 注解在 Spring Boot 2.7 之后出现，本身包含了 @Configuration(proxyBeanMethods = false)，同时标记这个类在自动装配候选扫描时会被识别。@ConditionalOnClass 里的 RedisLockClient 是我们自己写的业务类，这个条件判断的是“当前项目里有没有引入 Redis 依赖导致这个类可用”。如果 Redis 相关类都不存在，条件就不满足，整个自动配置类不会加载。

属性类 HelloLockProperties：

package cn.demo.lock; import org.springframework.boot.context.properties.ConfigurationProperties; @ConfigurationProperties(prefix = "hello.lock") public class HelloLockProperties { private String namespace = "demo-lock"; private int timeout = 3000; // getter、setter 省略 }

通过 @EnableConfigurationProperties 注册属性类后，application.yml 里写 hello.lock.timeout 就能覆盖默认值。

5.3 自动配置清单文件怎么写

在 autoconfigure 模块的 src/main/resources/META-INF/spring/ 目录下新建文件 org.springframework.boot.autoconfigure.AutoConfiguration.imports，内容一行一个：

cn.demo.lock.HelloLockAutoConfiguration

这里不写属性类，因为属性类是通过 @EnableConfigurationProperties 注册的，不参与自动装配候选。写错文件路径是新手最容易踩的坑，路径少一个目录层级，启动日志不会直接报错，但你翻配置类时发现它根本没进候选清单。

starter 模块的 pom 只需要 agregator：依赖 hello-spring-boot-autoconfigure，以及某些配置为 optional 的依赖。optional 的作用是让使用者自行决定是否引入对应能力，如果你的自动配置类上有 @ConditionalOnClass 判断，optional 依赖配合条件注解就是标准搭法。

6. 手写一个自定义 Starter（下）：必须避开的雷区

6.1 自动配置类不要放在主启动类扫描路径下

这是个看起来反直觉、实际却非常常见的问题。Spring Boot 的 @SpringBootApplication 自带 @ComponentScan，扫描范围是启动类所在包及其子包。如果你的自动配置类恰好放在这个扫描路径下，会发生什么？它会被 @ComponentScan 当成普通 @Component 注册。

表面上项目能跑，但问题在于：自动配置类的注册时机和顺序被破坏了。它不再走条件评估那套机制，@ConditionalOnMissingBean 的判断结果就会出问题，因为你的自动配置类比业务 Bean 更早注册，导致业务 Bean 想覆盖自动配置 Bean 时发现已经被占位。正确的做法是把自动配置类放在独立的包路径下，远离业务扫描根。

更隐蔽的是测试场景。某个开发者在自己的模块里写了一个配置类，顺手放在主类旁边，本地启动完全没有问题，因为他的机器上 Redis 依赖齐全。发到同事环境里，同事的模块没有 Redis，条件注解理论上应该跳过配置，但由于配置类被 @ComponentScan 提前注册，容器尝试创建 Bean 时直接报连接失败。

6.2 条件注解和实际依赖不一致导致启动失败

写条件注解时，判断的类一定要和你的 @Bean 方法实际依赖保持一致。举个例子，你的 RedisLockClient 构造器需要 Jedis 类，条件上写的却是 Lettuce 类。结果项目里只有 Jedis 依赖，没有 Lettuce 依赖，条件判断为 false，自动配置类被跳过，使用者编译不报错，启动也“正常”，但功能完全不可用。这种问题排查起来，比报错难得多。

另一个方向是反向的不一致。条件注解写成宽松匹配，比如 @ConditionalOnClass(name = "redis.clients.jedis.Jedis")，实际依赖缺失时条件不满足，但如果你写的 @Bean 方法里用了 operator new RedisLockClient() 且构造器里引用了 Jedis，启动时类加载器发现找不到 Jedis，依然会抛 NoClassDefFoundError。条件只能帮你跳过装配逻辑，不能帮你阻止方法内代码对缺失类的加载。

6.3 spring.factories 的遗留文件别急着删

Spring Boot 2.7 兼容旧版 spring.factories，官方迁移建议是同时保留两种文件。如果团队项目里有老 Starter 使用 spring.factories，且框架版本在 2.7 到 3.0 之间，旧文件还能继续生效。升到 3.0 之后 spring.factories 不再支持自动装配，但 ApplicationListener、Initializer 这些键值仍然需要 spring.factories，二者并存没毛病。

我见过一个升级事故。项目从 Spring Boot 2.6 升级到 2.7，开发者把所有 spring.factories 里的配置类全部迁移到 AutoConfiguration.imports，但某中间件的旧版本 jar 还在 classpath 里，它自己的 auto-configuration 仍然通过旧文件注册。结果同一个类出现了两次，虽然 Spring 去重校验能兜住一部分，但日志里出现 warning，排查时虚惊一场。后来我们把旧 jar 的版本升级到支持新格式的版本，问题才彻底消失。处理升级时先确认依赖树，再动手改文件，顺序不能反。

7. 条件注解矩阵：用对比表格做一份速查手册

条件注解是整个自动装配里出镜率最高、也最容易混淆的一组注解。我整理了一个比较全的对照表，开发时可以直接查。

7.1 @ConditionalOnMissingBean 的深坑

这个注解值得单独讲，因为几乎所有自动配置都会用到它。理解它的关键在于“注册时间”。自动配置类经过 DeferredImportSelector 推迟处理，保证业务配置类先注册。如果业务项目里自己定义了 RedisLockClient，自动配置里的同名 @Bean 就会被 @ConditionalOnMissingBean 判定为 false，从而跳过。

但有些场景靠这个注解兜不住。比如业务项目里不是通过 @Bean 定义 RedisLockClient，而是用某个第三方 Starter 在更早阶段自动装配了一个，顺序就会变成未知数。Spring Boot 官方也明确建议：自动配置里的默认实现应尽量与业务自定义实现兼容，条件注解保证大多数场景正确，不能保证所有场景。

7.2 属性条件里的 matchIfMissing 用还是不用

@ConditionalOnProperty 里有属性 matchIfMissing，默认 false，表示“配置项不存在时条件不成立”。很多 Starter 作者习惯把 matchIfMissing 设为 true，让用户不做任何配置也能启用功能。这本身没问题，但要想清楚后果：某一天使用者确实不想启用这个功能，他必须显式写 hello.lock.enabled=false。如果忘了，功能就一直悄无声息地开着，这在安全敏感场景下很危险。

合理策略是，对“默认开”的功能用 matchIfMissing = true，对“默认关”的功能不设置，强制用户显式开启。不要一刀切。服务发现、消息订阅这类可能产生副作用的能力，建议默认关闭。

8. 自动装配失效问题排查实录

8.1 学会读 CONDITIONS EVALUATION REPORT

排查自动装配问题，第一个动作永远是看条件评估报告。启动命令加 debug=true，日志里会打印两个大块。Positive matches 是当前环境里成功匹配的自动配置类，Negative matches 是没匹配上的自动配置类和具体原因。

Negative matches 的输出非常详尽，比如：

RedisAutoConfiguration: Did not match: - @ConditionalOnClass did not find required class 'org.springframework.data.redis.core.RedisOperations'

看到这种输出，问题定位很快。需要注意，原因不同对应的处理方式也不同：类是确实不在 classpath 里，说明你缺依赖；类存在但没被加载，可能是依赖被 optional 或者类加载器隔离；条件本身是 @ConditionalOnProperty 且属性没配，直接去配置文件检查键名。

8.2 利用 actuator 的 conditions 端点做运行时诊断

如果项目已经启动完毕且引入了 actuator，可以用 /actuator/conditions 端点拉取同样的评估报告，不需要重启应用加 debug。这个端点返回 JSON 结构，里面的 positiveMatches、negativeMatches、exclusions 三个字段把当前应用的所有自动装配评估结果暴露得清清楚楚。

实际操作里，我排查某个同事反馈的配置不生效时，直接调这个接口，配合 grep 找到对应配置类，很快就发现是顺序问题而不是依赖问题。比翻日志高效得多。

8.3 案例：为什么我的 DataSource 自动配置没有生效

这是我的一个典型排查记录。某项目引入 spring-boot-starter-data-jpa，也配好了数据源信息，启动后却报“Table not found”，说明 JPA 的自动配置确实执行了，但 DataSource 相关 Bean 可能有问题。用 debug 模式看报告，发现 DataSourceAutoConfiguration 匹配了，但 DataSourcePoolMetadataProvidersConfiguration 里的连接池子条件没匹配上。

最终定位原因：项目里同时引入了 HikariCP 和 Commons DBCP2 两个连接池，条件注解匹配时选择了其中一个，而使用者以为自己配的是另一个。把 commons-dbcp2 从依赖中排除掉，问题消失。这类问题靠阅读源码很难发现，但条件评估报告一针见血。遇到自动装配相关故障，先看报告，再看依赖树，最后再读源码，这个顺序能省很多时间。

9. 一些实操心得：哪些习惯让我少踩坑

自动装配和 Starter 开发，试错成本不算高，但反复试错很浪费。这里分享几个长期养成的习惯。

写任何 Starter，第一件事不是写代码，而是把自动配置类注册文件建好。文件路径容易错，先建好文件，哪怕内容是空类全限定名，也能验证加载链路通不通。我习惯在自动配置类的构造器里临时加一行 System.out 日志验证加载，确认被调用后再删掉。虽然这种 log 不该出现在生产代码里，但调试阶段确实高效。

条件注解尽量精简。一个新自动配置类，能用 @ConditionalOnClass 和 @ConditionalOnMissingBean 解决的，就不要额外加 @ConditionalOnProperty。属性开关越多，使用者心智负担越大，排查时也更难定位。提供默认启用的能力，让使用者真的需要关闭时才显式配置，这一类 Starter 用起来最顺手。

调试自动装配还有一个简单工具，在启动类里临时加一个 ApplicationRunner，打印容器里的关键 Bean 存在性。比如判断某个 RedisLockClient 是否存在，直接注入 ApplicationContext 然后 getBean 看报不报错。这个做法比看日志更直接，尤其在条件评估报告过长、日志被刷屏的场景下。

还有一个容易被忽略的操作习惯：排查自动装配问题，让项目保持最小启动状态。把不相关的 Starter 临时注释掉，只保留最小依赖，启动速度会快非常多，配置类之间的干扰也会大幅降低。等定位到问题再逐步恢复依赖。我在公司内部排查一个多数据源配置冲突时，用这个方法十五分钟解决了问题，如果带着整个项目慢慢试，估计要折腾半天。

最后再讲一个和自动装配看似无关、实际关系很大的细节。写自动配置类时，不要把项目主代码里的工具类直接拿来用。自动配置类属于框架级别代码，应该保持高度独立。有一次我把一个业务工具类放进自动配置类里，后来业务模块重构，工具类删除，所有依赖这个 Starter 的服务启动全部报 ClassNotFound。从那以后，我的 Starter 模块里从来不依赖业务模块的代码，所有辅助类要么自己实现，要么从基础库中寻找。这在多团队协作的项目里尤为重要。

自动装配机制并不复杂，把它拆成“读文件、做条件判断、注册配置类”三步，就很容易建立整体认知。真正想出问题，往往是对条件注解理解不到位，或者对执行顺序没有概念。希望这篇梳理能帮你把这条链路彻底打通。