健康状态检查不能依赖depends_on实现，需结合healthcheck定义与应用层等待逻辑：为被依赖服务配置healthcheck（如pg_isready），在依赖服务中通过docker-compose-wait或shell轮询主动等待，再辅以depends_on condition: service_healthy。
在 compose.yml 中，服务间依赖的“健康状态检查”不能靠 depends_on 实现——它只控制启动顺序，不检查目标服务是否真正就绪（比如数据库是否能响应 SQL 请求）。要实现基于健康状态的依赖等待，需结合健康检查定义 + 启动前等待逻辑。
1. 为被依赖服务配置 healthcheck
健康检查是基础。Docker Compose 会定期执行命令判断容器是否健康，状态变为 healthy 后才视为就绪。
services:
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: example
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
注意：start_period 很关键——PostgreSQL 启动慢，需预留初始化时间；retries 和 timeout 要合理，避免过早失败。
2. 在依赖服务中主动等待健康状态
depends_on: [db] 配合 condition: service_healthy 只能等 healthcheck 成功，但应用容器自身仍可能因连接池未初始化、ORM 未迁移等提前启动失败。更可靠的做法是在应用镜像里加等待脚本：
- 使用 docker-compose-wait（推荐）：在应用启动命令前插入等待逻辑
- 或用简单 shell 轮询（如
until pg_isready -h db -U postgres; do sleep 2; done） - 确保等待逻辑在应用主进程启动前执行，通常通过封装
entrypoint.sh
3. 正确使用 depends_on + condition（辅助作用）
它不替代应用层等待，但可防止容器过早启动（比如在 db 还没开始健康检查时就跑起来）：
services:
app:
build: .
depends_on:
db:
condition: service_healthy # 等 db 容器状态变成 healthy
这个条件生效的前提是 db 已定义 healthcheck，否则始终不满足。
4. 避免常见误区
-
depends_on不等于“已连通”，它不检测网络可达性或端口响应，只看容器状态和健康检查结果 - 健康检查命令必须在容器内可用（如
pg_isready在 PostgreSQL 镜像中有，但 Alpine 镜像默认没有curl或nc，需自行安装） - Java/Spring Boot 等框架建议用 Actuator 的
/actuator/health做 HTTP 检查，而非只 ping 端口
健康依赖的本质是：先让被依赖服务自报状态（healthcheck），再让依赖方主动确认连通性（应用内等待）。两者配合，才能真正解决“启动了但还没好”的问题。
