单纯靠 depends_on 无法真正管理启动依赖顺序，必须结合健康检查和等待机制；推荐用 healthcheck + condition 实现原生就绪等待，或在应用容器内集成 wait-for-it.sh 等等待脚本，并辅以应用层重试增强鲁棒性。

单纯靠 depends_on 无法真正管理启动依赖顺序，它只控制容器启动先后，不判断服务是否就绪。要实现可靠依赖，必须结合健康检查和等待机制。

用 healthcheck + condition 实现原生就绪等待

这是 Docker Compose 原生支持、最推荐的方式。它让依赖服务等被依赖方通过健康检查后才启动：

• 为被依赖服务（如数据库）添加 healthcheck，用真实命令验证服务可用性（例如 pg_isready 或 curl -f http://localhost:8080/actuator/health）
• 在依赖服务的 depends_on 中指定 condition: service_healthy
• 健康检查失败时，Docker 会持续重试，直到超时或成功；依赖服务仅在此之后启动

在应用容器内集成等待脚本

当无法修改 Compose 配置或需更灵活控制时，把等待逻辑放进应用容器启动流程：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 将 wait-for-it.sh 或 dockerize 工具复制进镜像
• 在 entrypoint 或启动脚本中调用，例如：
  ./wait-for-it.sh db:5432 --timeout=60 --strict -- npm start
• 注意：wait-for-it.sh 只检测端口通断，不验证业务逻辑；适合简单场景

避免常见误区

很多问题源于对机制理解偏差：

• depends_on 默认行为 = 等容器 running，不是 ready —— PostgreSQL 容器启动了，但可能还在初始化数据目录
• 健康检查的 interval / timeout / retries 要合理设置，太短易误判，太长拖慢启动
• 网络通信依赖默认 bridge 网络，服务名即 DNS 名；不要在脚本里写 localhost，应写 db（服务名）

补充策略：应用层重试作为兜底

即使编排层做了等待，生产环境仍建议保留应用级容错：

• 数据库连接池配置初始连接延迟、最大重试次数和退避策略（如指数退避）
• HTTP 客户端对下游服务调用也启用重试，应对短暂抖动
• 这类逻辑不替代编排层等待，而是增强整体鲁棒性