depends_on仅控制容器启动顺序，不保证服务就绪；需结合healthcheck与condition: service_healthy实现真正依赖等待，或在应用层用wait-for脚本主动探测。
靠 depends_on 本身并不能真正控制启动时序——它只保证容器进程先拉起来，不保证服务已就绪。要实现可靠的多容器启动时序，关键在于把“容器启动”和“服务可用”区分开，并用可验证的手段等待后者。
依赖声明只是起点：depends_on 的真实作用
depends_on 是 Docker Compose 中最常用也最容易被误解的机制。它仅影响容器创建和启动的先后顺序，即：
- Compose 会按依赖关系拓扑排序，先启动 db，再启动 web
- 但一旦 db 容器的主进程（如 postgres）开始运行，Compose 就认为它“启动完成”，立刻启动 web
- 此时 PostgreSQL 可能还在初始化数据目录、加载扩展、恢复 WAL 日志——web 连接必然失败
让服务真正“就绪”：healthcheck + condition 组合
要让下游服务等到上游真正可服务，必须结合 healthcheck 和 depends_on 的 condition 模式：
- 为 db 服务定义
healthcheck，用实际协议探测（如pg_isready或curl -f http://localhost:8080/health） - 在 web 的
depends_on中指定condition: service_healthy - Compose 会轮询 db 的健康状态，直到返回 success 才启动 web
示例配置片段：
services:
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 10
web:
build: .
depends_on:
db:
condition: service_healthy
应用层主动等待：更灵活的兜底方案
当 healthcheck 不够用（比如依赖外部 API、需检查特定表结构或缓存预热），推荐在应用容器启动前插入等待逻辑：
- 把
wait-for类脚本作为容器 entrypoint 或 command 的前置步骤 - 脚本内使用
nc -z host port、curl --fail或语言原生 client（如 Python 的psycopg2.connect(..., connect_timeout=2)）重试探测 - 避免无限等待，设置最大重试次数与超时退出，防止阻塞整个编排
例如在 app 的 Dockerfile 中设入口点：
ENTRYPOINT ["./wait-for-db.sh"] CMD ["gunicorn", "app:app"]
网络与初始化协同：别忽略底层约束
即使时序控制得当，仍可能因网络或初始化问题失败：
- Docker 默认桥接网络 DNS 解析有时延迟，建议显式配置
networks并启用dns_opt加速解析 - PostgreSQL 等服务首次启动会初始化数据目录，耗时较长；配合
init容器或命名卷预置数据可缩短冷启时间 - 避免在容器启动命令中直接执行数据库迁移——应由应用自身在就绪后触发，或拆分为单独的 init 容器
