记录一下那天晚上的排查过程。Ubuntu 22.04 上用 docker compose 起一套应用，db 容器初始化要四十秒，app 容器三秒就启动然后连不上数据库退出，加了 depends_on 之后现象一点没变。
刚开始盯着「compose 文件版本是 2.x，长语法的 condition 根本不被解析」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。depends_on 默认只等容器创建，不等里面的服务真正可用。少数情况下是写了 condition: service_healthy 但 db 没有配 healthcheck，条件永远不成立。
少数情况下是healthcheck 的 test 命令返回码不对，容器永远处于 starting。
动手时先看 compose 把依赖解析成了什么
docker compose config | grep -A5 depends_on给 db 补一个可用的健康检查
docker inspect -f '{{json .State.Health}}' proj-db-1然后用长语法声明健康依赖并重建
docker compose up -d --force-recreate app等前面都确认过，再确认启动顺序符合预期
docker compose ps --format 'table {{.Name}}\t{{.Status}}'别只看报错消失，验证要多做一步。docker compose ps 里 db 先变成 healthy，app 在之后才启动，应用日志里第一次连库就成功，不再出现重试和退出。
提醒一点。健康检查命令要能在容器内跑通并且真的反映服务就绪，用 curl 探本机时记得镜像里可能没有 curl；改 compose 文件后必须重建，restart 不会重新判断依赖。报错文案容易误导，真正的原因往往在相邻那一层的日志里。