spring bean 加载顺序默认由依赖关系决定，手动干预方式包括：①@dependson 声明隐式初始化依赖；②构造器注入保障天然依赖顺序；③@order 控制集合注入或扩展点执行序；④commandlinerunner/applicationrunner 在容器就绪后调度任务。
Spring 默认按依赖关系自动决定 Bean 加载顺序——谁被谁用，谁就先加载。但当没有直接引用（比如字段注入）、却存在隐式依赖（如数据库建表必须早于数据导入），或需要控制同类型多个 Bean 的执行次序时，就得手动干预。关键不是“谁先扫描到”，而是“谁必须等谁完成”。
@DependsOn：最直白的显式依赖声明
适用于 A Bean 不持有 B 的引用，但逻辑上必须等 B 初始化完才能启动。
- 在目标 Bean 类上加 @DependsOn("beanName")，括号里填被依赖 Bean 的名称（注意大小写）
- 被依赖的 Bean 必须有明确的 bean 名称，比如用 @Component("databaseInitializer") 或 @Bean(name = "databaseInitializer")
- 支持多个，写成 @DependsOn({"beanA", "beanB"})
- 它不改变 Bean 创建时机，只强制初始化阶段的先后顺序
构造器注入：依赖即顺序，天然可靠
如果 A 真正需要 B 才能工作，就把 B 声明为 A 构造函数的参数。
- Spring 会自动分析依赖图，在创建 A 前确保 B 已完全实例化并完成所有初始化（包括 @PostConstruct）
- 这是最符合 Spring 设计哲学的方式，无需额外注解，也最易测试和维护
- 避免在字段上用 @Autowired + @Lazy 混搭，容易掩盖真实依赖
@Order 与集合注入：仅对特定场景有效
@Order 不控制单个 Bean 的加载顺序，但它能影响以下两类行为：
- 多个相同接口实现类注入到 List 或数组时：Spring 按 @Order 值升序排列这些 Bean，值越小越靠前
- BeanPostProcessor、Aware 接口实现类、切面（@Aspect）等扩展点的执行优先级
- 不要把它加在普通 @Component 类或 @Bean 方法上——实测无效
- 若需排序 List
，就在每个 Handler 实现类上加 @Order(1)、@Order(2) 等
CommandLineRunner / ApplicationRunner：容器就绪后的统一调度点
适合做启动后一次性任务，比如缓存预热、MQ 订阅、数据校验等。
- 它们在所有单例 Bean 初始化完毕、上下文刷新完成后才执行
- 多个 Runner 可通过实现 Ordered 接口 或加 @Order 注解来控制执行顺序
- 比 @PostConstruct 更安全，因为此时整个容器已稳定，可放心调用任意其他 Bean
- 注意：run() 方法抛异常会导致应用启动失败，建议自行捕获处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
