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，例如：
db:
condition: service_healthy
应用层容错：重试 + 等待脚本双保险
即使 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 分阶段启动
