容器运行状态通常反映进程是否存在，不能直接代表业务服务已经可以处理请求。应用启动可能经历配置读取、缓存预热、数据库连接建立、迁移检查或模型加载。若调度系统过早发送流量，用户会看到启动期错误；若检查器把短暂依赖故障当作进程失效，又可能触发重启循环。健康检查的设计应从失败结果将触发什么动作开始。🚦
存活检查判断进程是否仍在工作，失败通常意味着需要重启实例，例如主事件循环长期阻塞或内部状态无法自行恢复。就绪检查判断实例是否可以接收新请求，失败通常应暂时停止向该实例分配流量，待条件恢复后再加入。应用尚在初始化时，启动检查可以提供更长的启动窗口，避免存活检查过早终止正常启动过程。
三者不可因为都叫“健康检查”就使用相同逻辑。依赖服务短时不可达时，服务也许可以继续处理缓存请求，或应拒绝全部请求；这取决于业务行为。如果把依赖不可达直接映射为存活失败，依赖故障会扩散为大量实例重启，给恢复中的依赖增加连接压力。🧭
只检查TCP端口只能证明某个进程正在监听，不能证明请求已进入应用处理路径。HTTP健康端点应在应用确认初始化完成后返回成功，并设置明确的成功码、超时和响应体判断。端点要轻量、无副作用，避免每次探测都执行昂贵查询或触发业务写入。
端点可按业务划分为浅层和深层：浅层只验证进程内部处理能力；深层可验证必须依赖的连接或关键状态。将深层依赖探测直接用于每个实例的存活判断，容易产生重启风暴。要明确每个探测由谁消费、失败时是摘流量还是重启，以及它是否适用于部署期间的流量门控。🔎
常见参数包括interval（探测间隔）、timeout（单次等待上限）、连续失败阈值和启动宽限时间。若服务正常启动时间的高分位数接近宽限期，检查可能在偶发慢启动时误判；若失败阈值很高，真实故障被发现的时间会延长。应结合启动耗时分布、实例故障恢复时间和业务容忍的不可用窗口选择参数，而不是仅按经验复制配置。
探测命令也必须真实存在于镜像环境中。精简镜像常不包含curl或shell工具；如果检查命令因此退出失败，服务健康状态会持续错误。可用应用原生探测端点或镜像内已有工具。容器运行时的状态可以通过只读命令docker inspect CONTAINER查看，包括最近检查结果和失败原因。🧰
将健康状态变化与重启次数、探测延迟、应用错误率、请求延迟、依赖连接错误和启动耗时放在同一时间线上。若探测失败但用户请求成功，可能是端点逻辑过深或阈值过紧；若探测成功但用户请求大量失败，端点可能只检查了监听端口，未覆盖实际处理路径。健康结果是运维信号，不是业务正确性的证明。
同时检查探测是否受资源争用影响。CPU饱和时，探针超时可能反映主机资源不足，而非应用死锁；应结合调度延迟和CPU限额判断。连续失败计数、状态切换频率和重启原因比单次成功/失败更能解释行为。📊
容易误判：健康端点返回成功只能证明端点定义的条件成立。应明确它覆盖哪些能力，并用真实请求路径、错误率和依赖指标补足。🛡️
