Docker中“启动优先级”实为服务间逻辑依赖的时序控制，需通过healthcheck+depends_on.condition确保上游服务真正健康后下游才启动，而非仅依赖容器进程启动顺序。
在 docker 中，“启动优先级”不是指 cpu 或资源抢占意义上的优先级，而是服务间逻辑依赖的启动时序控制。微服务初始化失败，90% 是因为上游依赖（如数据库、redis、注册中心）容器虽已启动，但内部服务尚未就绪——docker 默认只管“容器进程起来”，不管“服务能不能用”。要真正解决初始化依赖，核心是让下游服务等上游服务真正健康后再启动，而非仅靠先后顺序。
用 healthcheck + depends_on.condition 实现可靠等待
这是目前最标准、最推荐的方式，适用于 Docker Compose v2.20+ / v3.4+。
- 为被依赖服务（如数据库）添加 healthcheck，定义它“算健康”的判断逻辑
- 在依赖服务中用 depends_on: {service: {condition: service_healthy}} 显式声明“必须等它健康”
- 健康检查命令需真实反映服务可用性，例如 PostgreSQL 用
pg_isready，MySQL 用mysqladmin ping，自定义服务暴露/health端点
示例（PostgreSQL + Web 应用）：
services:
db:
image: postgres:15
environment:
POSTGRES_DB: myapp
POSTGRES_PASSWORD: password
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d myapp"]
interval: 10s
timeout: 5s
retries: 10
web:
build: .
depends_on:
db:
condition: service_healthy
ports: ["8080:8080"]
避免只用 depends_on 的常见陷阱
depends_on 单独使用 = 伪依赖。它只确保容器进程启动完成，不验证服务状态。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- PostgreSQL 容器启动后可能还需数秒完成初始化、建库、加载 schema —— 此时连接会报
connection refused或database does not exist - Spring Boot 应用若配置了
spring.datasource.initialization-mode=always，更需等待 DB 就绪后才执行脚本 - Redis 启动快，但若应用依赖 Redis 的某个 key 初始化或 Pub/Sub 配置，也需主动探测
补充手段：入口脚本内嵌等待逻辑
当无法修改被依赖服务（如第三方镜像无健康端点），或需更细粒度控制（如等待某条 SQL 执行完），可在应用容器的启动命令前插入等待逻辑：
- 使用轻量脚本
wait-for-it.sh或dockerize工具，在 entrypoint 中检测目标 host:port 是否可连通 - 对数据库还可加 SQL 探测，例如：
until mysql -h db -u root -ppassword -e "SELECT 1"; do sleep 2; done - 注意：该方式把等待逻辑耦合进应用镜像，适合快速验证，长期建议统一走 healthcheck 方案
多层依赖与启动链管理
真实微服务常含三级甚至更多依赖（如：Config Server → Eureka → Gateway → Business Service）。此时需逐级设置 healthcheck 和 condition：
- Config Server 先健康 → Eureka 才启动并等待 Config 健康 → Gateway 再等 Eureka 健康
- 避免跨跳依赖（如 Gateway 直接 depends_on Config Server），应严格按调用链逐层声明
- 可配合
restart: on-failure让短暂失败的服务自动重试，提升容错性
