Docker容器健康检查需用HEALTHCHECK指令定义并贴近业务真实状态。参数需配对设置：--interval、--timeout、--start-period、--retries；检查命令应验证服务可用性而非仅进程存活；须配合重启策略实现自愈。
Docker 容器健康检查不是只写个 curl 就完事，关键是要让检查真实反映应用是否“能干活”，而不是仅仅“进程没死”。
最常用、也最推荐的方式是在 Dockerfile 中用 HEALTHCHECK 指令定义。它会嵌入镜像，所有基于该镜像启动的容器自动继承，省得每次 docker run 都重复配置。
核心参数要配对理解，不能孤立设置：
-
--interval=30s：每 30 秒执行一次检查（太短增加负载，太长故障发现慢） -
--timeout=5s：单次检查最多等 5 秒，超时即算失败（比服务实际响应时间略宽裕） -
--start-period=30s：容器刚启动的前 30 秒，失败不计入重试（给慢启动应用留缓冲） -
--retries=3：连续 3 次失败才标记为unhealthy（避免偶发网络抖动误判）
检查命令要贴近业务真实状态：
- Web 服务：优先用
curl -f http://localhost:8080/health，-f确保非 2xx 状态码直接报错 - Python 应用：可用内置模块减少依赖，比如
python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health', timeout=4)" - 数据库类容器：不能只看端口通，要真正连一下并执行简单语句，例如
mysql -h127.0.0.1 -uroot -p"$MYSQL_ROOT_PASSWORD" -e "SELECT 1" - 无 HTTP 接口的服务：写个小脚本检查关键文件、进程或业务指标（如心跳文件更新时间、队列积压量）
别忘了验证和联动：
- 启动后用
docker inspect <容器名> | grep -A 10 Health查看实时状态和最近结果 - 单靠健康检查不会自动重启，必须配合
--restart unless-stopped或--restart on-failure:5才能实现自愈 - 在 Docker Compose 中，可对单个服务覆盖镜像级配置，更灵活：
services: api: image: my-api:latest healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/ready"] interval: 10s timeout: 3s retries: 3 start_period: 40s
健康检查的本质，是把“应用是否可用”翻译成 Docker 能懂的退出码（0=健康，非0=不健康）。写得越贴近真实业务逻辑，越不容易漏掉假死、连接泄漏、依赖中断这类隐蔽问题。
