depends_on仅控制容器启动顺序，不保证服务就绪；需配合healthcheck与condition: service_healthy，并辅以应用层重试或等待脚本才能实现可靠依赖。
depends_on 是 Docker Compose 中最常用、也最容易被误解的依赖控制机制。它能控制启动顺序，但不能保证服务就绪——这是关键前提。
如果你只写 depends_on: -db，Docker 会等 db 容器进入 running 状态后才启动 app，但此时 MySQL 或 PostgreSQL 很可能还在初始化数据库、加载配置、监听端口，应用一连就报 Connection refused。
depends_on 的真实作用
- 它只是让 Docker Compose 按拓扑顺序调用
docker start - 不检查端口是否开放、进程是否响应、数据库是否可连接
- 不等待健康检查通过（除非你额外配置
condition） - 不跨 compose 文件生效，也不适用于
docker run
示例：
version: '3.8'
services:
db:
image: postgres:15
environment:
POSTGRES_DB: myapp
web:
build: .
depends_on:
- db
这个配置下，web 会在 db 容器启动后立刻启动，不等 pg_isready 成功。
如何让 depends_on 真正“管用”
要让它发挥实际价值，必须配合健康检查和 condition 字段：
services:
db:
image: postgres:15
environment:
POSTGRES_DB: myapp
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
web:
build: .
depends_on:
db:
condition: service_healthy # ← 关键！必须这样写
这样，web 只有在 db 通过全部健康检查后才会启动。
注意：
-
condition: service_healthy要求db先定义healthcheck -
condition: service_started等价于原始depends_on: -db，只是等容器启动 - 健康检查失败时，
docker-compose ps会显示Unhealthy，便于排查
为什么光靠 depends_on 不够？常见失败场景
- PostgreSQL 启动快，但首次初始化可能耗时 20 秒以上
- MySQL 8.0 默认启用
caching_sha2_password插件，客户端驱动未适配时连接卡住 - Redis 启动后需加载 RDB/AOF，期间拒绝新连接
- 自定义服务监听端口前还要读配置、建表、拉远程元数据
这些都不是容器“没启动”，而是服务没就绪——depends_on 对此完全无感。
更稳妥的补充手段（推荐组合使用）
当 service_healthy + depends_on 还不够稳（比如健康检查脚本本身有延迟），建议叠加以下任一方式：
-
在
web的entrypoint中加入等待逻辑：#!/bin/sh until pg_isready -h db -p 5432; do echo "Waiting for DB..." sleep 2 done exec "$@"
-
使用轻量工具如
wait-for-it.sh：web: build: . entrypoint: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"]
应用代码内实现连接重试（如 Python 的
tenacity、Go 的backoff），比编排层更灵活
这些不是替代 depends_on，而是补足它缺失的“就绪判断”能力。
不复杂但容易忽略：depends_on 只是起点，不是终点。真正可靠的依赖控制，是 健康检查 + condition + 应用层容错 三层协同的结果。
