depends_on 默认仅控制容器启动顺序，不等待依赖服务就绪；需结合 healthcheck 和 condition: service_healthy 才能实现真正就绪等待。
在 Docker Compose 中，depends_on 可以声明服务间的依赖关系，但它**默认不等待依赖服务“就绪”**，只控制容器启动顺序（即先启动被依赖的服务）。要实现真正可靠的关联启动（比如应用等数据库 ready 后再启动），需结合健康检查（healthcheck）和 depends_on.condition 配置。
基础 depends_on：仅控制启动顺序
最简单的用法是让 service B 在 service A 启动后再启动：
services:
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: example
<p>app:
image: myapp:latest
depends_on:</p>
- db
⚠️ 注意：此时
app容器启动时，db容器虽已运行，但 PostgreSQL 可能尚未完成初始化（监听端口、接受连接），导致应用启动失败。
配合 healthcheck 实现“真正就绪”等待
为 db 添加健康检查，并在 app.depends_on 中指定等待条件：
services:
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: example
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
interval: 30s
timeout: 10s
retries: 5
start_period: 40s
<p>app:
image: myapp:latest
depends_on:
db:
condition: service_healthy
</p>
说明：
-
pg_isready是 PostgreSQL 自带的健康探测命令，比简单curl或telnet更准确（确认服务可响应 SQL 请求） -
start_period给数据库预留足够初始化时间（如加载扩展、恢复数据） -
condition: service_healthy表示app会等到db的健康状态变为healthy后才启动
进阶：多个依赖 + 不同等待条件
一个服务可依赖多个服务，且可混合使用不同条件：
app:
image: myapp:latest
depends_on:
db:
condition: service_healthy
redis:
condition: service_started # 只需容器启动，不强求 ready（如 Redis 启动即可用）
nginx:
condition: service_healthy
常用 condition 值：
-
service_started：容器已运行（默认行为，等价于depends_on: [x]） -
service_healthy：容器健康检查通过（需提前配置healthcheck） -
service_completed_successfully：适用于一次性任务容器（如数据迁移脚本）
补充建议：应用层仍需容错重试
即使 Compose 等待了健康状态，网络抖动或短暂不可用仍可能发生。推荐在应用代码中：
- 连接数据库时设置合理超时与重试逻辑（如指数退避）
- 避免启动时硬性阻塞，改用异步探活 + fallback 提示
- 对非关键依赖（如日志收集服务），可设为软依赖（不加
depends_on，靠应用内降级处理）
不复杂但容易忽略：健康检查必须真实反映服务可用性，否则 depends_on 就形同虚设。
