depends_on 的 condition 参数仅控制等待行为而非启动顺序，真正可靠的方式是结合 healthcheck 与 condition: service_healthy，确保依赖服务通过健康检查（如 pg_isready）后才启动上游服务。
在 Docker Compose 中，depends_on 的 condition 参数本身**不能真正控制微服务启动顺序**，它只影响容器的“就绪等待”行为，而非启动先后。真正决定启动顺序的是 depends_on 的依赖声明 + 容器内部服务是否真正就绪。要可靠控制微服务启动顺序，需结合健康检查（healthcheck）与 condition: service_healthy。
condition 的可选值及真实作用
depends_on 的 condition 仅用于指定等待依赖服务处于何种状态才启动当前服务，它不改变 Docker 的并行启动行为，也不保证服务逻辑已就绪：
-
service_started：仅等待依赖容器进程启动（即docker start成功），不检查端口或业务是否可用 —— 最弱，不推荐用于依赖数据库、Redis 等场景 -
service_healthy：等待依赖容器通过其定义的healthcheck检查（返回healthy）—— 唯一能体现“服务真正可用”的条件 -
service_completed_successfully：仅适用于one-off类型容器（如数据迁移脚本），等待其退出且返回码为 0
必须配合 healthcheck 才有效
condition: service_healthy 不会自动生效，你必须为被依赖服务明确定义 healthcheck，否则该 condition 会永远等待或报错：
services:
postgres:
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
<p>api:
build: ./api
depends_on:
postgres:
condition: service_healthy # ← 此时才真正等待 PostgreSQL 可连接
</p>
注意：start_period 很关键，它允许数据库在首次检查前有足够时间完成初始化（PostgreSQL 启动较慢）。
常见误区与替代方案
仅靠 depends_on + condition 无法解决所有启动依赖问题，尤其当服务间存在循环依赖、网络延迟或服务启动后仍需加载配置时：
-
应用层重试更可靠：API 服务启动时应自带数据库连接重试逻辑（如使用
spring-boot-starter-jdbc的spring.datasource.hikari.connection-timeout+ 初始化重试），而不是完全依赖 Docker 编排 -
避免过度依赖 depends_on：Kubernetes 中无此机制，建议将启动健壮性下沉到应用自身（例如用
wait-for-it.sh或dockerize脚本包装启动命令） -
condition 不等于启动顺序保证：Docker 仍可能先启动
api，再启动postgres；depends_on只是让api的启动过程暂停等待 —— 实际顺序由docker-compose up内部调度决定
轻量级启动协调建议
若需更强控制，可在服务启动命令中嵌入等待逻辑，无需额外工具：
- 在
api的entrypoint.sh中调用nc -z postgres 5432或curl -f http://config:8888/actuator/health，失败则 sleep + retry - 使用官方推荐的 wait-for 工具简化脚本逻辑
- 对 Java 应用，启用 Spring Boot 的
spring.cloud.bootstrap.enabled=true和配置中心预加载，减少运行时依赖
不复杂但容易忽略：condition 是“等什么”，healthcheck 是“怎么判”，两者缺一不可；而真正的容错能力，还得靠服务自己扛。
