dockerize通过-wait参数轮询依赖服务端口或HTTP健康端点，确保服务真正就绪后才启动应用，比仅依赖depends_on的启动顺序更可靠；支持多条件等待、超时控制，需集成在应用容器内并配合网络互通使用。
dockerize 本身不直接控制容器启动顺序，但它能通过等待依赖服务就绪（而非简单按 docker compose 启动顺序）来实现可靠的依赖就绪判断，这是比“依赖启动顺序”更健壮的做法。
用 dockerize 等待服务端口就绪
很多服务（如 PostgreSQL、Redis、MySQL）启动后需要几秒才能真正接受连接。dockerize 的 -wait 参数可轮询目标地址的 TCP 端口，直到成功建立连接才继续执行后续命令。
- 在应用容器的启动命令前加上
dockerize -wait tcp://db:5432 -timeout 30s -- -
db:5432是依赖服务的容器名和端口（需确保网络互通） -
-timeout 30s防止无限等待，默认超时是 30 秒，可按需调整 - 实际效果：应用容器会阻塞在 dockerize 这一步，直到数据库监听端口可连，再执行真正的启动命令（如
npm start或python app.py）
支持 HTTP 健康检查等待
如果依赖服务提供了 /health 或 /ready 这类 HTTP 接口，dockerize 也能等待返回 2xx 状态码：
dockerize -wait http://redis-exporter:9121/health -timeout 20s -- ./start-app.sh- 注意：HTTP 检查要求目标服务已响应且返回成功状态，单纯端口通还不行
- 适合 Spring Boot Actuator、Prometheus Exporter 等自带健康端点的服务
组合多个等待条件
一个应用可能依赖多个服务，dockerize 支持用多个 -wait 参数依次等待：
dockerize -wait tcp://db:5432 -wait tcp://cache:6379 -wait http://api-gw:8080/ready -- npm start- 所有条件满足后才执行
npm start；任一超时则整个容器启动失败 - 适合微服务中需同时等待数据库、缓存、配置中心等场景
配合 Docker Compose 使用的关键点
dockerize 必须运行在需要等待依赖的应用容器内，不是在依赖容器里：
- 在
docker-compose.yml中，只给 app 服务加 dockerize，db、redis 等保持原镜像和配置 - 确保 app 容器与依赖容器在同一网络（默认
default网络已满足） - 不要依赖
depends_on的“启动完成”语义——它只控制容器创建顺序，不保证服务就绪 -
depends_on可保留用于定义启动依赖关系（如避免 app 先于 db 创建），但必须搭配 dockerize 才真正可靠
注意：dockerize 不解决容器崩溃重启后的二次等待问题，也不替代服务自身的重试逻辑。它只是启动阶段的一次性就绪检查。
