docker容器级联启动的核心是等待依赖服务就绪而非控制启动顺序；需结合healthcheck与depends_on、容器内主动等待脚本或独立初始化容器实现可靠依赖管理。
在 Docker 中配置容器级联启动顺序，核心不是让容器“谁先启动”，而是确保下游服务真正能连上、用上上游依赖——比如应用启动前，数据库必须已接受连接、Redis 已响应 PING、API 服务已返回 200。Docker 本身不判断服务就绪，只管进程启动；所以级联的关键是“等待就绪”，而非“控制顺序”。
用 depends_on + healthcheck 做基础等待
这是 docker-compose 最常用也最易上手的方式，但需注意：depends_on 单独用没用，必须搭配 healthcheck 才生效。
- 为依赖服务（如 PostgreSQL）添加健康检查，例如检测端口连通性 + pg_isready 命令：
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 初始化时间。
在容器内主动等待更可靠
把等待逻辑放进应用容器的启动脚本里，比编排层控制更灵活、失败可定位、适配各种环境（包括 docker run、K8s initContainer）。
- 在 entrypoint.sh 中调用 wait-for-it.sh 或简单循环检测：
- 示例：等待 db:5432 可连通，超时 60 秒，失败则退出
#!/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 版本。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
复杂初始化拆成独立初始化容器
如果启动涉及数据库迁移、缓存预热、配置拉取等耗时或可能失败的操作，别堆在主应用里——单独起一个 init-job 容器。
- 定义一个一次性任务容器，完成即退出：
init-db:
image: my-springboot-app
command: python manage.py migrate
depends_on:
db:
condition: service_healthy
restart: "no"- 主应用通过 condition: service_completed_successfully 等待它成功结束（需 Compose v2.3+）：
app:
image: my-springboot-app
depends_on:
init-db:
condition: service_completed_successfully这种方式职责分离，失败可单独重试，也方便 CI/CD 流水线复用初始化命令。
避免常见误区
depends_on 不等于服务可用：它只等容器进程起来，不管 MySQL 是否完成初始化、Redis 是否加载了 RDB。
健康检查接口要绕过认证和业务逻辑：比如加一个 /healthz 接口，不做 token 校验、不查业务表，只返回 HTTP 200 或执行 pg_isready。
不要靠 sleep 硬等：固定延时不可靠，慢机器可能不够，快机器又浪费时间；应基于真实就绪信号做轮询。
