depends_on仅确保容器启动完成,不保证服务就绪;需配合healthcheck的service_healthy条件及应用层重试机制才能实现可靠依赖。

depends_on 只能控制容器启动的依赖关系,不能保证服务内部是否真正就绪,它只确保被依赖的服务容器已 启动并运行(即 docker ps 显示状态为 Up),但不等待其端口监听、数据库初始化完成或应用完全可用。
depends_on 的基本写法
在 compose.yml 中,通过 depends_on 字段声明服务之间的启动依赖。Docker Compose 会按顺序创建和启动容器:先启动 depends_on 列表中的服务,再启动当前服务。
- 支持字符串列表或对象形式(可配置健康检查等待)
- 默认不等待依赖服务“就绪”,只等容器进程启动成功
- 适用于有明确启动先后需求、但不强依赖服务内部状态的场景(如 Web 服务依赖 Nginx 容器)
基础示例:web 依赖 db
以下配置会让 db 先启动,web 在 db 容器运行后再启动:
services:
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: example
<p>web:
build: .
depends_on:</p>
- db
注意:web 启动时,db 可能还在初始化数据库、监听端口,直接连接大概率失败。depends_on 不解决这个问题。
配合 healthcheck 实现更可靠的等待
要真正等待 db 可用,需在依赖服务中定义 healthcheck,并在 depends_on 中启用 condition:
services:
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: example
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 30s
timeout: 10s
retries: 5
<p>web:
build: .
depends_on:
db:
condition: service_healthy
</p>
这样 web 会等到 db 容器通过 healthcheck(即 pg_isready 成功)后才启动。
应用层仍需容错重试
即使用了 service_healthy,网络延迟、短暂抖动仍可能导致首次连接失败。最佳实践是:
- Web 应用启动时主动重试连接数据库(例如用 wait-for-it.sh、dockerize 或代码内建重试逻辑)
- 避免把启动顺序完全交给 depends_on,尤其对数据库、缓存等有初始化耗时的服务
- 不要在应用里假设“只要容器起来了,服务就一定能用”











