docker容器健康检查通过healthcheck指令配置，核心是周期性执行cmd命令（如curl -f http://localhost:8080/health || exit 1），依据退出码0/1判定healthy/unhealthy；关键参数包括--interval、--timeout、--start-period和--retries，需结合应用启动时长与业务端点合理设置。
dockerfile 中通过 healthcheck 指令定义容器健康检查逻辑，让 docker 能主动判断应用是否真正就绪、是否仍在正常提供服务，而不仅依赖进程是否存活。
HEALTHCHECK 基本语法与常用写法
标准格式为：
HEALTHCHECK [OPTIONS] CMD command其中 CMD 后跟的是在容器内执行的 Shell 命令（推荐使用完整路径，避免依赖 PATH）；常用选项包括：
- --interval=30s：两次检查间隔，默认 30 秒
- --timeout=3s：单次检查超时时间，超时即视为失败
- --start-period=5s：容器启动后等待多久再开始首次检查，给应用留出初始化时间
- --retries=3：连续失败多少次才将状态设为 unhealthy
例如，对一个监听 8080 端口的 Web 应用，可写成：
选择合适的健康检查端点或方式
不建议直接用 curl http://localhost:8080/ 这类首页检测，因为首页可能返回 200 却不反映真实业务状态。应优先使用应用提供的专用健康端点，如：
-
/health或/actuator/health（Spring Boot） -
/ping（某些 HTTP 服务） -
/status（自定义轻量接口）
若应用无 HTTP 接口，可用其他方式验证核心依赖是否就绪，比如：
- 检查数据库连接：
mysqladmin ping -h db -u user -ppass --silent - 检查本地 socket 文件是否存在：
test -S /var/run/app.sock - 调用 CLI 工具输出关键状态：
redis-cli ping | grep PONG
注意命令执行环境与权限问题
HEALTHCHECK CMD 在容器内以 root 用户执行（除非指定了 USER），但实际命令可能受限于以下因素：
- 容器中未安装
curl或netcat？建议基础镜像包含必要工具，或改用sh -c 'echo > /dev/tcp/localhost/8080 2>/dev/null'（需启用 bash 的/dev/tcp支持） - 应用监听
127.0.0.1而非0.0.0.0？健康检查命令无法访问，需确保监听地址允许本地回环访问 - 应用启动慢于默认
start-period？务必设置足够长的--start-period，否则容器刚启动就被标记为 unhealthy
验证和调试健康检查行为
构建并运行后，可通过以下命令观察效果：
-
docker ps查看 STATUS 列是否显示healthy、unhealthy或starting -
docker inspect <container> | jq '.[0].State.Health'</container>查看详细健康状态、最近一次检查结果与输出 - 手动进入容器执行相同命令，确认返回值是否符合预期（成功返回 0，失败返回非 0）
如果始终显示 unhealthy，重点检查命令退出码、网络连通性、端口绑定方式以及日志输出（Docker 默认不显示 healthcheck 输出，可通过 inspect 查看历史输出）。
