Docker Compose 通过分层控制管理微服务依赖：先用 depends_on 定义启动顺序，再以 healthcheck + condition 判断服务就绪，最后用应用级等待脚本收尾；依赖必须为无环有向图（DAG），循环依赖会报错退出；需避免隐式依赖，优先使用健康检查替代裸 depends_on，并对无健康端点服务补充 wait-for-it.sh 等等待机制；配置应环境分离，通过 .env、多文件组合与 profiles 实现灵活管理。
Docker Compose 管理复杂微服务依赖树，核心不是靠“堆配置”，而是分层控制：先用 depends_on 定义启动顺序骨架，再用 healthcheck + condition 补足服务就绪判断，最后靠 应用级等待脚本或重试逻辑 收尾。三者缺一不可，否则容易在生产环境出现“容器起来了但连不上”的静默失败。
依赖树必须是无环的有向图（DAG）
Compose 内部用 DAG 解析服务关系，自动推导启动/停止顺序。如果定义了循环依赖（比如 A → B → C → A），Compose 会直接报错退出，不执行任何操作。
- 检查方式：运行 docker compose config，它会验证并输出拓扑结构
- 拆解建议：把强耦合逻辑下沉到单个服务内（如把“API + 缓存预热”合并为一个服务），避免跨服务强时序绑定
- 避免隐式依赖：不要让服务 B 通过 DNS 发现服务 C 却不在
depends_on中声明——这会让启动顺序不可控
用 healthcheck + condition 替代裸 depends_on
单纯写 depends_on: [db, redis] 只等容器 running 状态，PostgreSQL 可能还在加载 WAL、Redis 还在 RDB 加载，此时上游服务连接必败。真正可靠的做法是：
- 为 db 服务加上健康检查：
pg_isready -U postgres或curl -f http://localhost:5432/health - 在依赖方声明条件：
depends_on: db: { condition: service_healthy } - 关键参数不能省：
start_period（给数据库留出初始化时间）、retries（避免瞬时失败误判）
对非标准服务补充应用级等待机制
有些中间件（如 Kafka、Elasticsearch）没有内置健康端点，或健康检查响应慢、不可靠。这时需要在服务容器内主动等待：
- 使用轻量脚本：比如
wait-for-it.sh db:5432 --timeout=60 --strict -- npm start - 或集成
dockerize：dockerize -wait tcp://redis:6379 -timeout 30s node app.js - 不推荐在应用代码里写长轮询重试——这会让日志混乱、超时难调、健康状态不透明
环境与配置分离，支撑多层级依赖
复杂依赖树常涉及不同环境（dev/staging/prod）下不同的中间件版本或地址。硬编码会导致配置爆炸：
- 用
.env文件管理变量：DB_HOST=db、KAFKA_VERSION=3.7 - 按环境拆分 Compose 文件：
docker-compose.yml（通用服务）+docker-compose.prod.yml（加监控、资源限制、TLS 配置） - 用
extends或profiles控制可选服务（如 dev 环境启用 mock-service，prod 禁用）
