Docker Compose服务启动超时本质是依赖服务“已启动”但“未就绪”，depends_on仅判断容器running状态，不验证端口监听、数据库可连或健康接口返回OK；须组合声明式依赖、主动探测（如wait-for）、健康检查（含start_period）及应用层优化（懒加载、连接池配置）来解决。
服务启动超时被中断，本质是依赖服务“已启动”但“未就绪”，而编排工具误判为可用。docker compose 的 depends_on 只管容器进程是否 running，不检查应用端口是否监听、数据库是否可连、健康接口是否返回 ok。要真正解决，得组合使用声明式依赖 + 主动就绪探测 + 启动容错策略。
用 wait-for 机制替代单纯 depends_on
在依赖服务真正就绪前，阻塞上游服务启动。推荐轻量方案：
- 在 web 或 app 服务的启动命令前加
./wait-for db:5432 --（需提前把wait-for脚本 COPY 进镜像） - 或使用官方推荐的
docker-compose-wait工具，支持超时、重试、自定义检测命令（如curl -f http://config:8888/actuator/health） - 避免写死 IP 或 localhost：容器内应通过服务名（如
db）访问，确保 DNS 解析正常
给关键服务配健康检查 + start_period
让 Docker 知道“刚启动≠能干活”，主动宽限初始化时间：
- 数据库服务中显式定义：
healthcheck:<br> test: ["CMD-SHELL", "pg_isready -U postgres -d mydb"]<br> interval: 30s<br> timeout: 10s<br> start_period: 90s<br> retries: 5
-
start_period是重点：它告诉 Docker，在容器启动后的前 90 秒内，健康检查失败不算异常，避免因初始化慢被 kill - Spring Boot 应用同理，暴露
/actuator/health并排除数据库等外部依赖项
调整应用层启动行为，减少阻塞点
很多超时其实源于应用自身卡在同步初始化上：
- 启用 Spring Boot 懒加载：
spring.main.lazy-initialization=true，跳过非必需 Bean 的启动期加载 - 数据库连接池设合理初始大小（如 HikariCP 的
connection-init-sql和minimum-idle=1），避免首次请求才建连 - 远程配置（如 Nacos、Apollo）设置连接超时与失败降级策略，不因配置中心抖动拖垮整个启动流程
日志与线程快照辅助定位卡点
当超时反复发生，别只看“timeout”，要确认卡在哪一步：
- 进容器执行
ps aux | grep java看主进程是否存活；若已 exit，说明启动失败而非超时 - 若进程仍在，立即执行
jstack $(jps | grep Application | awk '{print $1}')抓线程堆栈 - 重点关注
WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject或BLOCKED on java.net.PlainSocketImpl类型线程——它们往往指向数据库连接池耗尽、ZooKeeper 会话未建立、HTTP 客户端阻塞等真实瓶颈
