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）
编排层负责“大概率就绪”，应用层负责“小概率兜底”，两者结合才是生产级稳健性。
不复杂但容易忽略。
