理解 Compose 的健康检查与就绪依赖本质
Compose 本身不提供“等待服务就绪后再启动依赖”的原生能力，所谓“前置依赖严格就绪”，实际是通过 healthcheck + depends_on: condition 组合实现的契约式控制。关键点在于：仅声明 depends_on: [service] 不触发等待；必须显式指定 condition: service_healthy（或 service_started），且被依赖服务需定义有效的健康检查。
配置被依赖服务的可靠健康检查
健康检查必须反映真实就绪状态，而非仅进程存活。例如数据库服务不能只用 curl -f http://localhost:5432（端口通 ≠ 可用），而应执行轻量级业务探测：
- PostgreSQL：用
pg_isready -U $POSTGRES_USER -d $POSTGRES_DB - Redis：用
redis-cli -h localhost -p 6379 ping | grep PONG - 自定义 HTTP 服务：用
curl -f http://localhost:8080/health，确保返回 200 且响应体含"status":"UP"
同时设置合理超时与重试，避免假失败：
healthcheck: test: ["CMD-SHELL", "pg_isready -U myuser -d mydb || exit 1"] interval: 30s timeout: 10s retries: 5 start_period: 40s
在依赖服务中声明精确的启动条件
在 depends_on 中明确使用 condition: service_healthy，并确保该服务已定义 healthcheck：
services:
app:
build: .
depends_on:
db:
condition: service_healthy # 关键：不是默认的 service_started
cache:
condition: service_healthy
<p>db:
image: postgres:15
healthcheck: # 必须存在且有效
test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"]
interval: 20s
retries: 10注意：start_period 要覆盖服务冷启动耗时（如 PostgreSQL 初始化可能需 20–60 秒），否则健康检查过早触发导致失败。
补充健壮性：应用层主动等待（可选但推荐）
Compose 的依赖等待仅控制容器启动顺序，不保证应用代码在容器内立即可用。建议在应用启动脚本中增加主动等待逻辑：
- 使用
wait-for-it.sh或dockerize工具封装连接重试 - Node.js 应用中用
await wait-on http-get://db:5432/ready - Java Spring Boot 默认支持
spring.datasource.hikari.initialization-fail-timeout配合健康端点
这样形成“Compose 控制容器级依赖 → 应用控制进程级就绪”的双重保障。
