核心思路是让健康检查“不被抖动带节奏”：通过start-period隔离启动期、timeout和interval协同放宽响应容忍、分层设计/ready与/health端点、避免外部依赖绑架容器状态，并优化宿主机网络基础配置。
核心思路是让健康检查“不被抖动带节奏”——不是压低检测频率，而是增强判断鲁棒性：隔离启动期、放宽单次响应容忍、分层验证依赖、避免把外部故障当自身问题。
延长启动宽限期（start-period）
很多误判发生在应用还没完全就绪时，健康检查就已开跑。比如 Spring Boot 服务常需 40–60 秒加载配置、连接数据库、预热缓存。
- 设 start-period=60s 或更长（如 90s），这段时间内所有失败都不计入重试计数
- 不要依赖默认的 0s 或 5s，那几乎等于没设
- Docker Compose 示例：start_period: 75s（注意 YAML 中是下划线）
调高单次超时并拉宽检查间隔
一次 DNS 解析慢、一次 Redis 连接抖动、一次 GC 暂停，都可能让 curl 卡在 3 秒超时上。这不是容器病了，是网络或依赖临时卡顿。
- timeout 设为 5–10s：比业务平均响应时间多留 2–3 秒缓冲
- interval 设为 20–30s：太密（如 5s）会把一次抖动放大成连续失败；太疏（如 60s）又延迟发现真实故障
- 避免盲目设 retries=5：它只防“连续失败”，不防“每次失败原因不同”。重点是先让单次检查稳住
拆分健康端点，分层验证关键依赖
把 /health 端点做成“全链路检查”，等于把数据库、Redis、第三方 API 的稳定性全部绑定到容器状态上——它们一抖，你的容器就被标记 unhealthy。
- 用 /ready 做轻量级就绪检查：只验进程存活、端口监听、本地文件锁或内存队列是否可写
- 用 /health 做全链路健康检查：才查 DB、Redis、外部 API，且每个依赖加独立超时（如 redis-cli -h redis --scan-timeout 1000 ping || exit 1）
- 健康检查命令指向 /ready，而不是 /health —— 尤其在 readiness 场景下
优化宿主机网络基础配置
再好的健康检查也架不住底层网络反复断连。很多“抖动”其实是宿主机转发、DNS 或网段冲突导致的。
- 确认 IPv4 转发已开启：sysctl -w net.ipv4.ip_forward=1 并写入 /etc/sysctl.conf
- 统一 Docker DNS 配置：/etc/docker/daemon.json 加 "dns": ["114.114.114.114", "8.8.8.8"]，重启 docker
- 检查是否与企业内网网段冲突（如 Docker 默认 172.17.0.0/16 和公司办公网重叠），冲突则改 bip 或用 --subnet 显式指定桥接网段
