容器显示“Up”并不等于应用真正可用：主进程可能仍在运行，但服务已经死锁、端口无法响应，或者数据库尚未完成初始化。Docker 健康检查可以定期执行探测命令，并将容器标记为 starting、healthy 或 unhealthy，为故障发现和依赖服务启动提供更可靠的依据。🩺
一、理解 Docker 健康状态
未配置健康检查时，Docker 主要依据容器主进程是否退出判断运行状态。加入 HEALTHCHECK 后，Docker 会在容器内部周期性执行指定命令：返回码为 0 表示本次检查成功，返回码为 1 表示失败，返回码 2 为保留值，不建议使用。相关语法和行为可参考 Dockerfile 官方文档。
- starting：容器处于启动或宽限阶段，尚未得出最终健康结论。
- healthy：最近一次健康检查成功，服务当前可响应探测。
- unhealthy：连续失败次数达到设定阈值，需要立即排查。
需要特别注意，unhealthy 只是健康状态，并不代表容器已经停止。对于普通独立容器，Docker 通常不会仅因状态变成 unhealthy 就自动重启；重启策略主要针对容器进程退出。因此，生产环境还应结合监控告警、编排平台或外部恢复机制。⚠️
二、在 Dockerfile 中配置 HEALTHCHECK
一个常见的 HTTP 服务检查可以写成：
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
CMD curl -fsS 来源链接 || exit 1
其中，interval 表示检查间隔；timeout 表示单次检查允许执行的最长时间；start-period 为应用预留启动宽限期；retries 表示连续失败多少次后标记为 unhealthy。参数不应机械照搬，应根据应用启动时间、接口响应速度和可接受的故障发现时长进行调整。
健康检查命令使用的是容器内部环境。镜像中必须确实包含 curl、wget、pg_isready 等工具，否则应用即使正常，检查也会因“命令不存在”持续失败。对于精简镜像或 distroless 镜像，可以在应用中提供轻量级检查程序，并使用 exec 形式直接调用。
探测目标如何选择
检查接口应轻量、稳定且能够反映核心依赖状态。只检查进程存在意义有限；检查首页又可能触发复杂业务逻辑。更合理的方式是提供专用的 /health 或 /ready 接口，验证线程池、数据库连接等关键能力，同时避免执行写操作、全表查询或访问不必要的第三方服务。🎯
三、在 Compose 中定义健康检查
Compose 服务可以通过 healthcheck 字段覆盖或补充镜像配置，例如：
healthcheck:
test: ["CMD-SHELL", "wget -q --spider 来源链接 || exit 1"]
interval: 30s
timeout: 5s
retries: 3
start_period: 20s
多容器应用中，仅写 depends_on 通常只保证启动顺序，不代表依赖服务已经可以处理请求。若应用必须等待数据库就绪，可使用 condition: service_healthy，让上游服务通过健康检查后再启动下游服务，具体行为可参阅 Compose 启动顺序说明。不过，应用自身仍应实现连接重试和退避策略，避免把全部可靠性寄托在启动阶段。
四、容器状态异常的排查顺序
- 确认整体状态：执行 docker ps -a，查看容器是否为 Up、Exited、Restarting，以及是否附带 unhealthy。
- 查看检查记录：执行 docker inspect 容器名，重点检查 State.Health.Status、FailingStreak 和 Log，最后几次记录通常包含返回码与错误输出。
- 检查应用日志：执行 docker logs --tail 200 容器名，必要时增加时间范围，判断是否存在启动失败、连接超时、权限不足或内存异常。
- 进入容器复现：执行 docker exec -it 容器名 sh，然后手动运行健康检查命令。这样可以快速发现工具缺失、路径错误、环境变量为空或证书不可用等问题。
- 核对资源和网络：通过 docker stats 观察 CPU、内存和进程情况，同时确认监听地址、容器端口、DNS、网络连接及安全策略。
常见异常与修复方向
- 一直处于 starting：检查探测命令是否卡住，并确认 timeout、interval 与 start-period 是否合理。
- 启动后很快 unhealthy：应用初始化时间可能长于宽限期，可适当增加 start-period，但不要用过大的数值掩盖真实故障。
- 宿主机访问正常、内部检查失败：检查服务是否只监听特定地址，容器内部端口是否写错，以及 localhost 所指向的位置是否符合预期。
- 检查偶发超时：排查资源争用、垃圾回收、连接池耗尽和下游延迟，并适当增加 retries，避免一次瞬时抖动触发误报。
- 重启后仍反复异常：不要持续手动重启，应比较健康检查日志与应用日志，定位配置、依赖或数据层面的根因。🔍
五、生产环境配置建议
健康检查应设置明确超时，命令本身也最好带连接和请求超时，防止探测进程长期占用资源。检查频率不宜过高，否则大量容器会形成额外负载；失败阈值也不宜过低，以免短暂网络波动造成误判。
同时要区分“存活”和“就绪”：存活检查用于判断应用是否需要恢复，就绪检查用于判断是否能够接收流量。对关键系统，还应监控健康状态变化事件、容器重启次数、接口延迟与业务指标，避免把健康检查当成完整的可观测性方案。📊
总结
Docker 健康检查的核心价值，是识别“容器进程仍在，但应用已经不可用”的隐性故障。配置时应选择能代表真实服务能力的探测目标，合理设置间隔、超时、启动宽限期和重试次数；排障时则按照状态、检查记录、应用日志、容器内复现、资源网络的顺序逐层定位。只有将健康检查与应用重试、日志监控、告警及恢复策略结合，才能构建稳定、可维护的容器运行体系。✅
