Docker中无内核级启动优先级，需结合depends_on与healthcheck控制启动顺序和服务就绪；推荐docker-compose中用condition: service_healthy配合健康检查，或通过入口脚本主动等待，辅以资源限制实现软优先级。
在 Docker 中，“启动优先级”本身不是内核级调度概念，实际要解决的是容器启动顺序和服务就绪依赖两个问题。Docker 原生不保证服务内部是否真正可用，只控制进程是否 running；因此配置依赖关系必须结合启动顺序 + 就绪检查，才能避免“容器已启、服务未就绪”导致的失败。
用 docker-compose 的 depends_on + healthcheck 精确控制依赖
这是生产环境最推荐的方式，既声明启动先后，又验证服务真实可用。
- depends_on 只控制容器启动顺序，不等待服务就绪（比如 MySQL 容器 running 后可能还要初始化十几秒）
- 必须配合 healthcheck，让 Docker 持续探测目标容器的业务端点（如
/health或数据库连通性） - 在依赖方使用
condition: service_healthy，确保只有被依赖容器健康后才启动
示例：Redis 服务就绪后，Spring Boot 应用才启动
services:
redis:
image: redis:7-alpine
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 3
app:
image: my-springboot-app:latest
depends_on:
redis:
condition: service_healthy
environment:
SPRING_REDIS_HOST: redis
通过入口脚本主动等待依赖服务就绪
适用于无法修改 compose 文件、或需兼容旧版 Docker 的场景。核心思路是：容器启动时，先执行一个检测脚本，确认依赖服务可连通再 exec 主进程。
- 用
nc -z host port或curl -f http://host:port/health循环探测 - 设置超时和重试次数，避免无限等待（例如最多等 120 秒，每 2 秒试一次）
- 把等待逻辑写进容器的
entrypoint.sh，并在 Dockerfile 中指定
常见错误：只检测端口开放（如 telnet db 3306），但 MySQL 可能正在初始化——建议直接用客户端命令验证协议层就绪（如 mysqladmin ping -h db -u root -proot --silent）。
资源层面的“软优先级”：内存与 CPU 限制协同保障
虽然不能直接设“启动优先级”，但可通过资源约束影响容器在竞争中的稳定性，间接体现优先级差异：
- 给关键服务（如数据库）分配明确内存上限 + 较低 OOM 分数：
--memory=2g --oom-score-adj=-500 - 给临时任务或批处理容器提高 OOM 分数：
--oom-score-adj=400，使其在内存紧张时更早被回收 - CPU 方面，用
--cpus=1.5限制非关键容器，避免其突发占用挤占核心服务资源
⚠️ 注意：--oom-score-adj 必须配合 --memory 才有效；不设内存限制时，该参数失去上下文意义。
Swarm 和自定义编排中更严格的依赖表达
在 Docker Swarm 中，depends_on 不可用，但可通过以下方式强化依赖语义：
- 使用
deploy.order_before（部分版本支持）显式声明顺序 - 在 service 的
healthcheck中定义完整就绪逻辑，并在上游服务的启动命令里加until curl -f http://downstream:8080/ready; do sleep 2; done && exec your-app - 借助外部协调器（如 Consul 或 etcd）实现服务注册+健康发现，由应用自身决定何时开始工作
这种方式更适合多节点集群，但复杂度明显上升，中小项目优先走 compose + healthcheck 路线。
