depends_on 默认只保证「容器启动顺序」不保证「服务就绪顺序」：db 容器 started 的瞬间 MySQL 还要初始化几十秒，应用冲上去连就是 Connection refused。这是 compose 最经典的误解。
正确姿势是健康检查驱动：给 db 服务配 healthcheck（test: mysqladmin ping -h localhost，interval 5s，retries 10，start_period 30s——初始化期失败不计入），应用服务的 depends_on 写成条件形式：depends_on: db: condition: service_healthy（compose v2 语法）。这样应用容器会等到 db 健康检查通过才启动。postgres 用 pg_isready，redis 用 redis-cli ping，自定义应用就 curl 自己的 /healthz。
但应用侧的连接重试仍然不能省，两个原因：健康检查是采样制，db 通过检查后到应用真正连上去之间仍可能抖动；生产环境 db 重启、主从切换时不存在「启动顺序」这回事，应用必须能自愈。标准配置：连接池 initializationFailTimeout 放宽 + 启动重试逻辑（指数退避 30 秒内）+ K8s 环境用 startupProbe 给慢启动留时间。restart: unless-stopped 也是 compose 生产模板必备，宿主机重启后整套服务自动拉起。