微服务启动关键在于服务真正就绪而非容器启动，应结合healthcheck+service_healthy声明式控制依赖、应用内指数退避重试、wait-for-it.sh兜底及分阶段compose编排。
微服务启动顺序错乱，核心不是“谁先启动”，而是“谁先真正就绪”。docker compose 的 depends_on 只管容器进程是否 running，不管 postgresql 是否能建连、redis 是否已加载数据、api 服务是否完成配置初始化。解决的关键，在于把“等待容器启动”升级为“等待服务可用”。
用 healthcheck + service_healthy 精准控制依赖
这是 Docker 原生、声明式、最推荐的第一道防线。它让 Compose 主动检测服务内部状态，而非只看容器状态。
- 给被依赖服务（如数据库）定义
healthcheck，使用其原生健康探测命令 - PostgreSQL 示例：
["CMD-SHELL", "pg_isready -U postgres -d myapp"] - MySQL 示例：
["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-pexample"] - 在依赖服务中，把
depends_on改为带条件的写法：db: condition: service_healthy
加一层应用内重试，应对运行时抖动
即使启动时服务已健康，网络波动、连接池耗尽、瞬时负载高等情况仍可能导致首次连接失败。光靠启动等待不够，运行时也要有韧性。
- 数据库客户端启用连接重试（如 Spring Boot 的
spring.datasource.hikari.connection-timeout配合重试逻辑） - 采用指数退避策略：第一次等 100ms，第二次 200ms，第三次 400ms……避免雪崩式重连
- 设置合理上限，比如最多重试 5 次，超时总和不超过 3 秒，失败后抛出明确错误便于定位
用 wait-for-it.sh 或 dockerize 做轻量兜底
适合不便于改代码、或需要兼容老镜像的场景。原理是在应用容器启动前，插入一个 shell 脚本，轮询目标服务端口或 HTTP 接口直到响应成功。
- 将
wait-for-it.sh复制进镜像，修改启动命令为：./wait-for-it.sh db:5432 -- npm start - 支持 TCP 端口检查、HTTP 状态码检查（需搭配 curl）、超时与重试参数
- 优势是无需改业务逻辑，缺点是增加一层脚本依赖，且属于“外部干预”，不如 healthcheck 声明式清晰
拆分 compose 文件，按阶段编排（适合复杂部署）
当服务之间存在强阶段性依赖（如配置中心 → 注册中心 → 业务服务），可物理隔离启动节奏：
- 第一份
docker-compose.infra.yml：只启 etcd、Nacos、Redis、DB 等基础设施 - 第二份
docker-compose.apps.yml：依赖同一自定义网络，但仅在 infra 就绪后手动或 CI 中触发 - 配合
docker network connect或共享networks:配置，确保跨文件服务互通
