Spring Boot依赖注入顺序由容器依依赖关系自动推导：存在依赖时，被依赖Bean优先初始化；构造器注入天然保障该顺序，@DependsOn慎用于隐式依赖，循环依赖必须规避。
Spring Boot 中依赖注入顺序不是靠“手动排先后”，而是由容器根据依赖关系自动推导出来的。只要存在明确的依赖链，Spring 就会天然保证被依赖的 Bean 先初始化、再注入——这是默认行为，不需要额外干预。
构造器注入是最自然的顺序控制方式
当一个 Bean 通过构造器参数依赖另一个 Bean 时，Spring 必须先创建被依赖的 Bean，才能完成当前 Bean 的实例化。比如：
- ServiceA 构造器中声明了 ServiceB 类型参数 → Spring 会先初始化 ServiceB，再初始化 ServiceA
- 这种写法清晰表达了强依赖，且能避免字段注入带来的空指针风险
- 注意：构造器里不宜放耗时逻辑，否则拖慢整个应用启动
@DependsOn 可显式声明初始化先后（慎用）
适用于两个 Bean 没有直接引用关系，但存在隐式依赖（如初始化脚本、配置预加载等）：
- @DependsOn("beanName") 写在类上，表示当前 Bean 必须在指定名字的 Bean 初始化之后才开始初始化
- 缺点是硬编码 bean 名称，重命名类或修改 @Component 值时容易遗漏，维护成本高
- 不推荐用于常规业务 Bean，更适合基础设施类（如数据源初始化器、全局监听器）
@PostConstruct 执行顺序需单独处理
@PostConstruct 方法是在 Bean 实例化和依赖注入完成后才执行的，它的顺序不等于 Bean 创建顺序：
- 若 A.init() 需要 B.init() 的结果，不能只靠 @Autowired，得加 @DependsOn("b") 或让 A 构造器注入 B
- @Order 注解对 @PostConstruct 有效：值小的优先执行，但仅限于同一生命周期阶段（如多个 @PostConstruct 方法之间）
- 更稳妥的做法是把初始化逻辑收敛到构造器或 InitializingBean.afterPropertiesSet() 中，便于统一控制
避免循环依赖是前提
所有顺序控制手段都建立在无循环依赖的基础上：
- 构造器注入一旦形成 A→B→A 链，启动直接失败
- Setter 或字段注入虽能绕过部分循环依赖（靠三级缓存），但属于设计缺陷，应重构拆解职责
- 使用 @Lazy 可延迟某一方的创建，缓解启动期冲突，但不解决根本问题
