Docker容器启动顺序本质是依赖服务就绪检测而非简单顺序执行。需结合healthcheck、容器内主动等待或独立初始化容器实现可靠级联启动。
理解 Docker 容器启动顺序的本质
Docker 本身不提供原生的容器启动依赖编排能力。docker run 是单点执行，docker-compose up 默认按配置顺序启动，但仅保证 YAML 中定义的先后，并不检测容器内部服务是否真正就绪。所谓“级联初始化”，实际是让下游容器等待上游容器的服务端口开放、健康检查通过或特定条件满足后，再开始自身初始化逻辑。
用 depends_on + healthcheck 实现基础级联
depends_on 在 docker-compose.yml 中仅控制启动顺序（先启 db，再启 app），但不会等待 db 的 PostgreSQL 进程监听成功。必须配合 healthcheck 才能形成有效等待：
- 为数据库服务定义健康检查，例如检测 5432 端口可连通且返回 pg_isready 响应
- 在 app 服务中设置 depends_on: { db: { condition: service_healthy } }
- 此时 docker-compose 会阻塞 app 启动，直到 db 报告 healthy 状态
注意：healthcheck 需合理设置 interval、timeout 和 retries，避免过早失败或无限等待。
容器内主动等待更可靠（推荐）
把等待逻辑下沉到应用容器启动脚本中，比编排层等待更可控、更健壮。常见做法：
- 在 app 的 entrypoint.sh 中，用 wait-for-it.sh 或自研循环检测（如 nc -z db 5432 或 curl -f http://redis:6379/ping）
- 支持超时退出，避免死锁；可记录日志便于排障
- 适用于任意启动方式（docker run / compose / k8s initContainer），不绑定工具链
例如：启动 Python 应用前，先执行 ./wait-for-it.sh db:5432 --timeout=60 --strict -- python manage.py migrate。
复杂初始化建议拆分为多阶段容器
若初始化涉及数据库迁移、缓存预热、配置同步等多步骤，不宜全堆在主应用容器里。可设计为：
- 独立的 init-job 容器（restart: "no"），依赖 db/redis 并完成迁移后退出
- 主应用容器通过 depends_on: { init-job: { condition: service_completed_successfully } }（需 Compose v2.3+）确保其执行完毕
- 或用轻量协调服务（如 consul-template、envconsul）监听依赖服务就绪后触发动作
这种方式职责清晰，失败可单独重试，也方便 CI/CD 流水线复用初始化逻辑。
