Docker Compose 中实现多容器按序启动需结合 healthcheck 与 depends_on 的 condition: service_healthy。上游服务（如 PostgreSQL）须配置合理健康检查（如 pg_isready），下游服务（如 API）通过 depends_on 指定依赖其健康状态，确保业务就绪后再启动，避免仅等待容器运行。
在 Docker Compose 中实现健康检查和多容器按序启动，核心是结合 healthcheck 配置与 depends_on 的 condition: service_healthy，让下游服务真正等上游服务就绪后再启动，而非仅等待容器创建完成。
配置容器健康检查（healthcheck）
健康检查需由服务自身暴露可探测的端点（如 HTTP /health 或 TCP 端口响应），并在 docker-compose.yml 中明确定义：
- 使用
curl、nc或内置命令（如test -f /tmp/ready）判断服务是否就绪 -
interval、timeout、retries和start_period需合理设置，避免过早失败或等待过久 -
关键细节：Docker 默认以 root 运行 healthcheck 命令，若容器内无
curl或nc，需提前安装，或改用 shell 内置方式（如sh -c 'echo > /dev/tcp/127.0.0.1/8080' 2>/dev/null）
示例（Spring Boot 应用）：
web:
image: my-web-app
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
声明依赖并指定健康就绪条件
depends_on 默认只等容器启动成功（即 created → running），不关心业务就绪。要实现“等健康”，必须显式指定条件：
- 写法为
depends_on: { service-name: { condition: service_healthy } } - 被依赖的服务（如数据库）必须已定义
healthcheck，否则会报错或始终不满足条件 - 多个依赖可同时声明，Docker Compose 会串行检查所有健康状态
示例（API 服务依赖已健康的数据库）：
api:
image: my-api-app
depends_on:
db:
condition: service_healthy
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d mydb"]
interval: 30s
timeout: 10s
retries: 5
start_period: 60s
规避常见陷阱
实际使用中易忽略以下问题，导致“看似配置了，但仍未按序就绪”：
-
应用启动慢于健康检查首次执行：务必设置足够长的
start_period（尤其对 JVM、PostgreSQL 初始化），否则健康检查在服务真正监听前就失败多次，进入 unhealthy 状态 -
健康检查路径/端口未开放或权限受限：确保容器内服务监听
0.0.0.0（非127.0.0.1），且防火墙或安全组未拦截；PostgreSQL 需确认pg_hba.conf允许本地pg_isready连接 - 依赖链断裂：若 A 依赖 B，B 依赖 C，则 C 必须先健康，B 才可能变健康，A 才能启动——任一环节 healthcheck 缺失或失败，整条链阻塞
补充建议：应用层兜底更可靠
Docker 层的健康检查 + service_healthy 是良好起点，但不能替代应用自身的容错设计：
- 客户端（如 Spring Boot 的
@Retryable、RabbitMQ 的自动重连）应具备连接失败后重试能力 - 避免在应用启动时硬性阻塞等待 DB 连接（如 Hibernate
spring.jpa.hibernate.ddl-auto=validate启动即校验），改用延迟初始化或健康探针驱动 - 调试时可用
docker compose ps查看各服务STATUS列是否含healthy，用docker compose logs <service>检查 healthcheck 执行输出
