Docker健康检查核心是HEALTHCHECK指令配合合理参数：退出码0为健康、1为不健康；推荐curl -f确保HTTP非2xx返回非零码；关键参数--interval（30s～60s）、--timeout（依依赖响应设）、--start-period（覆盖冷启动）、--retries（建议3）需协同配置；失败后需结合--restart=on-failure或编排工具实现自动恢复。
在Docker中配置健康检查，核心是用好HEALTHCHECK指令，并搭配合理的重试参数，让状态判断既灵敏又不误判。
健康检查命令要返回明确退出码
健康检查依赖命令的退出状态：0 表示健康，1 表示不健康（2 保留不用）。不能只靠输出内容判断。
- HTTP服务推荐用
curl -f http://localhost:8080/health，-f保证非2xx响应时自动返回非零码 - 避免裸写
curl http://...——它成功连上就返回0，哪怕后端返回500也判为健康 - 若用自定义脚本（如检查DB连接+磁盘空间），务必在所有失败分支末尾写
exit 1，成功路径结尾写exit 0
四个关键参数必须协同设置
仅写命令不够，--interval、--timeout、--start-period、--retries 共同决定判断逻辑是否可靠。
- interval：建议30s～60s。太密增加负载，太疏延迟发现故障
- timeout：设为最慢依赖环节响应时间的1.5倍。例如DB平均200ms，这里设300ms；默认30s极易掩盖性能退化
- start-period：冷启动宽限期，必须覆盖应用完全就绪所需时间。Web服务常见60s，数据库从库可能需120s
- retries：设为3较稳妥。连续3次失败才标为unhealthy，能过滤瞬时抖动，但不宜设太高（如5+），否则故障暴露滞后
重试失败后触发可控恢复动作
Docker本身不自动重启，但可通过组合配置实现“检测失败→重建容器”的闭环。
- 在
docker run中加--restart=on-failure:3，配合健康检查，失败后最多重启3次 - 在
docker-compose.yml中写restart: on-failure+healthcheck:块，容器被标为unhealthy时自动重建（数据卷和网络保持） - 生产环境建议上Kubernetes或Swarm：它们能基于健康状态做滚动更新、节点隔离，甚至调用webhook通知人
验证与防坑要点
配完别急着上线，先看三件事：
- 进容器手动执行一遍健康命令，确认它真能反映业务可用性（比如断掉DB再试）
- 用
docker inspect --format='{{json .State.Health}}' 容器名查看实时状态，重点关注FailingStreak和Log.Output - 禁用
restart: always，改用on-failure+ 健康检查——否则进程卡死但健康检查没跑，容器永不重启
