docker compose启动死锁的破局点是分层就绪判定+主动退出机制：需拆解循环依赖、锚定无依赖服务为启动主干，结合healthcheck与startup探针双重验证（如pg_isready+curl+sql校验），并用带超时/退避的wait-for脚本和on-failure重启策略防僵局。
在复杂微服务链条中，docker compose 启动死锁通常不是因为容器没启动，而是多个服务互相等待对方“就绪”，却各自只检查端口或容器状态，结果卡在循环依赖或假就绪状态里。核心破局点在于：**不依赖单向等待，而用分层就绪判定 + 主动退出机制打破僵局**。
拆解循环依赖，明确启动主干链
微服务间若存在 A→B→C→A 这类隐式循环（比如配置中心要注册到注册中心、网关要拉取配置、注册中心又要连网关健康探针），depends_on 会直接失效甚至引发死锁。必须人工梳理出一条无环的启动主干：
- 识别真正无外部依赖的“锚点服务”：通常是 Eureka Server、Consul Server、独立 Config Server（不依赖远程配置）或数据库初始化器
- 将其他服务按数据流/控制流方向分级：一级依赖锚点，二级依赖一级，以此类推；禁止跨级反向引用
- 对无法解耦的双向交互（如服务注册 + 健康上报），强制约定“注册可异步，健康检测延后 30 秒开始”，避免启动期强耦合
用 healthcheck + startup probe 双重判定就绪
仅靠端口开放（nc -z）或容器 running 状态极易误判。MySQL 容器可能已监听 3306，但 root 密码未设好、库未初始化；Eureka 可能返回 HTTP 200，但 peer replication 尚未完成。应组合使用：
- 容器级 healthcheck：检测进程存活与基础端口（如 curl -f http://localhost:8761/actuator/health）
- 启动期专用探针脚本：在 entrypoint 中嵌入 startup.sh，调用 pg_isready -h db 或 curl -f http://config:8888/actuator/health | jq -e '.status == "UP"'，失败则 sleep 后重试，超时（如 120s）直接 exit 1
- web 服务的 depends_on 条件改用 condition: service_started + 自定义健康检查脚本触发，而非单纯 service_healthy
引入带超时和退避的等待脚本，防无限挂起
wait-for-it.sh 类脚本若无超时，会导致整个 compose up 卡住不动。必须强化其鲁棒性：
- 脚本内设置最大等待时间（如 TIMEOUT=180），超时后 echo 错误并 exit 1，触发容器失败退出而非静默等待
- 采用指数退避：首次等待 1s，失败后 2s、4s、8s…避免高频探测压垮依赖服务
- 对关键依赖（如 DB、Config）做多点验证：先 nc 检端口，再 mysql -h db -u root -p$PASS -e "SELECT 1"，双通过才算就绪
- 在 docker-compose.yml 中 command 替换为 ["./wait-for-deps.sh", "db:5432", "config:8888", "--timeout", "180", "--", "python", "app.py"]
用 restart: on-failure 配合 backoff 防止雪崩重启
当某服务因依赖未就绪启动失败，Docker 默认立即重试，可能加剧资源争抢或日志刷屏。应主动控制重启行为：
- 对非核心服务（如日志收集器、监控 exporter）设 restart: "on-failure:3"，最多重试 3 次即停
- 对核心服务（如 API Gateway）设 restart: unless-stopped，并在应用启动逻辑中内置重试（如 Spring Boot 的 spring.datasource.hikari.connection-timeout=30000 + max-lifetime=1800000）
- 避免全局 restart: always —— 它会让失败服务无限重启，掩盖真实依赖问题
