核心思路是将初始化顺序问题转化为服务就绪状态对齐，通过@DependsOn声明依赖、就绪探针检测、ApplicationRunner分层执行及分布式选主机制实现状态驱动的可靠启动。
核心思路不是“强行排序”，而是让依赖关系可声明、可感知、可等待——初始化顺序问题本质是服务就绪状态未对齐，而非类加载时间点之争。
用 @DependsOn 显式声明 Bean 级依赖
当多个关键组件存在强先后关系（如缓存预热服务必须等配置中心客户端就绪后才执行），直接在 Bean 定义处标注依赖目标名称：
- @DependsOn("configClient") 确保 configClient Bean 完全初始化后再创建当前 Bean
- 支持数组写法：@DependsOn({"redisTemplate", "dataSource"})，满足多前置条件
- 注意：它只控制初始化时机，不解决运行时连接可用性；若 configClient 初始化成功但尚未拉取到配置，仍需配合后续健康检查
将“就绪判断”下沉到服务内部，而非仅靠加载顺序
数据库连接池、Redis 客户端、消息队列生产者等中间件，在 Bean 初始化完成后往往还需完成连接建立、集群发现、权限认证等步骤。此时仅靠 @DependsOn 不够，应封装“就绪探针”：
- 提供 isReady() 方法，内部检测连接是否活跃、配置是否加载完毕、心跳是否正常
- 在依赖方的 @PostConstruct 或 InitializingBean.afterPropertiesSet() 中轮询该方法，超时抛异常
- 例如：CachePreloader.init() 内部 while(!configClient.isReady()) { Thread.sleep(100); }
借助 Spring Boot 的 ApplicationRunner / CommandLineRunner 分层执行
把初始化动作从“Bean 创建阶段”后移到“容器启动完成但应用尚未对外提供服务”的窗口期，天然规避多数加载竞争：
- 实现 ApplicationRunner 接口，重写 run(ApplicationArguments args) 方法
- 配合 @Order(100) 控制多个 Runner 的执行次序，数字越小越早执行
- 适合执行耗时操作（如批量缓存预热、索引重建），且能统一捕获异常、记录日志、触发告警
- 比 @PostConstruct 更灵活，支持参数注入、异步调度、失败重试等扩展
分布式场景下加一道“选主+单例执行”保护
在多实例部署中，配置加载、数据校验、定时任务注册等操作只需一个节点执行。避免依赖顺序，转而依赖协调机制：
- 集成 Redis 或 ZooKeeper 实现分布式锁，抢到锁的实例才执行初始化逻辑
- 使用 Spring Cloud Context 的 ContextRefresher 主动刷新配置，替代启动时硬依赖
- 通过事件驱动：发布 ConfigLoadedEvent，监听方按需响应，解耦执行时机与加载顺序
不复杂但容易忽略：真正影响启动稳定性的，往往不是哪个类先 new 出来，而是哪个服务的 TCP 连接通了、哪个配置项生效了、哪个远程调用返回了 200。把“顺序”思维切换成“状态驱动”，才能在复杂分布式环境中稳住启动链路。
