Docker Compose 依赖管理需分层设计：仅用 depends_on 不足，必须结合 healthcheck 实现真就绪等待、避免循环依赖、应用层内置重试容错，并辅以日志诊断。
Docker Compose 本身不是微服务编排平台，它不处理服务发现、动态扩缩容或跨主机调度，但对本地开发和中小型部署场景中的依赖关系管理，它提供了一套清晰、可组合的机制。关键在于：不能只靠 depends_on，必须分层设计——启动顺序 + 健康就绪 + 应用韧性。
depends_on 是起点，不是终点
它只控制容器启动先后，不判断服务是否可用。比如：
services:
api:
build: ./api
depends_on:
- db
- redis
db:
image: postgres:15
redis:
image: redis:7-alpine这段配置只是让 db 和 redis 容器先拉起，但 api 启动时，PostgreSQL 可能还在初始化、Redis 还没加载完数据——连接失败几乎必然发生。
必须配合 healthcheck 实现“真就绪”等待
给被依赖服务加上健康检查，并在 depends_on 中指定条件：
services:
db:
image: postgres:15
environment:
POSTGRES_DB: app
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d app"]
interval: 10s
timeout: 5s
retries: 10
start_period: 30s
api:
build: ./api
depends_on:
db:
condition: service_healthy # ← 关键！等 healthcheck 成功才启动
redis:
condition: service_healthy这样 api 容器启动前，Compose 会持续轮询 db 和 redis 的健康状态，直到两者都返回 healthy。
复杂依赖链需避免循环，拆解为单向依赖
例如 A → B → C 是安全的；但若 A 依赖 B，B 依赖 C，C 又回调 A（如日志服务反向调用认证服务），就会形成循环依赖，导致启动卡死。解决方法：
- 拆出公共能力（如把认证抽成独立 auth-service）
- 用异步通信替代同步调用（如通过消息队列解耦）
- 对非核心依赖（如监控上报）设置宽松条件（
condition: service_started）
应用层要自带容错能力，别全指望编排层
即使 Compose 等到了服务健康，网络抖动、瞬时超载仍可能导致首次连接失败。因此应用代码中应包含：
- 数据库连接重试（带指数退避）
- HTTP 客户端设置超时与重试（如 Spring 的
@Retryable或 Resilience4j） - 启动时主动探测关键依赖（如 Spring Boot 的
LivenessProbe+ReadinessProbe）
开发期建议加日志聚合和启动诊断
在 docker-compose.yml 中启用统一日志输出，便于快速定位卡点：
services:
api:
# ... 其他配置
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"搭配 docker compose logs -f --tail=50 实时观察各服务启动流，尤其关注 db 是否真正进入 healthy 状态，以及 api 是否在健康后立刻发起连接。
基本上就这些。Compose 的依赖管理不复杂，但容易忽略健康检查和应用韧性这两层，补上就能覆盖绝大多数微服务本地联调和 CI 部署场景。
