Compose 启动顺序需要明确的就绪条件
Docker Compose 描述服务依赖图，并可以按声明关系启动服务。进程启动只是图中的一种条件：数据库或 API 可能已经运行，却还不能接受其他服务需要的操作。显式 service_healthy 条件让 Compose 在启动依赖方之前，等待被依赖服务的健康检查通过；前提是这个检查确实表达有意义的就绪状态，而不是随意返回成功。 坏掉的样子 简短 depends_on 形式建立启动顺序，却不建立应用就绪保证。用固定 sleep 替代也很脆弱，因为初始化时间会随存储、缓存、迁移和机器负载变化。同一段等待在某次运行中过长，在另一次又不足。条件应来自可以观察的依赖行为，而不是估计已经过去多久；否则构建机变快或变慢，都可能暴露新的偶发故障。 基于健康状态的依赖条件，也不是持续可用性保证。依赖方启动之后，被依赖服务仍可能失败或重启。Compose 不会仅因依赖后来变得不健康，就自动停止或重启已经运行的依赖方。应用仍需要处理连接中断、有界重试，以及操作可能部分完成的情况，不能把启动编排当成完整运行期容错。 嵌套在依赖项里的 restart: true，与服务自身重启策略含义不同。它针对显式 Compose 操作更新或重启依赖后，对依赖方进行相应重启，不是对每一次健康转换或引擎级崩溃的通用订阅。相似字段名容易造成误解，应按照配置层级和文档契约区分，而不是看到 restart 就认为所有失败都会触发。 快速验证 使用宿主 Python、Docker Compose 和固定 Python 镜像运行脚本。实测为 Compose 5.1.1、Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16。脚本用 YAML 接受的 JSON 语法写 Compose 文档，创建唯一项目，所有 HTTP 访问都留在项目网络中。清理只移除该项目，不影响其他服务： ...