docker健康检查通过定期执行命令（如curl -f访问/health接口）验证服务真实响应能力，而非仅检测进程存活；在dockerfile中用healthcheck指令配置，支持interval、timeout、start-period和retries参数，命令返回0才视为成功。
docker 容器健康检查不是看进程有没有在跑，而是验证服务能不能真正响应请求。它通过定期执行命令（比如访问 /health 接口），依据退出码 0/1 判断状态，从而避免“容器活着、服务挂了”的盲区。
怎么在 Dockerfile 中配置健康检查
这是最稳定、可复用的方式，把检查逻辑打包进镜像：
- 使用
HEALTHCHECK指令，一个 Dockerfile 只生效最后一个 - 推荐写法示例：
HEALTHCHECK --interval=20s --timeout=5s --start-period=40s --retries=3 \CMD curl -f http://localhost:8080/health || exit 1 -
关键细节：命令必须返回 0 才算成功；
curl -f会自动对非 2xx 状态码报错并返回 1；start-period给慢启动应用缓冲时间，期间失败不计数
怎么在 docker-compose.yml 中覆盖或补充健康检查
适合多服务编排场景，能灵活调整参数而不改镜像：
- 在 service 下添加
healthcheck块，会覆盖镜像中定义的 HEALTHCHECK - 推荐用数组格式写命令：
test: ["CMD", "curl", "-f", "http://localhost:8080/health"] - 注意：
start_period和retries必须是整数（如30），不能带单位（如30s）；timeout单位是秒，但值本身是数字
怎么看健康状态和排查问题
不依赖日志，直接查容器元数据：
- 快速查看当前状态：
docker inspect --format='{{.State.Health.Status}}' <container_name></container_name>
输出可能是starting、healthy或unhealthy - 查完整信息（含最近一次检查时间、输出、退出码）：
docker inspect --format='{{json .State.Health}}' <container_name></container_name> - 如果状态卡在
starting，大概率是start-period没过完，或首次检查就超时；如果反复变unhealthy，优先检查应用是否真监听了对应端口和路径，再确认网络连通性
怎么让健康检查真正起作用
光配检查不够，得配合调度与恢复机制：
- 在 Swarm 或 Kubernetes 中，健康状态直接影响任务调度和流量分发——不健康的实例会被自动剔除或重启
- 单机部署时，需搭配
--restart on-failure或unless-stopped启动参数，否则容器即使被标为unhealthy也不会自愈 - 生产环境建议：HTTP 探针优先于 TCP；健康接口应轻量、无副作用、不依赖外部资源（如 DB 连接池未建好时也应返回 200）；避免在健康检查里做耗时操作
