docker compose 中需用 healthcheck + condition 实现服务真正就绪依赖，depends_on 仅控制启动顺序而非可用性；db 需配置 pg_isready 健康检查，web 须设 condition: service_healthy；辅以 wait-for-it.sh 端口探测或应用层重试。
要让 docker compose 中的服务按需启动、真正就绪后再依赖运行，不能只靠 depends_on 写个顺序就完事。它只管容器“跑起来”，不管应用有没有监听端口、数据库连不连得上、api 是否可响应。实战中必须组合健康检查、等待脚本或条件判断，才能避免 connection refused 或启动失败。
depends_on 是起点，不是终点
它定义的是容器启动的先后，而非服务可用性保障。比如：
- db 容器启动后，PostgreSQL 进程可能还在初始化数据目录，耗时几秒到十几秒
- web 容器一看到 db 容器 running 就立刻执行
npm start，此时连接数据库必然失败 - 这个行为在本地开发偶尔能“碰巧成功”，但一上 CI 或高负载环境就稳定报错
用 healthcheck + condition 实现可靠等待
这是目前最推荐、最原生、无需额外脚本的方案。关键在于两处配置协同：
- 被依赖服务（如 db）必须定义
healthcheck，用真实业务逻辑判断是否就绪，例如：test: ["CMD-SHELL", "pg_isready -U postgres"] - 依赖方（如 web）在
depends_on中指定condition: service_healthy，而不是默认的service_started - 务必设置合理的
interval、timeout和retries，避免过早失败或无限等待
用 wait-for-it.sh 做轻量级端口探测
适合无法修改目标服务镜像、或健康检查命令不可用的场景（比如自建 Java 微服务没暴露 /health 端点）：
- 下载
wait-for-it.sh到项目根目录，赋予可执行权限 - 挂载进容器：
volumes: ["./wait-for-it.sh:/wait-for-it.sh"] - 重写启动命令：
command: sh -c "./wait-for-it.sh db:5432 --timeout=60 -- npm start" - 注意：它只检测端口通不通，不验证协议层或业务逻辑是否就绪（如 PostgreSQL 启动但密码错误，端口仍通）
生产环境建议的组合策略
单一手段总有盲区，高可用系统应分层防御：
- 底层：db、redis 等基础服务开启
healthcheck，并设好超时与重试 - 中间层：web、api 类服务统一使用
depends_on: {service: condition: service_healthy} - 兜底层：应用自身代码加入连接重试逻辑（如 Spring Boot 的
spring.datasource.hikari.connection-timeout+ 初始化重试） - 可观测性：配合
docker-compose logs -f和健康状态查询docker inspect -f '{{.State.Health.Status}}' <container></container>快速定位卡点
