Docker健康检查关键在于命令真实反映服务可用性，并通过--interval、--timeout、--start-period、--retries四参数避免误判；状态仅含starting/healthy/unhealthy三种，退出码0为健康、1为不健康、2禁用；推荐HTTP服务用curl -f调用/health端点，非HTTP服务检查进程、连接或文件锁，配置优先写入Dockerfile固化标准。
在 Docker 中配置健康检查，关键不是加一条命令，而是让检查逻辑真正反映应用是否能提供服务，并通过重试机制避免误判。健康状态只有三种：starting（启动中）、healthy（健康）、unhealthy（不健康），而判定依据是检查命令的退出码——0 表示健康，1 表示不健康，2 是保留值不能用。
写对健康检查命令
命令必须运行在容器内部，能真实验证服务能力。常见错误是只检查端口是否监听，却不管应用是否就绪。推荐方式：
- HTTP 服务：用 curl -f http://localhost:8080/health 或 wget --spider --quiet http://localhost/health，-f 参数确保非 2xx 状态码也返回非零退出码
- 无 HTTP 接口的服务：可检查进程、文件锁、数据库连接等，例如 pg_isready -q -d mydb 或 ls /tmp/app-ready && exit 0 || exit 1
- 复杂判断建议封装成脚本（如 check-health.sh），COPY 进镜像并赋予执行权限，再在 HEALTHCHECK 中调用
设好四个核心参数
仅靠命令不够，必须配合合理的时间与次数控制：
- --interval=30s：两次检查间隔。太短增加负载，太长延迟故障发现；Web 服务常用 15–30 秒，后台任务可放宽到 60 秒
- --timeout=5s：单次检查最长等待时间。应略大于正常响应耗时，比如 API 平均响应 1.2 秒，设为 3–5 秒较稳妥
- --start-period=40s：容器启动后等待多久才开始检查。Spring Boot、Node.js 等初始化慢的应用需设高些（20–90 秒），否则早期失败会直接计入重试
- --retries=3：连续失败几次才标记为 unhealthy。设为 2–3 较常见；设太高可能延误干预，设为 1 则易受瞬时抖动影响
两种主流配置方式
优先级：运行时（docker run / docker-compose） > 镜像（Dockerfile）。生产环境建议用后者统一标准，调试或差异化部署用前者覆盖：
-
Dockerfile 方式（推荐）：把健康逻辑固化进镜像，便于复用和版本管理
HEALTHCHECK --interval=20s --timeout=4s --start-period=60s --retries=2 \
CMD curl -f http://localhost:8080/actuator/health || exit 1 -
Docker Compose 方式（更灵活）：适合多服务协同场景，支持 JSON 数组语法防止 shell 解析问题
healthcheck:
test: ["CMD", "curl", "-f", "-s", "http://localhost:8080/health"]
interval: 15s
timeout: 6s
retries: 3
start_period: 75s
确认生效并观察状态
配置完成后不是就结束了，要验证它是否按预期工作：
- 启动容器后执行 docker ps，STATUS 列会显示 healthy、unhealthy 或 (health: starting)
- 用 docker inspect myapp | jq '.State.Health' 查看完整健康详情，包括最近几次检查的退出码、输出、时间戳和当前 FailingStreak（连续失败次数）
- 手动触发一次失败（如停掉内部服务），观察状态是否在 retries 次后变为 unhealthy；再恢复服务，确认能否自动回到 healthy
