使用 entrypoint 覆盖是实现多服务启动前预检最可靠的方式，需封装前置检查、初始化、主进程启动三步，支持并行/串行等待、超时控制，并与 healthcheck 配合提升鲁棒性。
直接用 entrypoint 覆盖是实现多服务启动前预检最可靠的方式之一。它把等待、校验、初始化等逻辑封装在容器启动的第一步，不依赖外部调度，也不受 depends_on 的“仅启动不就绪”限制。
entrypoint 脚本必须能接管整个启动流程
镜像的默认 ENTRYPOINT（如果有）会被 docker-compose.yml 中定义的 entrypoint 完全覆盖。因此脚本需自行完成三件事：前置检查 → 初始化动作 → 启动主进程。常见错误是只做等待却忘了 exec "$@"，导致应用没起来。
- 脚本开头加
#!/bin/sh，确保可执行 - 结尾必须用
exec "$@"或明确调用主命令（如gunicorn app:app），否则容器会退出 - 所有依赖工具（如
pg_isready、mysqladmin、curl）需提前装入镜像
支持多依赖并行或串行等待
一个 entrypoint 脚本可以同时检查多个服务是否就绪，比如数据库 + Redis + 配置中心。用后台任务+计数器，或逐个 until 循环，避免因某一项失败阻塞全部。
- 串行示例：先等 PostgreSQL，再等 Redis，最后等 API 网关
- 并行示例：用
&启动多个检测进程，用wait汇总结果 - 超时控制很重要，建议每项等待设最大重试次数（如 60 次 × 2 秒 = 2 分钟），超时则
exit 1
与健康检查（healthcheck）配合提升鲁棒性
entrypoint 负责“启动前等”，healthcheck 负责“运行中保活”。两者搭配，能让依赖链更稳。例如：
- db 服务配置
healthcheck使用pg_isready，返回非零即不健康 - app 服务的
entrypoint在启动前调用curl -f http://db:5432/health或直接复用同一检测逻辑 - compose 文件中仍保留
depends_on: { db: { condition: service_healthy } }作为兜底
实际脚本结构建议
一个生产可用的 entrypoint.sh 通常包含四段：
- 环境准备：设置默认变量、加载 .env、验证必要 env 是否存在
-
依赖预检：对每个
depends_on服务做端口连通性或 HTTP/DB 协议级探测 - 初始化操作：执行迁移、加载 seed 数据、生成 config.toml、chown 目录等
-
启动主程序：用
exec "$@"执行原始 CMD，保持命令可覆盖性
