depends_on仅确保容器启动，不保证服务就绪；需结合healthcheck定义就绪状态、service_healthy条件等待、wait-for-it.sh/dockerize探活及应用层重试机制共同解决。
depends_on 本身不感知容器内服务是否真实可用，它只管容器“跑起来了没”，不管数据库连不连得上、API 听不听得到、端口通不通。这个痛点必须靠组合手段来解决，核心思路是：用健康检查定义“就绪”，再用依赖条件或脚本等待这个状态。
给依赖服务加 healthcheck，让 Docker 知道它真好了
这是最规范、原生支持的方式。Docker 能基于你写的检测命令判断服务是否进入可服务状态，不只是“容器在运行”。-
test命令要能真实反映业务就绪（比如 MySQL 用mysqladmin ping，PostgreSQL 用pg_isready，HTTP 服务用curl -f http://localhost:8080/health） -
start_period很关键：给数据库留出初始化时间（如 30 秒），避免刚启动就被判失败 -
retries和timeout配合，防止偶发网络抖动误判
例如：
db:
image: postgres:15
environment:
POSTGRES_DB: myapp
POSTGRES_PASSWORD: secret
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
start_period: 40s在依赖服务里用 condition: service_healthy 显式等待
光有 healthcheck 不够，还得让上游服务“等它好”。从 Compose v2.1 起，`depends_on` 支持带条件的写法：web:
build: .
depends_on:
db:
condition: service_healthy这样 web 容器不会在 db 容器一启动就开跑，而是等到 db 连续通过健康检查（即 docker inspect 中显示 "Status": "healthy"）才真正启动。
用 wait-for-it.sh 或 dockerize 在启动前主动探活
适合老版本 Compose、或需要更灵活控制（比如等多个服务、加自定义逻辑）的场景。-
wait-for-it.sh是轻量 Bash 脚本，只做 TCP 端口连通性检测（简单直接，但不验证协议层就绪） -
dockerize功能更强，支持 HTTP、TCP、文件存在等多种检查方式，还能渲染模板
用法示例（挂载脚本后）：
web:
build: .
depends_on: [db]
command: ["./wait-for-it.sh", "db:5432", "--", "npm", "start"]
volumes:
- ./wait-for-it.sh:/wait-for-it.sh应用层自己重试，最可靠也最可控
无论编排层怎么等，网络和初始化总有不确定性。在代码里实现连接重试（推荐指数退避 + 最大尝试次数）才是兜底方案。- Python（SQLAlchemy）：用
connect_args={"connect_timeout": 5}+ 自定义pool_pre_ping=True - Node.js（pg）：配合
node-postgres的maxRetries和retryDelay - Java（Spring Boot）：配置
spring.datasource.hikari.connection-timeout和initialization-fail-timeout
这步不是“可选优化”，而是生产环境必备容错能力。
本质上，depends_on 是容器调度层面的声明，而服务就绪是应用生命周期问题——两者不在一个抽象层级。把它们串起来，靠的是健康检查 + 条件等待 + 应用韧性，三者缺一不可。
