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><ul><li>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
这样 web 会等到 db 容器通过 healthcheck（即 pg_isready 成功）后才启动。
应用层仍需容错重试
即使用了 service_healthy，网络延迟、短暂抖动仍可能导致首次连接失败。最佳实践是：
- Web 应用启动时主动重试连接数据库（例如用 wait-for-it.sh、dockerize 或代码内建重试逻辑）
- 避免把启动顺序完全交给 depends_on，尤其对数据库、缓存等有初始化耗时的服务
- 不要在应用里假设“只要容器起来了，服务就一定能用”
