Docker容器依赖服务未就绪时需主动控制启动顺序：可用wait-for-it.sh做端口探测、应用内实现连接重试与指数退避、Docker Compose配置healthcheck+depends_on.condition、或用初始化容器预检依赖。
当 Docker 容器依赖其他服务（如数据库、Redis、消息队列等）时，主应用常因依赖未就绪而启动失败或崩溃。Docker 本身不提供内置的“等待依赖就绪”机制，需通过外部策略主动控制启动顺序和健康检查逻辑。
使用 wait-for-it.sh 脚本做简单端口探测
这是轻量、无额外依赖的常见方案：在应用启动前，先执行一个 Shell 脚本持续检测目标服务的 IP 和端口是否可连通。
操作方式：
- 将 wait-for-it.sh 下载到镜像中（例如 COPY 到 /usr/local/bin/），并赋予执行权限
- 修改容器启动命令，用它包裹主应用命令，例如：
cmd: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"] - 脚本默认每秒重试一次，超时 15 秒后失败；可通过环境变量调整，如 WAITFORIT_TIMEOUT=30
注意：它只判断 TCP 连通性，不验证服务内部状态（比如 PostgreSQL 是否已接受 SQL 连接）。
在应用内实现连接重试与指数退避
更健壮的做法是把等待逻辑下沉到应用代码中，避免容器层过度耦合。
建议做法：
- 启动时不要直接初始化数据库连接，而是封装带重试的初始化函数
- 首次连接失败后，等待 1–2 秒再试，后续间隔逐步拉长（如 1s → 2s → 4s → 8s）
- 设置最大重试次数（如 10 次）或总超时时间（如 60 秒），超时后明确报错退出
- Python 示例可用 tenacity 库，Go 可用 backoff 或标准库 time.Sleep + for 循环
配合 Docker Compose 的健康检查与 depends_on 条件启动
Docker Compose v2.3+ 支持 depends_on.condition: service_healthy，但前提是被依赖服务必须定义了 healthcheck。
配置要点：
- 为 db 服务添加 healthcheck，例如对 PostgreSQL 执行 pg_isready -U user -d dbname
- 在 app 服务中写明：
depends_on:
db:
condition: service_healthy - 注意：depends_on 不阻塞 docker-compose up 的返回，仅影响容器启动顺序；仍需应用自身容错
用专用初始化容器（init container）预检依赖
适用于 Kubernetes 场景，也可在 Docker Compose 中模拟（通过自定义启动顺序）。
思路是：
- 起一个临时容器，运行探活脚本（如 curl、nc、sql 查询等），成功后退出
- 主应用容器通过 restart: on-failure 或依赖该 init 容器的退出状态来决定是否启动
- Compos e 中可用 extends 或 profiles 分离 init 步骤，或用 Makefile / shell wrapper 控制流程
这种方式把“等待逻辑”从主应用剥离，职责更清晰，也便于调试和复用。
