docker健康检查通过周期性执行命令判断服务是否真实可响应，而非仅检测进程存活；核心配置包括healthcheck指令（镜像级）和docker-compose.yml中healthcheck字段（容器级），需合理设置--interval、--timeout、--retries和--start-period参数，并使用curl -f等可靠命令验证业务端点。
直接在容器启动前定义检查逻辑，核心是让 Docker 能通过命令结果判断服务是否真能响应请求，而不是只看进程有没有跑起来。
用 Dockerfile 在镜像层配置
适合所有基于该镜像启动的容器，一次配置、处处生效。注意基础镜像得自带检查工具（比如 Alpine 需手动装 curl）：
-
基础写法：在 Dockerfile 末尾加一行 HEALTHCHECK 指令，例如
HEALTHCHECK --interval=30s --timeout=5s --retries=3 --start-period=60s \
CMD curl -f http://127.0.0.1:8080/actuator/health || exit 1 -
关键参数含义：
--interval：每 30 秒检查一次；
--timeout：命令执行超时为 5 秒，超时即算失败；
--retries：连续 3 次失败才标记为 unhealthy；
--start-period：容器启动后宽限 60 秒，期间失败不计数，避免 Spring Boot 类应用因初始化慢被误杀。 - 禁用继承的健康检查：如果基础镜像已有 HEALTHCHECK 但你不想要，写 HEALTHCHECK NONE 即可覆盖。
用 docker-compose.yml 在服务层配置
更灵活，推荐生产环境使用，尤其微服务中各组件启动耗时不同，可单独调参：
-
典型配置段：
healthcheck: test: ["CMD", "curl", "-f", "-s", "http://localhost:8080/health"] interval: 15s timeout: 8s retries: 3 start_period: 90s
- test 字段必须是数组格式，不能写成字符串（如 test: "curl -f..." 会报错）；
- start_period 要比应用实际冷启动时间略长，比如 Spring Boot 加载完数据库连接池+缓存通常要 40–70 秒，设 90s 更稳妥；
- 配合 restart: on-failure:5，能让不健康容器自动重启，但注意：Docker 不会仅因 health 状态变 unhealthy 就重启——它只在容器真正退出且退出码非 0 时触发；所以健康检查常和上层编排（如 Kubernetes）或脚本联动做下线/重建。
健康检查命令怎么写才靠谱
别只测端口通不通，要测业务是否就绪。常见误区是 curl 一个静态路径，结果服务挂着但数据库连不上也返回 200。
- Web 应用建议调用 /actuator/health（Spring Boot）或 /healthz（通用），且接口内部应校验下游依赖（如 DB 连接、Redis 可用性）；
- Java 应用可自定义接口逻辑，例如检查某个关键文件是否存在、某个配置是否加载成功，再决定返回 HTTP 200 还是 503；
- 避免用 ping 或 telnet 测端口，因为 TCP 握手成功 ≠ 应用能处理请求；
- curl 命令加 -f 参数很关键，它会让 curl 在 HTTP 状态码 ≥400 时返回退出码 22（非 0），从而被 Docker 正确识别为失败；不加 -f，即使返回 500，curl 默认仍返回 0。
怎么验证和排查
别等出问题才查，启动后立刻确认状态是否符合预期：
- 运行 docker ps，STATUS 列会显示 healthy、unhealthy 或 starting；
- 查详细日志：docker inspect --format='{{json .State.Health}}' 容器名，输出里有每次检查的起止时间、退出码、输出内容；
- 如果一直卡在 starting，大概率是 start-period 没设够，或者健康接口根本没监听（比如应用还没 bind port）；
- 如果频繁变 unhealthy，先看 inspect 输出里的 Output 字段，确认是超时、连接拒绝，还是返回了非 200 状态码，再针对性调 timeout 或修复接口逻辑。
