在ci/cd中复用docker原生健康检查可轻量、可信地判断服务就绪：通过healthcheck指令固化/readyz端点检查，配合--start-period和curl -f；部署后轮询docker inspect状态，超时中断；compose中用service_healthy依赖联动；测试阶段复用同一检查逻辑。
在CI/CD流程中直接复用Docker原生健康检查，能避免额外引入等待脚本或外部工具，让“依赖就绪”判断更轻量、更可信。关键不是等容器启动，而是等应用真实可服务——比如API端点返回200且DB连通、配置加载完成。
把健康检查逻辑固化进镜像
在Dockerfile里声明HEALTHCHECK指令，确保每次构建的镜像自带就绪判定能力：
- 使用
--start-period留出初始化时间，例如45秒，覆盖Spring Boot加载上下文、Hibernate建表等耗时操作 - 检查命令必须调用
/readyz这类业务语义端点，而非/health——前者验证DB连接池、Redis写入、配置项有效性；后者只确认进程存活 - 用
curl -f强制校验HTTP状态码，失败时显式exit 1，让Docker准确识别不健康状态
在CI/CD流水线中主动读取健康状态
部署后不直接发请求或跑测试，先确认目标服务容器已进入healthy状态：
- 执行
docker inspect <container-id> -f '{{.State.Health.Status}}'</container-id>，轮询直到输出healthy - 配合超时控制（如最多等待120秒），防止因配置错误无限挂起
- 若返回
unhealthy或starting，立即中断流水线并输出docker logs辅助定位
与Compose服务依赖联动使用
在docker-compose.yml中启用健康检查，并让下游服务通过depends_on绑定健康状态：
-
depends_on: {db: {condition: service_healthy}}比单纯service_started更可靠 - 数据库服务自身也应配置
HEALTHCHECK，例如用pg_isready -q验证PostgreSQL是否接受连接，而不仅是端口通 - 该组合能让CI/CD在本地或预发环境模拟K8s的
readinessProbe行为，无需改动代码即可实现依赖收敛
在测试阶段复用同一检查逻辑
集成测试前，用相同探针验证环境就绪，避免无效执行：
- 写一个简短shell循环：
until docker inspect my-app | grep -q '"Status":"healthy"'; do sleep 2; done - 跳过自建HTTP轮询脚本，减少维护点和环境差异风险
- 所有环节都基于同一个镜像定义的HEALTHCHECK，保证“就绪”定义始终一致
