depends_on仅确保容器启动顺序，不保证服务就绪；需配合healthcheck（如pg_isready）或wait-for-it.sh脚本检测真实可用性，并避免循环依赖与yaml书写顺序误解。
depends_on 能让容器按你写的顺序启动，但它只管“容器跑起来了”，不管“服务能不能用”。想真正控制先后顺序并确保可用，得配合健康检查或脚本探测。
depends_on 基础写法：先启数据库，再启应用
这是最常用也最容易误解的写法。它只保证容器状态从 Created 变成 Running，不等数据库连得上。
- 在 docker-compose.yml 中声明依赖关系，比如 web 依赖 db：
- db 服务先启动，状态变为 Running 后，web 才开始创建容器
- 但 PostgreSQL 此时可能还在初始化系统表，pg_isready 还没响应
- 如果 web 应用一启动就尝试连接数据库，大概率报 Connection refused
加 healthcheck + condition：等服务真正就绪再启动
这才是官方推荐的可靠方式，需要两端配合：被依赖服务定义健康检查，依赖方指定等待条件。
- 给 db 加 healthcheck，例如用 pg_isready 检查 PostgreSQL 是否可接受连接：
- test: ["CMD-SHELL", "pg_isready -U postgres"]
- interval: 5s timeout: 5s retries: 10
- web 的 depends_on 改成带条件的形式（注意缩进和冒号后空格）：
- depends_on:
- db:
- condition: service_healthy
- 这样 web 会一直阻塞，直到 db 连续 10 次通过健康检查
用 wait-for-it.sh 脚本：兼容老镜像或复杂探测逻辑
当你用的是第三方镜像、没法改 healthcheck，或者需要验证 HTTP 接口、Redis PING 等更细粒度的状态，脚本更灵活。
- 下载脚本：curl -o wait-for-it.sh https://raw.githubusercontent.com/vishnubob/wait-for-it/master/wait-for-it.sh
- 给执行权限：chmod +x wait-for-it.sh
- 挂载进容器，并修改 web 的 command：
- command: ["sh", "./wait-for-it.sh", "db:5432", "--timeout=60", "--", "npm", "start"]
- 注意：它只检测 TCP 端口通不通，不验证协议层（比如不会发 HTTP GET 或 Redis PING）
避坑提醒：别信 YAML 书写顺序，也别写循环依赖
很多人以为把 db 写在 web 上面，就会先启动 db —— 这是旧版 Compose 的行为，现在完全无效。
- 启动顺序只由 depends_on 图谱决定，跟 services 在文件里谁先谁后没关系
- 没写 depends_on 的服务，默认并行启动，顺序不可预测
- 如果 A 依赖 B，B 又依赖 A，docker-compose up 会直接报错：Service 'A' is part of a circular dependency with 'B'
- depends_on 不传递依赖：web → db，db → redis，不意味着 web 自动依赖 redis；要显式写出来
