@DependsOn用于强制指定Bean初始化顺序，确保被依赖Bean完成整个生命周期后依赖方才初始化；适用于隐式依赖、配置类/监听器/数据源初始化器等需前置就绪的场景。
@DependsOn 是 Spring 提供的显式声明依赖关系的注解，用于**强制指定某个 Bean 在另一个 Bean 之前初始化**。它不改变 Spring 容器中 Bean 的创建顺序本身（如构造函数、@PostConstruct 等生命周期阶段仍按常规执行），而是确保被依赖的 Bean 已完成初始化（即走完完整生命周期）后，依赖方才开始初始化。
什么时候需要用 @DependsOn？
当两个 Bean 之间存在隐式依赖（比如一个 Bean 的 @PostConstruct 方法里要操作另一个 Bean，但它们没有通过构造器/Setter/字段注入建立直接引用），或者需要确保某 Bean（如配置类、监听器、数据源初始化器）先就绪，再让其他 Bean 启动时，就适合用 @DependsOn。
常见场景包括：
- 自定义事件发布器依赖于某个消息总线 Bean 初始化完毕
- 缓存预热逻辑依赖 RedisTemplate 已连接成功
- 数据库 schema 初始化器必须在 JPA EntityManagerFactory 创建前运行
- 某些第三方 SDK 要求特定 Bean 先启动（如 Dubbo 的 RegistryConfig）
基本用法：单个和多个依赖
在目标 Bean 的类或@Bean方法上标注 @DependsOn，传入依赖 Bean 的名称（即 beanName）：
立即学习“Java免费学习笔记（深入）”；
@Component
@DependsOn("redisTemplate") // 确保 redisTemplate 先初始化
public class CachePreloader {
@PostConstruct
public void init() {
// 此时 redisTemplate 已 ready，可安全调用
}
}
支持多个依赖，按数组形式写：
@Component
@DependsOn({"dataSource", "redisTemplate", "configLoader"})
public class ApplicationInitializer { ... }
注意：beanName 默认是类名首字母小写（如 RedisTemplate → redisTemplate），也可用 @Bean(name = "xxx") 显式指定。
和 @Order、@Priority 的区别
@DependsOn 控制的是「初始化时机」，不是「排序优先级」：
- @Order 和 @Priority 主要用在实现相同接口的多个 Bean 排序（如多个 Handler、Filter、Advice），影响的是它们在集合中的执行顺序，不控制创建/初始化先后
- @DependsOn 是跨 Bean 的强依赖约束，Spring 会把它加入内部依赖图，在刷新容器时做拓扑排序，确保依赖链满足
- 二者可共存：比如多个 Filter 用 @Order 排执行顺序，其中某个 Filter 又用 @DependsOn 确保它依赖的配置服务已加载
注意事项和避坑点
使用 @DependsOn 需留意以下几点：
- 不能形成循环依赖，否则启动时报
BeanCreationException: Circular depends-on relationship - 只保证「初始化完成」，不保证「完全可用」——比如依赖的 Bean 虽已完成 @PostConstruct，但其内部异步任务可能还在跑
- 对 prototype 或其他作用域的 Bean 不起作用（@DependsOn 仅对 singleton 有效）
- 慎用于 @Configuration 类：若 A @Configuration 依赖 B @Configuration，B 中定义的 Bean 才能被 A 使用；但更推荐拆分配置类或用 @Import
- 替代方案考虑：优先用构造器注入建立真实依赖；若不行，再用 @DependsOn —— 它是“不得已而为之”的显式手段
