在 Spring Boot 应用程序里，配置类就像厨房里的菜谱——你可能有多个菜谱同时存在，但如果你不告诉厨师先做哪道菜、后做哪道菜，最后端上来的可能就是一锅乱炖！Spring Boot 虽然聪明，会自动扫描并加载所有带 @Configuration 的类，但它默认并不保证这些配置类的加载顺序。
这在大多数情况下没问题，可一旦你的某个配置依赖另一个配置的 Bean，顺序就变得至关重要。
今天，我们就来彻底搞懂：Spring Boot 到底是怎么决定配置加载顺序的？开发者又该如何精准控制它？从 @Order、@DependsOn 到自动配置专用的 @AutoConfigureAfter，你掌握这套“启动时序控制术”。
首先，得搞清楚什么是配置类。
在 Spring 世界里，配置类分两种：
一种是“完整配置类”，用 @Configuration 标注；另一种是“精简配置类”，比如用 @Component、@Import，或者哪怕只写了一个 @Bean 方法，Spring 也会把它当作配置来处理。它们都会被 Spring 的 ConfigurationClassPostProcessor 在启动阶段扫描、解析元数据，并注册成 Bean 定义。
但关键来了：Spring 默认加载这些类时，顺序完全取决于类路径（classpath）里的排列——这就像你把一堆文件扔进抽屉，下次拿出来时顺序是随机的。
所以，如果你的 ConfigB 依赖 ConfigA 里的某个 Bean，而 ConfigB 恰好先被加载，那程序就可能崩！
举个最简单的例子：ConfigA 定义了 beanA，ConfigB 定义了 beanB，两者互不相干。这时候无论谁先谁后，Spring 都能正常注册两个 Bean。我们写个测试验证一下——用 @SpringBootTest 启动上下文，然后断言两个 Bean 都存在。
结果？稳得很！但这只是理想情况。现实中，配置之间往往有依赖关系。比如，数据源配置必须在服务层配置之前完成，否则服务一启动就报“找不到数据源”！
那怎么办？第一个武器来了：@Order 注解。
你可能以为 @Order 是给 Bean 排序的，其实它排的是“配置类的处理优先级”。数值越小，越早被处理：比如 ConfigOne 标 @Order(1)，ConfigTwo 标 @Order(2)，那 Spring 就会先处理 ConfigOne。
注意：这个顺序影响的是“配置类被解析和注册的时机”，不是 Bean 实例化的顺序。但如果 ConfigTwo 里用到了 ConfigOne 定义的 Bean，那提前加载 ConfigOne 就能避免“Bean not found”错误。
我们写个测试，故意在测试类里先写 ConfigTwo.class，再写 ConfigOne.class，结果发现 Spring 还是尊重 @Order，先加载了 ConfigOne——这说明注解的优先级高于声明顺序！
但 @Order 有个局限：它只在同类配置之间有效，比如都是普通用户定义的 @Configuration 类。
一旦你进入 Spring Boot 的自动配置领域（也就是那些 spring.factories 里声明的 AutoConfiguration），@Order 就不管用了！这时候就得换装备：@AutoConfigureOrder、@AutoConfigureAfter 和 @AutoConfigureBefore。
这三个是 Spring Boot 专门为自动配置设计的“排序三剑客”。
比如你写了一个 FirstAutoConfig，希望另一个 SecondAutoConfig 必须在它之后加载，那就给 SecondAutoConfig 加上 @AutoConfigureAfter(FirstAutoConfig.class)。这样，无论类路径怎么排，Spring Boot 都会确保顺序正确。我们同样用单元测试验证：即使测试里先声明 SecondAutoConfig，最终 Bean 依然按注解顺序加载成功。
不过，有时候你不需要控制整个配置类的顺序，而只想让某个 Bean 在另一个 Bean 之后创建。
这时候，终极精准武器登场：@DependsOn。它直接作用在 @Bean 方法上，告诉 Spring：“创建我之前，必须先把 xxx Bean 初始化好”。比如 firstBean 返回 "FirstBean"，secondBean 上加 @DependsOn("firstBean")，那 Spring 就会严格保证 firstBean 先实例化。这种依赖关系比配置类排序更细粒度，也更可靠——因为它不依赖配置加载顺序，而是直接绑定到 Bean 生命周期。
说到这里，你可能会问：那我到底该用哪个？
简单总结：
- 如果是普通配置类之间的顺序，用 @Order；
- 如果是自动配置之间的顺序，用 @AutoConfigureAfter 等；
- 如果只是两个 Bean 有依赖，直接上 @DependsOn。
三者各司其职，千万别混用。
值得一提的是，这些机制背后反映的是 Spring Boot 对“可预测性”的极致追求。作为开发者，我们不能依赖“碰巧能跑”的代码，而要写出无论部署到哪个环境、无论类加载顺序如何，都能稳定启动的应用。尤其是在微服务架构下，一个模块的配置可能被多个服务复用，顺序控制就更关键了。
最后再强调一遍：Spring Boot 的默认行为是“无序加载”，这在简单项目中没问题，但在复杂系统中就是隐患。学会用 @Order、@DependsOn 和自动配置排序注解，等于给你的应用启动过程装上了“导航系统”，再也不怕“Bean not found”或“初始化失败”的半夜报警！