depends_on仅控制容器启动顺序，不能确保服务就绪；需配合healthcheck定义服务健康状态，并用condition: service_healthy实现精准等待，应用层仍需内置重试容错。

单纯靠 depends_on 无法确保服务真正可用，它只管容器“跑起来”，不管里面的服务有没有准备好。要让依赖链稳住，得把启动顺序、健康检查、等待逻辑三者配合起来用。

depends_on 是起点，不是终点

它只是声明“这个服务得等那个服务先启动”。比如 web 依赖 db：

• docker-compose 会先创建并启动 db 容器（状态变为 running）
• 然后才开始构建/启动 web 容器
• 但此时 PostgreSQL 可能还在初始化数据目录、加载扩展、启动监听进程——端口通了，服务未必能连

所以不能把 depends_on 当成“等数据库就绪”的开关，它只是启动流程的第一道调度指令。

必须配 healthcheck 才算真正“看得到”服务状态

给关键依赖服务（如 db、redis、rabbitmq）加上健康检查，才能让 Docker 知道“它活了且能干活”：

• PostgreSQL 示例：test: ["CMD-SHELL", "pg_isready -U postgres"]
• Redis 示例：test: ["CMD", "redis-cli", "ping"]
• 设置 interval（检测频率）、timeout（单次超时）、retries（连续成功次数）

健康检查通过后，服务状态才会变成 healthy，后续机制才能基于这个状态做判断。

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

用 condition: service_healthy 实现精准等待

Docker Compose v2.1+ 支持在 depends_on 中指定条件，这才是让依赖“等到位”的标准写法：

• depends_on:
  db:
    condition: service_healthy
• 这样 web 不仅等 db 容器启动，还会等 db 状态变成 healthy 后才启动
• 比纯脚本更轻量、更原生，也更容易被 docker-compose ps / docker inspect 观察到

应用层仍需容错，不能全靠编排层兜底

即使 Compose 层做了健康检查和条件等待，网络抖动、服务短暂重启、连接池初始化延迟等情况仍可能发生：

• Web 应用首次连接数据库时，应自带重试逻辑（例如：最多重试 5 次，每次间隔 1–3 秒）
• 避免一连不上就直接 panic 或 exit，导致容器反复重启
• 推荐使用成熟库（如 Go 的 sql.Open + db.PingContext 带 timeout 和 retry）

编排层负责“大概率就绪”，应用层负责“小概率兜底”，两者结合才是生产级稳健性。

不复杂但容易忽略。