要用 condition 实现“上游容器完全健康后再拉起下游”，核心是结合 depends_on 与 service_healthy，但必须清楚：这仅在 Docker Compose v2.3+ 及以上生效，且只控制启动顺序，不保证服务业务就绪——真正的“完全健康”还得靠健康检查本身配置得当。
要用 condition 实现“上游容器完全健康后再拉起下游”，核心是结合 depends_on 与 service_healthy，但必须清楚：这仅在 docker compose v2.3+ 及以上生效，且只控制启动顺序，不保证服务业务就绪——真正的“完全健康”还得靠健康检查本身配置得当。
docker-compose.yml 中正确声明依赖条件
在 depends_on 中指定 condition: service_healthy，表示下游容器会等待上游容器的健康状态变为 healthy 后才开始启动：
-
service_healthy不是“容器进程 running”，而是 Docker 已确认其HEALTHCHECK连续成功、状态稳定为healthy - 该条件仅作用于
docker compose up阶段，不持续阻塞；一旦下游启动，后续上游变 unhealthy 不会自动重启下游 - 必须确保上游服务已在
healthcheck块中正确定义（或镜像内已含HEALTHCHECK），否则状态永远卡在starting，下游一直等
上游容器的健康检查必须真实反映业务就绪
很多失败源于健康检查“形同虚设”。要让 service_healthy 有意义，上游的健康端点需满足：
- 返回 HTTP 2xx/3xx 状态码，且命令带
-f（如curl -f http://localhost:8080/health），避免 404/503 被误判为 healthy - 端点内部做轻量级业务校验：比如 Spring Boot 的
/actuator/health默认检查数据库连接、Redis 连通性；Node.js 服务可查 DB ping + 缓存初始化标志 -
start_period设足够长（如 90s），覆盖冷启动耗时（JVM 加载、连接池填充、缓存预热等），避免因过早检查失败而永久卡住依赖链
避免常见陷阱：condition 不等于服务可用
service_healthy 是必要条件，但不是充分条件。以下情况仍会导致下游启动后报错：
- 上游健康端点返回了
{"status":"UP"}，但数据库连接池刚建好、第一条查询还没执行——下游发请求时仍可能超时 - 网络延迟或 DNS 解析偶尔失败，
curl在容器内调用localhost失效（尤其 Alpine 镜像未配 hosts）；建议改用127.0.0.1或服务名（如http://web:8080/health） - 下游应用自身未做重试或熔断，一上来就密集请求，压垮尚未完全 warmup 的上游
增强可靠性的补充手段
单靠 depends_on + service_healthy 不够稳健，建议叠加：
- 下游启动前加轻量级等待脚本（如
wait-for工具），在 entrypoint 中循环调用上游健康接口，直到返回 200 再 exec 主程序 - 对关键依赖（如数据库），在下游镜像里嵌入初始化检查逻辑，例如用
mysqladmin ping -h db或pg_isready -h pg - 配合
restart: on-failure+ 指定次数，让短暂抖动导致的启动失败自动恢复，而非直接退出
