docker compose通过healthcheck与depends_on的condition: service_healthy组合实现依赖服务健康等待。需为被依赖服务配置含start_period的healthcheck，上游服务声明depends_on条件，启动时自动等待健康后执行，但应用层仍需自行处理连接重试。
Docker Compose 的健康检查（healthcheck）本身不直接触发依赖服务的自动启动或重试，但可以通过合理配置 depends_on 的 condition 字段，实现“等待依赖服务健康后再启动当前服务”的联动效果。关键在于组合使用 healthcheck + depends_on: { service: xxx, condition: service_healthy }。
1. 为被依赖服务定义健康检查
目标服务（如数据库、Redis）必须显式声明 healthcheck，否则其他服务无法判断其是否就绪。
示例：PostgreSQL 服务添加健康检查
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: example
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
注意：start_period 很重要——容器启动初期可能尚未完成初始化，需预留足够时间再开始探测；test 命令需实际验证服务可用性（如连通性+基础响应），而非仅检查进程是否存在。
2. 在依赖服务中用 service_healthy 声明启动条件
上游服务（如应用 API）通过 depends_on 指定等待 db 健康后才启动：
api:
build: .
depends_on:
db:
condition: service_healthy
# 其他配置...
此时 docker-compose up api 会：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 先启动
db容器 - 等待
db的健康检查连续成功（默认需通过retries次） - 确认
db状态为healthy后，再启动api
3. 避免常见误区
健康检查 ≠ 应用内部连接就绪：即使 db 容器报告 healthy，你的应用代码仍需处理连接失败重试（例如网络抖动、事务锁等）。Compose 不接管应用层逻辑。
condition 不支持 “service_started” 或 “service_running”：这两个值只检查容器是否运行，不校验服务是否可用，容易导致应用启动后因 DB 未就绪而崩溃。
不要省略 start_period：PostgreSQL、MySQL 等初始化耗时较长，若健康检查在初始化完成前开始，会误判失败并重试多次，拖慢整体启动。
4. 进阶：多依赖 & 健康状态可视化
可同时依赖多个健康服务：
app:
build: .
depends_on:
db:
condition: service_healthy
cache:
condition: service_healthy
查看健康状态：
docker-compose ps
输出中 Health 列会显示 healthy / unhealthy / starting，便于排查启动卡点。
