Docker 健康检查怎么写？运行状态、就绪条件与故障处理
运行状态只说明主进程还在
本文适用于 Linux Docker Engine 和支持健康检查的 Compose 插件。进程可能活着却无法处理请求，也可能刚启动尚在加载配置。先确定检查要回答的问题：这个实例能否处理最基本的请求，还是整条业务链路都正常？把两者混成一个条件，容易在共享数据库故障时同时判坏所有应用。
建议让应用提供只读、快速且不返回敏感信息的内部健康端点。需要检查依赖时，限定检查时长与范围，不要每次都执行大查询、发送邮件或创建订单。探针需要能够代表服务能力，也不能变成新的业务负载。
检查命令必须存在于镜像内
健康检查在容器内部执行，不能因为宿主机装了 curl 就假设容器也能使用。以下片段适用于已把健康脚本放入镜像的服务：/app/healthcheck 必须是可执行文件，运行用户可访问，并且只在必要检查通过时返回退出码零；失败返回一，且自行限制网络等待。
services:
app:
healthcheck:
test: ["CMD", "/app/healthcheck"]
interval: 30s
timeout: 5s
retries: 3
start_period: 40s
这段配置不能代替脚本实现。可以让脚本使用应用已有的运行时向容器内真实监听地址发起请求，严格判断约定的成功状态码，并为异常提供简短原因。先在同一镜像、同一用户和同一环境下单独执行脚本，确认无权限、依赖或路径错误。Docker 健康检查规则
宽限期和重试次数各管一件事
interval 控制检查节奏，timeout 限制单次执行时间，retries 控制连续失败阈值。start_period 为启动提供失败宽限，并不是固定等这段时间才允许成功；应用提前通过检查后，后续失败会进入正常计算。参数应依据真实启动过程设置，不要直接把示例当作性能结论。
过短的超时可能把短暂资源争用当作故障，过长的间隔又会延迟发现异常。验证时记录正常启动、依赖暂不可用和恢复三种情况下的状态变化。如果检查本身依赖外部域名，DNS 故障也可能导致误报，应明确这种依赖是否属于目标。
健康状态不会自动等于重启
单独运行 Docker 容器时，unhealthy 标记本身不会让引擎自动重启容器；常见 restart 策略主要响应进程退出。其他编排或外部恢复程序可能据此执行动作，必须查看实际部署规则，不能把配置了 healthcheck 当作已配置自动修复。
Compose 可以通过 depends_on 的 service_healthy 条件等待依赖健康后启动服务，但这主要解决启动顺序，不保证运行期间依赖一直可用。应用仍需合理的连接重试、超时和降级；依赖中途故障不能靠最初等待一次解决。Compose 启动顺序
分清探针失败和应用失败再处理
先查看健康检查最近执行结果，再看同一时间的应用日志。如果输出是命令不存在，修改镜像或检查路径；如果请求被拒绝，核对实际端口和监听地址；如果应用返回依赖错误，沿着具体依赖排查。不要仅把重试次数不断调高来隐藏失败。
在测试环境模拟可控的依赖异常，确认失败与恢复都能被检测，且探针没有写入副作用。生产环境采用自然流量观察，不为验收主动中断业务。变更后出现误报时，恢复原检查配置并重新部署目标服务，保留错误记录用于完善探针；应用是否可用仍需独立验证。