depends_on仅确保容器运行，不保证服务就绪；需配合healthcheck、condition: service_healthy、应用层重试及init容器等机制实现真正就绪等待。

docker compose 的 depends_on 看似能控制服务启动先后，但实际只管“容器是否 running”，不管“应用有没有准备好”。真正影响系统稳定性的，是服务就绪（ready）而非启动（started）。理解这个区别，才能避开 90% 的依赖失败问题。

depends_on 的真实行为：只排队，不等待

Compose 启动时会解析所有服务的依赖关系，构建一个有向无环图（DAG），再按拓扑排序依次调用 docker run。这个过程发生在容器生命周期的“创建→运行”阶段，仅检查目标容器是否进入 Running 状态。

• 数据库容器启动成功 ≠ PostgreSQL 已监听 5432 端口
• Redis 容器 running ≠ redis-server 已完成配置加载并接受连接
• Web 服务在 db 容器 start 后立即启动，但首次 DB 连接大概率失败

健康检查（healthcheck）：让就绪状态可被识别

仅靠 depends_on 不够，必须配合 healthcheck 让 Compose “看懂”服务是否真正可用。PostgreSQL、MySQL、Redis 等官方镜像都支持标准健康探针。

• 为 db 添加健康检查：pg_isready -U postgres 或 mysqladmin ping -h localhost -u root --password=xxx
• 设置合理参数：interval（建议 10s）、timeout（≤5s）、retries（≥3），避免过早判定失败
• 在依赖方使用 condition: service_healthy，例如：

  depends_on:
    db:
      condition: service_healthy

应用层容错：重试 + 等待脚本双保险

即使 Compose 层做了健康等待，网络抖动或初始化延迟仍可能导致首连失败。应用自身必须具备弹性。

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

• 在应用启动入口前插入 wait-for-it.sh db:5432 --timeout=60 --strict -- python app.py
• Python 应用内使用 tenacity 库实现带退避策略的 DB 连接重试
• Node.js 可用 wait-on 或自定义 await waitForPort(5432, 'db')

进阶方案：init 容器与启动协调服务

对高一致性要求的场景（如金融类微服务），可引入更可控的启动编排逻辑。

• 用轻量 init 容器执行预检：验证下游服务端口、API 响应、DB schema 是否就位
• 基于 Consul 或 Etcd 构建启动协调服务，各服务注册就绪状态，由中心节点统一放行
• 使用 Docker Compose v2.23+ 的 profiles + 自定义 entrypoint 分阶段启动