docker compose 不支持服务优先级调度，核心是确保依赖服务真正就绪：depends_on 仅控制启动顺序，healthcheck + condition 实现健康状态等待，入口脚本（如 wait-for-it.sh）提供灵活端点探测，辅以资源限制与重启策略提升可靠性。
在 Docker Compose 中，“服务优先级启动队列”并不是一个原生支持的概念，Docker 本身不提供类似操作系统的进程优先级调度。实际要解决的是依赖服务必须先就绪，当前服务才能安全启动这一核心问题。关键在于区分“容器启动完成”和“服务真正可用”——前者由 depends_on 控制，后者必须靠健康检查或主动等待机制保障。
用 depends_on 声明基础启动顺序
这是最基础的依赖声明方式，仅控制容器创建与启动的先后次序，不等待服务内部准备就绪。
- 语法简单：在依赖方服务中添加
depends_on: [service-name] - 支持多个依赖，按列表顺序依次启动（但不保证并行或严格串行）
- 例如数据库必须在 Web 应用前启动：
web:<br> depends_on:<br> - db<br> - redis
- ⚠️ 注意：PostgreSQL 容器 running 后可能还需 10–20 秒完成初始化，此时 Web 连接会失败
用 healthcheck + condition 实现真实就绪依赖
这是生产环境推荐做法，把“服务是否可用”变成可检测、可等待的状态。
- 被依赖服务需定义
healthcheck，例如检测 MySQL 是否能响应查询：mysql:<br> healthcheck:<br> test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "--password=pass"]<br> interval: 15s<br> timeout: 5s<br> retries: 5
- 依赖方使用
condition: service_healthy：app:<br> depends_on:<br> mysql:<br> condition: service_healthy
- Compose 会持续轮询目标服务健康状态，只有返回
healthy才启动当前服务
用入口脚本主动等待依赖端点就绪
适用于无法升级 Compose 版本、或需更灵活判断逻辑（如 HTTP 状态码、自定义探针）的场景。
- 将等待逻辑写入容器启动命令，例如使用
wait-for-it.sh或自研脚本 - 示例（Dockerfile 中）：
CMD ["sh", "-c", "wait-for-it.sh db:5432 --timeout=60 --strict -- spring-boot:run"] - 脚本会持续尝试 TCP 连接，成功后才执行主进程；失败则退出，触发
restart: on-failure - 比单纯端口探测更可靠的做法是结合业务接口，比如
curl -f http://config:8888/actuator/health
补充策略：资源限制与启动节奏控制
虽不能设“优先级”，但可通过资源配置间接影响启动表现。
- 为关键基础设施（如注册中心、配置中心）分配更高
mem_reservation或更低oom_score_adj，降低被系统 OOM 杀死风险 - 用
start_period延长健康检查初始等待时间，避免因服务冷启动慢而误判失败 - 对非关键服务启用
restart: unless-stopped，配合重试逻辑容忍短暂依赖不可用
