Docker Compose 启动卡顿主因是服务间隐式循环依赖与健康状态失控，需用 healthcheck + service_healthy 替代 depends_on，明确定义就绪条件，拆解双向依赖，并分批启动验证收敛性。
这通常不是 Docker Compose 本身的“死锁”，而是服务间依赖关系未收敛、健康状态不可控，导致启动卡在等待环节——比如 A 等 B，B 等 C，C 又间接依赖 A 的就绪信号，形成逻辑闭环。关键不在删配置，而在切断无效等待、显式定义就绪条件。
用 healthcheck + service_healthy 替代单纯 depends_on
depends_on 只保证容器进程启动，不判断服务是否真正可用。数据库容器起来了，但 PostgreSQL 还没完成初始化；缓存服务启动了，但 Redis 还没加载完持久化数据——这些都会让下游无限等待。
- 为每个被依赖服务（如 db、redis、elasticsearch）明确定义 healthcheck，使用能真实反映业务就绪的命令，例如：
test: ["CMD-SHELL", "pg_isready -U postgres -d myapp"]或test: ["CMD", "redis-cli", "ping"] - 在上游服务中改用 depends_on: {service: condition: service_healthy}，确保只在目标服务通过健康检查后才启动
- 设置
start_period覆盖冷启动时间（如 PostgreSQL 首次初始化可能需 20–30 秒），避免因检测过早失败而重试中断
拆解隐式循环依赖
看似无关的服务，可能通过日志收集器、监控代理或配置中心间接互指。例如：应用服务将日志发给 fluentd，fluentd 又依赖 consul 获取配置，而 consul 启动又要求应用注册健康端点——这就构成了启动环。
- 运行
docker-compose config输出完整解析后的 YAML，人工检查是否存在跨服务的“双向就绪依赖” - 把日志、监控、配置类基础设施服务设为 独立启动组，不参与主业务链的 depends_on，改用后台轮询或延迟重试机制接入
- 对必须联动的服务，引入轻量级协调层（如一个 init 容器或 shell 脚本），统一等待所有依赖就绪后再触发主服务启动
控制启动节奏，避免并发爆炸
当 10+ 服务同时启动并互相探测，网络探测包、连接尝试、健康检查请求会集中爆发，反而拖慢整体就绪速度，甚至触发超时退避逻辑。
- 用
deploy.restart_policy.delay和deploy.restart_policy.max_attempts控制失败重试节奏，防止雪崩式重试 - 对非核心服务（如文档站点、管理后台）添加
restart: "no"，避免它们反复重启干扰主链 - 分批启动：先
docker-compose up -d db redis，等docker-compose ps显示 healthy 后，再up -d app api
验证依赖图是否收敛
没有工具能直接画出 Docker Compose 的“运行时依赖图”，但你可以用组合命令逼近：
- 执行
docker-compose config --resolve-image-digests | grep -A5 -B5 "depends_on\|healthcheck"快速定位所有显式依赖声明 - 对每个 service，运行
docker-compose exec <service> sh -c 'echo $HOSTNAME && netstat -tuln | grep LISTEN'，确认它实际监听了哪些端口、是否真在提供服务 - 若某服务始终卡在
Waiting for healthy status，进入其容器执行telnet other-service 5432或curl -v http://config:8500/v1/status/leader，看是网络不通、端口未开，还是对方根本没响应
