在 Spring Boot 应用启动过程中，容器会按照一定的规则实例化并初始化各个 Bean。大多数情况下，依赖注入能够隐式地保证初始化顺序：如果一个 Bean A 通过构造器或属性注入了 Bean B，那么 B 一定会先于 A 完成初始化。但有些场景下，两个 Bean 之间并没有直接的注入关系，却存在初始化的先后依赖，比如一个 Bean 的初始化方法需要读取另一个 Bean 已经准备好的外部资源。此时，Spring 提供的 @DependsOn 注解就能派上用场。
@DependsOn 注解的作用与基本用法
@DependsOn 是 Spring 框架中的一个注解，它可以标注在类或方法上，用来强制指定当前 Bean 在初始化之前必须先初始化另外指定的一个或多个 Bean。这个注解并不会触发依赖注入，它只影响 Bean 的创建和初始化顺序。换句话说，即使当前 Bean 内部没有持有对目标 Bean 的引用，只要声明了 @DependsOn，Spring 容器就会保证目标 Bean 先被完整地初始化。
从源码层面来看，@DependsOn 注解的处理逻辑位于 AbstractBeanFactory 的 doGetBean 方法中。当容器创建某个 Bean 时，会先读取该 Bean 定义中记录的 dependsOn 列表，然后递归地创建这些被依赖的 Bean。如果被依赖的 Bean 又依赖其他 Bean，Spring 会继续递归处理，形成一个有向无环图。如果出现循环依赖，容器会抛出 BeanCreationException 异常。
最基本的用法是在配置类中使用 @Bean 方法或直接标注在组件类上。例如下面的代码演示了在 @Configuration 类中通过 @Bean 方法声明依赖：
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.DependsOn;
@Configuration
public class AppConfig {
@Bean
@DependsOn("dataSource")
public CacheManager cacheManager() {
// 假设 CacheManager 初始化时需要通过 DataSource 读取元数据
return new CacheManager();
}
@Bean
public DataSource dataSource() {
return new DataSource();
}
}
上面的配置中，cacheManager Bean 的初始化顺序被强制排在 dataSource 之后。即使 cacheManager 的构造函数或属性中并没有注入 dataSource，Spring 也会先创建并初始化 dataSource，然后再执行 cacheManager 的创建逻辑。
如果希望同时依赖多个 Bean，可以在注解的 value 属性中传入一个字符串数组，例如 @DependsOn({"beanA", "beanB"})。此时这些被依赖的 Bean 之间没有严格的顺序保证，但都会在当前 Bean 之前完成初始化。
在 Spring Boot 中使用 @DependsOn 的常见场景
Spring Boot 应用通常大量使用自动配置和组件扫描，@DependsOn 的使用频率相对较低，但在某些特殊场景下依然不可或缺。一个典型场景是数据库连接池与 Flyway 或 Liquibase 的集成：如果某个业务 Bean 的初始化方法需要立即访问数据库，而 Flyway 迁移脚本还未执行完成，就可能因为表不存在而失败。此时可以在业务 Bean 上标注 @DependsOn("flyway") 或 @DependsOn("flywayInitializer") 来保证迁移完成后再初始化。
另一个场景涉及文件系统或外部资源准备。例如一个 Bean 在初始化时需要读取本地临时目录下的配置文件，而另一个 Bean 负责在启动时下载并解压这些文件。这两个 Bean 之间没有任何注入关系，但初始化顺序却至关重要。通过 @DependsOn 可以清晰地表达这种非注入型的依赖。
下面是直接在组件类上使用 @DependsOn 的示例。假设有一个 FileLoader 负责下载资源，另一个 ConfigReader 需要在这些资源就绪后才能读取配置：
import org.springframework.context.annotation.DependsOn;
import org.springframework.stereotype.Component;
@Component
@DependsOn("fileLoader")
public class ConfigReader {
public ConfigReader() {
// 此时 fileLoader 已经完成初始化，临时文件已就绪
loadConfigFromFile();
}
private void loadConfigFromFile() {
// 读取本地配置文件的逻辑
}
}
需要注意的是，@DependsOn 作用于 @Component 注解的类上时，必需在 Spring 扫描该组件时才能生效。如果 Bean 是通过 @Bean 方法定义的，则更推荐将 @DependsOn 放在 @Bean 方法上，这样意图更明确，也便于统一管理。
此外，Spring Boot 还允许在 @Configuration 类上使用 @DependsOn。不过这种用法较少见，因为配置类本身的初始化顺序通常不影响内部定义的 Bean 创建顺序。配置类上的 @DependsOn 只会影响配置类本身的实例化时机，而无法传递给其中定义的 Bean。因此不要误以为把 @DependsOn 放在配置类上就能控制所有 @Bean 方法的顺序。
@DependsOn 与 @Lazy、@Conditional 等注解的交互
在实际项目中，@DependsOn 往往会和其他注解一起使用，理解它们之间的交互有助于避免一些隐蔽的问题。首先是 @Lazy 注解。如果一个 Bean 标注了 @Lazy，那么它不会在容器启动时初始化，而是在第一次被请求时才创建。但 @DependsOn 声明的依赖关系并不受 @Lazy 影响：被依赖的 Bean 仍然会在依赖它的 Bean 创建之前被初始化，哪怕这个 Bean 本身是懒加载的。例如，lazyBean 标注了 @Lazy 并 @DependsOn("eagerBean")，当 lazyBean 第一次被获取时，Spring 会先初始化 eagerBean，然后再创建 lazyBean。如果 eagerBean 本身也是懒加载的，则它会在此时被立即初始化，行为与常规的非懒 Bean 一致。
其次是 @Conditional 注解。如果一个被依赖的 Bean 不满足条件而没有注册到容器中，那么依赖它的 Bean 在启动时就会抛出 NoSuchBeanDefinitionException 或 BeanCreationException。这提醒我们在使用 @DependsOn 时，必须确保被依赖的 Bean 一定会被注册，否则需要结合条件判断进行规避。例如可以同时使用 @ConditionalOnBean 注解来保证依赖的 Bean 存在时才创建当前 Bean，但这属于间接控制，需要额外设计。
还有一个容易混淆的点是 @DependsOn 与构造器注入的区别。构造器注入天然保证了依赖顺序，但前提是存在直接的引用关系。@DependsOn 则适用于那些没有引用关系、但初始化过程有先后顺序要求的场景。两者可以同时使用，但会造成冗余的依赖声明，一般建议二选一：能用注入表达就用注入，不能则考虑 @DependsOn。
实战案例：解决缓存与数据库初始化顺序问题
设想一个 Spring Boot 应用，其中有一个 CacheWarmUp 组件在启动时需要立即从数据库表中加载一些常用数据到内存缓存中。而数据库表的创建是由 Flyway 执行的，Flyway 在 Spring Boot 中的自动配置会在 DataSource 初始化之后、应用程序完全准备好之前运行迁移脚本。如果 CacheWarmUp 在 Flyway 迁移之前执行，就会因为表不存在而失败。
解决方案就是让 CacheWarmUp 依赖 Flyway 的初始化 Bean。Spring Boot 自动配置中，Flyway 的核心 Bean 名称通常是 flyway（对应 Flyway 实例）或 flywayInitializer（对应执行迁移的初始化器，名称可能因版本而异）。最稳妥的方式是显式声明依赖 Bean 的名称，例如下面的配置：
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.DependsOn;
@Configuration
public class CacheConfig {
@Bean
@DependsOn("flywayInitializer")
public CacheWarmUp cacheWarmUp() {
// 此时数据库表已经由 Flyway 创建完成
return new CacheWarmUp();
}
}
如果使用的是 Spring Boot 2.x 且自定义了 Flyway 配置，可能还需要通过 @DependsOn("flyway") 来依赖 Flyway 实例本身。建议在编写依赖名称时，先确认容器中实际注册的 Bean 名称，可以通过启用 Spring Boot Actuator 的 /beans 端点或在启动日志中查看。
这种显式的依赖声明虽然解决了顺序问题，但也引入了一个潜在风险：如果将来升级 Spring Boot 版本导致 Flyway 初始化 Bean 的名称发生变化，应用会直接启动失败。因此更稳健的做法是尽量通过属性注入或构造器参数传递 Flyway 实例，让依赖关系变得显式化。例如在 CacheWarmUp 的构造函数中接收一个 Flyway 参数，Spring 会自然地保证 Flyway 先被创建。但这种方法要求 CacheWarmUp 确实需要 Flyway 对象，如果仅仅是为了顺序而添加无用的引用，代码可读性会下降。
综上所述，@DependsOn 是 Spring 提供的一个轻量级顺序控制工具，它没有改变 Bean 的生命周期，只是在创建流程中增加了一个前置检查。在 Spring Boot 项目中，我们可以把它用在那些难以通过常规依赖注入表达顺序的地方，但同时也要谨慎处理 Bean 名称的稳定性和条件注册的兼容性，避免引入新的维护负担。
Spring Boot@DependsOnBean初始化顺序修改时间：2026-08-25 19:59:09