容器级联启动关键在于等待服务就绪而非仅容器启动，需结合healthcheck、容器内脚本等待（如wait-for-it.sh）或独立初始化容器实现；depends_on alone is insufficient。
容器级联启动不是简单地“谁先谁后”，而是确保下游服务真正能连上、调用通上游依赖。Docker 本身不检查服务就绪，只管容器进程是否 running，所以必须主动做就绪等待。
用 depends_on + healthcheck 控制基础依赖链
仅靠 depends_on 不够——它只控制容器启动先后，不等数据库监听端口或服务初始化完成。必须搭配 healthcheck 才有效：
- 为数据库（如 PostgreSQL）配置健康检查，例如执行
pg_isready -U postgres -d mydb或检测 5432 端口 + 协议响应 - 在应用服务中写明：
depends_on: { db: { condition: service_healthy } } - 合理设置 healthcheck 参数：interval（建议 10–30s）、timeout（不超过 10s）、retries（3–5 次），避免卡死或误判
在容器内脚本中主动等待更可靠
把等待逻辑放进应用容器的 entrypoint.sh，比编排层等待更灵活、兼容性更好：
- 用轻量工具如
wait-for-it.sh或一行until nc -z db 5432; do sleep 2; done - 加超时机制，比如
--timeout=60，失败直接退出，不拖垮整个启动流程 - 适用于 docker run、docker-compose、Kubernetes initContainer 等各种场景，不绑定特定工具链
- 示例：Python 应用启动前执行
./wait-for-it.sh db:5432 -- python manage.py migrate
复杂初始化拆成独立初始化容器
如果启动涉及数据库迁移、缓存预热、配置加载等多步操作，别全塞进主应用容器里：
- 单独定义一个
init-db服务，restart: "no"，成功执行后自动退出 - 主应用通过
depends_on: { init-db: { condition: service_completed_successfully } }等待其完成（需 Compose v2.3+） - 失败可单独重试，不影响主服务；也方便 CI/CD 中复用初始化脚本
- 适合微服务中 upms → bgi → thingsboard 这类强顺序依赖链
本质上，级联启动的关键是“等服务就绪”，不是“等容器起来”。选哪种方式取决于你的初始化复杂度和运维习惯——简单依赖用 healthcheck 就够，常规项目推荐容器内脚本等待，多步骤初始化务必拆分。
