Docker健康检查需验证业务可用性而非仅进程存活，应使用应用暴露的/health端点或轻量探针，结合--start-period、--interval等参数适配启动节奏，并搭配unless-stopped等restart策略实现自愈。
实现 Docker 容器自动化健康检查，关键不是加个命令就完事，而是让 Docker 真正“看懂”你的服务是否能干活——它得验证业务逻辑是否可用，而不是只确认进程还在跑。
用 HEALTHCHECK 指令定义真实可用性检查
健康检查必须反映业务层面的可用性。比如 Web 服务，应调用 /health 或 /actuator/health 这类由应用暴露的真实端点；数据库服务，应执行简单 SQL 查询或使用专用工具验证连接与响应能力。
- 避免用
ps aux | grep myapp—— 进程活着不等于服务可用 - HTTP 类服务推荐
curl -f http://localhost:8080/health，-f确保非 2xx/3xx 返回非零退出码 - TCP 类服务（如 Redis、PostgreSQL）可用
nc -z localhost 6379，但要注意：端口通 ≠ 服务就绪，建议配合轻量级业务探针 - 复杂逻辑可封装成脚本（如检查 DB 连接 + 缓存响应 + 磁盘空间），
COPY到镜像并设为可执行，再在HEALTHCHECK中调用
参数设置要贴合应用实际启动节奏
很多容器反复重启，不是服务真坏了，而是健康检查太急——Java 应用还没加载完 Spring 上下文，检查就已失败。--start-period 就是为这类场景设计的缓冲期。
-
--start-period=40s：给慢启动应用留足初始化时间，期间失败不计入重试计数 -
--interval=30s：太频繁（如 5s）会增加负载；太宽松（如 5 分钟）故障发现滞后 -
--timeout=3s：确保检查本身不拖慢主服务，超时即判失败 -
--retries=3：连续 3 次失败才标记为 unhealthy，避免偶发网络抖动误判
搭配 restart 策略触发自动恢复
Docker 本身不因 unhealthy 状态直接重启容器，必须配合 restart 策略才能实现“自愈”。这个策略是在运行时指定的，和 HEALTHCHECK 是协同关系。
-
--restart=unless-stopped：最常用，Docker daemon 重启后也自动拉起，适合长期服务 -
--restart=on-failure:5：仅在容器非零退出时重启，最多重试 5 次（适用于希望控制重启次数的场景） - 注意：
unhealthy不等于退出，所以on-failure对健康检查失败无效；要用unless-stopped或always才能在状态变unhealthy后由编排工具（如 Swarm）触发重建
验证和调试不能跳过
配置完别急着上线，先本地验证命令行为是否符合预期——特别是异常情况下的退出码。
- 构建镜像后，用
docker inspect --format='{{json .State.Health}}' <container-id></container-id>查看健康配置是否生效 - 输出会显示
Status（starting/healthy/unhealthy）、FailingStreak和最近一次检查的Output - 手动执行健康检查命令（如
docker exec -it <container> curl -f http://localhost:8080/health</container>），确认返回码和响应内容符合预期
