健康检查应避免过频、过重、过急，合理配置后几乎无开销：调整频率（非核心60–120秒、web类20–45秒）、精简逻辑（仅进程存活+端口连通）、设合理超时（3–8秒）与重试（3次）、按需启用。
健康检查本身不该拖慢业务，关键在避免“查得太勤、判得太急、测得太重”。合理配置后，它几乎不产生可感知开销。
调整检查频率，避开高频轮询
默认每30秒检查一次对多数服务已偏高，尤其当容器数量多或健康端点本身有计算开销时。频繁调用会增加CPU、网络和应用层压力，还可能因瞬时负载抖动触发误判。
- 非核心服务（如日志处理、定时任务）可设为 60–120 秒 间隔
- Web/API类服务建议 20–45 秒，兼顾响应速度与系统负载
- 避免低于 10 秒——Docker 自身调度和命令执行也有延迟，过密检查反而降低准确性
精简健康检测逻辑，用轻量探针
别让健康检查变成业务压力测试。一个 HTTP /health 端点如果要查数据库连接、读配置、验缓存，就失去了“快速反馈”的意义。
- 只做最小必要验证：进程存活 + 主端口可连 + 内存/线程无明显异常（如 Go 的
/healthz默认只返回 200） - 依赖型服务（如需 DB 可用）可另设
/ready端点，由编排工具（如 Kubernetes readinessProbe）单独调用，不混入基础健康检查 - 避免在健康脚本中执行磁盘扫描、大文件读取或远程 API 调用
合理设置超时与重试，减少状态震荡
超时太短易被网络抖动或 GC 暂停干扰；重试太少容错差，太多又延长故障识别时间。
- --timeout 建议设为 3–8 秒：比业务平均响应时间高 2–3 倍即可，不追求极致低延迟
- --retries 推荐 3 次：既过滤偶发失败，又不会让异常容器长期滞留 unhealthy 状态
- 搭配 --start-period（如 30–60 秒）：给慢启动应用（Java/Spring Boot）充分初始化时间，避免启动期被误杀
按需启用，不监控所有容器
不是每个容器都需要健康检查。Sidecar、临时工具容器、批处理作业等开启健康检查纯属冗余，徒增 Docker daemon 负担。
- 仅在
docker-compose.yml或Dockerfile中为真正需要自愈保障的服务启用 HEALTHCHECK - 使用标签控制范围：例如通过
AUTOHEAL_CONTAINER_LABEL: "autoheal=true"让 autoheal 工具只盯关键服务 - 对静态镜像（如 nginx:alpine）可直接复用其内置健康检查，无需额外加脚本
