depends_on不解决服务就绪问题，仅控制容器启动顺序；需分三层排查：语法与版本验证、容器实际启动时序、依赖服务应用级健康检查及等待机制。
depends_on 不生效，不是配置写错了，而是它根本没打算解决“服务就绪”问题——它只管容器启没启动，不管里面的应用有没有准备好收请求。排查要分两层：先确认 docker compose 是否按预期调度了容器顺序，再验证目标服务是否真正可用。
确认 depends_on 是否被正确解析
Compose 文件里 depends_on 的语法必须准确，否则会被忽略：
- 检查缩进和冒号：depends_on: 下每一项必须顶格对齐，且后跟短横线加空格，比如
- db，不能写成-db或- db: - 避免拼写错误：服务名必须与
services下定义的完全一致（区分大小写），例如db和DB是两个不同服务 - 验证 Compose 版本支持：
depends_on在 v2+ 全支持，但条件式写法（如condition: service_healthy）需 v2.1+ 或 v3.4+，老版本会静默忽略 - 运行
docker-compose config查看最终解析结果，确认depends_on字段是否出现在输出中
检查容器是否真按顺序启动
执行 docker-compose up -d 后，用以下命令观察实际启动节奏：
-
docker-compose ps看各容器状态：如果db显示Up而web还是Restarting或Exit，说明顺序没错，但 web 启动时 db 尚未就绪 -
docker-compose events --json | jq 'select(.action=="start")'可实时捕获启动事件流，确认时间先后 - 注意：即使
db容器已Up，PostgreSQL 可能还在初始化数据库、加载扩展，耗时数秒到数十秒不等
验证依赖服务是否真正就绪
容器运行 ≠ 应用就绪。常见做法是加健康检查并配合等待逻辑：
- 为 db 加
healthcheck，例如 PostgreSQL 使用pg_isready，Redis 用redis-cli ping - 在 web 的启动命令前插入等待脚本，如
./wait-for-it.sh db:5432 -- npm start - 或改用
dockerize：dockerize -wait tcp://db:5432 -timeout 60s npm start - 关键点：等待目标必须是服务监听的端口 + 协议，不能只等容器 IP 可达（
ping没用）
日志里找真实失败原因
别只盯着 web 容器日志里“Connection refused”，要结合时间戳定位阻塞源头：
- 查 web 启动失败的具体时间：用
docker logs web --since "2026-09-16T07:30:00"锁定窗口 - 同一时间查 db 日志：
docker logs db --since "2026-09-16T07:30:00"，看是否刚打印出database system is ready to accept connections - 如果 db 日志里该行出现在 web 报错之后，说明 web 启动太快，没等 db 就绪
- 若 db 日志卡在初始化阶段（如
creating template1），说明需要调高healthcheck的retries或延长timeout
