速查在线工具箱Docker Compose 里 depends_on 写了，为什么服务还是起不来？
depends_on 保证的是「谁先启动」，不是「谁先就绪」。数据库进程起来了但还没能接受连接，应用照样连不上。
depends_on 的短写法只保证一件事：被依赖的容器先被启动。它不会等待对方「准备好」，而多数服务从进程启动到能对外服务之间有明显的空窗期。
Compose 的长写法提供三种条件：等待对方启动、等待对方健康、等待对方执行完成。要用「等待健康」，目标服务必须自己定义健康检查，否则这个条件无从判断。
更保险的做法是双层保险：编排层用健康条件控制启动顺序，应用层自己做连接重试与退避。因为就算健康检查通过，网络或权限问题仍可能让第一次连接失败。
本地开发时把一整套服务用一份编排文件拉起来，最恼人的报错往往是「连接被拒绝」——日志显示应用启动得比数据库还早。这属于依赖语义被误解的典型场景。
这一篇讲清启动顺序、就绪状态与重试三者各自负责什么，以及健康检查该怎么写。
1三种依赖条件各保证什么
把「启动」和「就绪」当成两件事，下面的对照就顺了。
| 写法 | 保证的事 | 不保证的事 |
|---|---|---|
depends_on 短写法 | 被依赖容器先创建、先启动 | 对方是否已能接受连接 |
| 等待启动完成 | 对方进程已开始运行 | 端口是否已监听、初始化是否结束 |
| 等待健康 | 健康检查已判定通过 | 业务层是否已加载完数据 |
| 等待执行完成 | 一次性任务已跑完退出 | 结果是否满足业务前置条件 |
顺序控制解决的是「谁先起」，可用性控制解决的是「能不能用」。两者不是同一件事。
2健康检查怎么写
健康检查就是一条能被容器内执行的探测命令。它必须有明确的成功与失败退出码，并且要留出「刚启动还没好」的宽限期，否则容器会在初始化完成前就被判为不健康。
| 要素 | 作用 | 取值建议 |
|---|---|---|
| 探测命令 | 返回成功码表示健康 | 用服务自带的就绪探测，不要用端口扫描代替 |
| 间隔与超时 | 多久探一次、单次等多久 | 间隔略大于正常响应时间，超时给足余量 |
| 重试次数 | 连续失败几次判为不健康 | 给 3 到 5 次，避开偶发慢查询 |
| 启动宽限期 | 初始化期间不判失败 | 按冷启动耗时设置，宁可略长 |
健康检查写得太严格，反而会把「启动慢」误判成「服务坏了」，于是容器被反复重启，永远起不来。
3应用侧的重试不能省
编排层的依赖条件只能覆盖启动时刻，运行期的抖动（对端重启、网络重连）它管不到。所以应用自身的重试逻辑仍然是必要的。
- 连接失败就退避重试
- 第一次等待一秒、之后逐步拉长，避免瞬间打爆对端
- 区分可重试与不可重试的错误
- 网络类错误重试，参数与权限类错误立即报错，不要无脑重试
- 给重试设上限
- 无限重试会让真正的配置错误被掩盖，最后表现为「一直卡住不报错」
- 留出可观测的日志
- 打印每一次重试与最终失败原因，否则排查时只能靠猜
把重试当成对依赖条件的兜底，而不是替代它。只做重试不做顺序控制，启动期间会产生大量无谓的错误日志。
顺着这个问题往下用
全部工具总览 →相关疑问
为什么数据库容器已经运行了，应用还是连不上？
「运行中」指的是进程还活着，不代表它已经完成初始化并能接受连接。这类空窗期只能靠健康检查判断。
健康检查会不会把启动慢的服务判死？
会，如果没设启动宽限期。初始化阶段应该允许它暂时不健康，等宽限期过后再开始计入失败次数。
写 version: 那行会报错吗？
不会报错，但新版编排会提示该字段已废弃。现代写法不需要它，直接写服务定义即可。
只加重试不写依赖条件可以吗？
能跑通但体验差：启动瞬间会刷出大量连接失败日志，排查真实问题时会被淹没。两者配合才是完整方案。
继续看：相关问题与资料
全部问题解答 →内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-10。若发现错误，欢迎通过页脚反馈入口告知。