最推荐的做法是在依赖服务中配置 healthcheck，并在 depends_on 中使用 condition: service_healthy 条件，这样能确保依赖服务真正就绪后再启动上游服务，适合数据库、缓存等有初始化过程的服务场景。
先说结论：depends_on 默认只控制容器启动顺序，不等待服务内部进程就绪，要实现真正的依赖等待必须配合健康检查使用。
- 适合：多容器应用中有明确依赖关系的场景，如应用等待数据库、缓存服务
- 先准备：为依赖服务配置 healthcheck 健康检查命令
- 验收：通过 docker compose ps 确认服务健康状态后再验证应用连接
命令速用版
查看服务健康状态的命令：
docker compose ps
查看具体服务健康检查日志：
docker inspect <容器名> | grep -A 20 Health
快速重启并观察启动顺序：
docker compose down && docker compose up -d
为什么会这样
很多开发者第一次用 depends_on 时会以为设置了依赖就能保证服务可用，但实际不是这样。depends_on 的设计初衷是控制容器的启动和关闭顺序，它只确保被依赖的容器先启动，但不会等待容器内的服务进程完成初始化。
举个例子，PostgreSQL 容器启动后，还需要时间完成数据目录初始化、监听端口绑定、接受连接等步骤。如果应用容器在这期间尝试连接数据库，就会遇到连接拒绝错误。这就是为什么很多人配置了 depends_on 但应用还是启动失败的原因。
要解决这个问题，需要让 Compose 知道服务什么时候才算真正就绪，这就是 healthcheck 的作用。健康检查会定期执行一个命令来探测服务状态，当检查通过后服务状态变为 healthy，此时 depends_on 的 condition: service_healthy 条件才会满足。
分步处理
第一步：为依赖服务添加健康检查
以 PostgreSQL 为例，在 docker-compose.yml 中为 db 服务配置 healthcheck：
services:db:image: postgres:15environment:POSTGRES_PASSWORD: examplehealthcheck:test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]interval: 30stimeout: 10sretries: 5start_period: 40s
这里 pg_isready 是 PostgreSQL 自带的健康探测命令，比简单的端口检测更准确，因为它确认服务可以响应 SQL 请求。start_period 给数据库预留了初始化时间，避免刚启动时健康检查就失败。
第二步：在依赖服务中使用 condition 条件
在 app 服务的 depends_on 中指定等待条件：
services:app:image: myapp:latestdepends_on:db:condition: service_healthy
这样配置后，app 容器会等到 db 的健康状态变为 healthy 后才启动。
第三步：处理多个依赖的情况
一个服务可以依赖多个服务，且可以混合使用不同条件：
services:app:image: myapp:latestdepends_on:db:condition: service_healthyredis:condition: service_startednginx:condition: service_healthy
这里 redis 使用 service_started 表示只需容器启动即可，因为 Redis 通常启动后即可用；而 db 和 nginx 需要等待健康检查通过。
怎么验证是否生效
启动后使用以下命令检查服务状态：
docker compose ps
观察输出中的 State 列，健康的依赖服务应该显示 healthy 状态。如果显示 starting 或 unhealthy，说明健康检查还未通过或配置有问题。
查看具体容器的健康检查详情：
docker inspect <容器名> `--format`='{{json .State.Health}}' | jq检查应用容器的启动日志，确认它是在依赖服务健康后才启动的：
docker compose logs app
如果配置正确，应用日志中应该看不到连接被拒绝的错误，因为启动时依赖服务已经就绪。
常见坑
坑一：以为 depends_on 就能解决所有依赖问题
这是最常见的误解。只写 depends_on: [db] 而不配置 healthcheck 和 condition，应用仍可能因数据库未就绪而启动失败。
坑二：健康检查命令写错
不同服务需要不同的健康检查命令。PostgreSQL 用 pg_isready，MySQL 可以用 mysqladmin ping，Redis 可以用 redis-cli ping。不要随便用 curl 或 telnet 检测端口，因为端口开放不代表服务能正常响应请求。
坑三：start_period 设置太短
有些服务初始化时间较长，如数据库首次启动需要创建数据文件、加载扩展等。如果 start_period 太短，健康检查会在服务还没准备好时就开始失败计数，导致服务状态变为 unhealthy。
坑四：应用层没有容错重试
即使 Compose 等待了健康状态，网络抖动或短暂不可用仍可能发生。建议在应用代码中实现连接重试逻辑，不要假设一次连接就能成功。
坑五：condition 值写错
常用的 condition 值有三个：service_started（容器已运行，默认行为）、service_healthy（健康检查通过，需提前配置 healthcheck）、service_completed_successfully（适用于一次性任务容器）。写错会导致条件不生效。
参考来源
- Docker Compose 依赖管理指南 - 怎么在 Compose 中利用 Depends 配置容器关联启动顺序
- Docker Compose 启动顺序控制解析 - 深入解析 depends_on 的正确使用与陷阱规避
- Docker Compose 依赖控制实战 - 5 个实战案例教你正确使用 depends_on 条件
- Docker Compose 系列教程 - Docker Compose 中 depends_on 理解
- Docker 多容器编排实战教程 - Compose 实战教程
原文链接：https://www.zjcp.cc/ask/9919.html