depends_on仅控制启动顺序，不保证服务就绪；必须配合healthcheck和condition: service_healthy才能实现真正就绪等待，多级依赖需逐层配置健康检查与condition，应用层还应补充重试机制。
depends_on 本身不保证服务“就绪”，只控制启动顺序；真正实现“完美控制启动时序”，必须配合 condition（如 service_healthy）和容器内健康检查（healthcheck），缺一不可。
depends_on 的真实作用：仅控制 docker start 顺序
它让 Docker Compose 按声明顺序调用 docker start，但不会等待目标容器里的进程真正可用。例如：
- 数据库容器可能已启动（
docker ps显示 Up），但 PostgreSQL 还在初始化、监听端口未就绪； - Redis 容器刚起来，但
redis-server还没完成加载 RDB 或 AOF； - 此时上游服务（如 API 服务）若直接连接，大概率报 “Connection refused” 或超时。
condition 是关键：把“启动完成”升级为“服务就绪”
只有设为 condition: service_healthy，Docker Compose 才会等待目标服务通过其 healthcheck 成功后，才启动依赖方。配置示例如下：
services:
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d myapp"]
interval: 30s
timeout: 10s
retries: 5
start_period: 40s
api:
build: ./api
depends_on:
db:
condition: service_healthy
注意：start_period 给 PostgreSQL 预留足够初始化时间（如加载扩展、恢复 WAL），避免健康检查过早失败。
多级依赖需逐层定义健康检查与 condition
例如：API → DB、API → Redis、Redis → Config Server（Consul），不能只配一级。正确做法是：
- 每个被依赖服务（db、redis、consul）都必须声明
healthcheck，且检查逻辑真实反映业务可用性（如连通性 + 关键端点响应）； - 每层依赖方显式使用
depends_on: {service: {condition: service_healthy}}，不要省略condition； - 避免循环依赖（如 A → B 且 B → A），Compose 会报错；若存在间接依赖（A→B→C），A 不必再写
depends_on: c，只要 B 健康了，C 一定已就绪（前提是 B 的 healthcheck 包含对 C 的探测或 B 启动逻辑已隐含 C 可用）。
进阶建议：补充应用层容错，不全依赖 Compose
Docker Compose 的健康检查是强辅助，不是银弹。生产中建议：
- 应用自身实现连接重试（如 Spring Boot 的
@Retryable或 HikariCP 的connection-test-query）； - 对非关键依赖（如日志收集器、消息队列），可设
condition: service_started降低启动阻塞风险； - 用
docker-compose up --wait（v2.20+）确保所有service_healthy检查通过后再返回，适合 CI/CD 脚本判断部署是否成功。
