Docker容器级联启动本质是等待依赖服务就绪而非控制启动顺序，推荐使用depends_on+healthcheck、容器内主动等待（如wait-for-it.sh）或独立init容器实现可靠初始化。
在Docker中配置容器级联启动顺序，关键不是让A容器“先启动”、B容器“后启动”，而是确保B容器真正能连上并使用A容器提供的服务——比如数据库监听了5432端口、Redis响应了PING、API返回了200状态。Docker本身只管进程是否启动，不判断服务是否就绪。所以级联的本质是“等待就绪”，不是“控制顺序”。
用 depends_on + healthcheck 做基础等待
这是 docker-compose 最常用的方式，但必须配合使用才有效：单独写 depends_on 只控制启动先后，不等待服务可用。
- 为依赖服务（如 PostgreSQL）添加健康检查，例如：
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d myapp"]
interval: 30s
timeout: 10s
retries: 5
start_period: 40s
- 在应用服务中声明强依赖条件：
app:
image: my-springboot-app
depends_on:
db:
condition: service_healthy
此时 docker-compose 会阻塞 app 启动，直到 db 容器报告 healthy 状态。注意 start_period 要覆盖数据库初始化时间（PostgreSQL首次启动可能需30秒以上）。
在容器内主动等待更可靠
把等待逻辑放进应用容器的启动脚本里，比编排层控制更灵活、失败可定位、适配各种环境（包括 docker run、Kubernetes initContainer）。
- 在 entrypoint.sh 中调用 wait-for-it.sh 或简单循环检测：
#!/bin/sh
./wait-for-it.sh db:5432 --timeout=60 --strict -- \
python manage.py migrate && \
exec python manage.py runserver 0.0.0.0:8000
- 支持日志输出、自定义重试间隔、兼容任意 TCP 服务（MySQL、Redis、Elasticsearch）
- 不依赖 compose 版本，失败时直接退出，避免卡死或静默失败
复杂初始化拆成独立初始化容器
如果启动涉及数据库迁移、缓存预热、配置拉取等耗时或可能失败的操作，别堆在主应用容器里——单独起一个 init-job 容器。
- 定义一个一次性任务容器，完成即退出：
init-migrate:
image: my-springboot-app
command: ["sh", "-c", "python manage.py migrate"]
depends_on:
- db
restart: "no"
- 主应用通过 depends_on 指向该 init 容器，并设置 condition: service_completed_successfully（需 Compose v2.3+）
- 职责清晰，失败可单独重试，也方便 CI/CD 流水线复用初始化逻辑
不推荐的做法
以下方式看似简单，实际隐患明显：
- 纯 depends_on 不配 healthcheck：只保证容器进程启动，不保证服务可连接，应用仍大概率启动失败
- sleep 延迟启动：硬编码等待时间不可靠，环境变化（CPU负载、磁盘IO）会导致等待不足或过度
- 在 Dockerfile 中用 CMD sleep + 启动命令：破坏镜像通用性，无法适配不同部署场景
- 外部 Shell 脚本按顺序 docker start：缺乏服务就绪判断，无法应对容器启动慢、网络延迟等真实问题
