spring boot 不管理服务间依赖启动顺序，连接超时根源是依赖服务未就绪；depends_on 仅保证容器启动而非服务可用；应通过健康检查、合理超时配置及懒加载异步初始化解决。
spring boot 本身不直接管理“服务间依赖启动顺序”，它只负责单体应用内部 bean 的加载顺序。你遇到的“连接超时”，比如连不上 redis、mysql 或其他微服务，**表面是超时，根源往往是依赖服务还没真正就绪，而你的 spring boot 应用已急着去连**。解决的关键不是让 spring boot “等”另一个容器，而是把“等待逻辑”做对、做稳。
明确 depends_on 只管容器启动，不管服务就绪
Docker Compose 中的 depends_on 只确保目标容器进程已 启动（即 docker ps 能看到），但完全不保证其内部服务（如 Redis 监听端口、MySQL 完成初始化）已可响应请求。这是最常被误解的一点。如果你只写了 depends_on: [redis]，Spring Boot 启动后立刻尝试 connect 6379，而 Redis 还在加载 RDB 或做 AOF 重放，就会报 Connection timed out。
让 Spring Boot 主动健康检查，而不是盲目等待
别依赖外部机制“喂时间”，让应用自己判断依赖是否可用：
- 用 Spring Boot Actuator + Health Indicator 自定义一个 Redis 健康检查器，检查
PING或INFO命令是否成功返回； - 配合 @ConditionalOnHealth（或手动在
@PostConstruct中轮询）延迟关键 Bean 初始化，直到健康检查通过； - 避免在
@Bean方法里直接 new RedisTemplate 并调用 connect() —— 这会让容器启动卡死在构造阶段。
配置层必须设好连接与读取超时
超时不是“加长等待”，而是防止无限阻塞。不同环节要分别设：
-
数据库连接池（HikariCP）：
spring.datasource.hikari.connection-timeout=5000（获取连接最多等 5 秒）； -
Redis 客户端（Lettuce）：
spring.redis.timeout=3000（命令级超时）； -
HTTP 调用（RestTemplate / WebClient）：显式配置
connectTimeout和readTimeout，不要依赖默认值； -
Web 容器（Tomcat）：
server.tomcat.connection-timeout=10000防止慢请求长期占线程。
启动流程加一层“懒加载 + 异步初始化”兜底
对非核心、强依赖外部服务的模块，启用懒加载和异步初始化能大幅降低启动失败概率：
- 在
application.properties加：spring.main.lazy-initialization=true，让大部分 Bean 推迟到首次使用才初始化； - 把耗时的远程连接逻辑（如初始化 Feign Client、预热缓存）放到
@EventListener(ApplicationReadyEvent.class)或单独线程中执行； - 这样即使 Redis 晚 8 秒起来，应用也能先启动成功，后续第一个请求再触发连接，不会导致整个部署失败。
