合理设置docker健康检查需配合start-period、retries、interval和timeout：start-period缓冲启动期（web服务30–60秒，数据库45–120秒），期间失败不计重试；retries设2–3次防误判；interval为timeout的2–3倍；命令须真实反映服务状态，用curl -f等确保http非2xx返回非零码。
设置合理的重试等待时间，关键不是堆高数字，而是让 docker 能区分“真故障”和“暂时没准备好”。核心靠 start-period 和 retries 配合，再用 interval 和 timeout 控制节奏。
先给启动期留足缓冲：start-period 是第一道防线
容器刚启动时，Spring Boot 加载上下文、数据库连接池初始化、缓存预热等都需要时间。如果一上来就检查，十有八九失败，还直接计入重试计数——这就误判了。
- Web 应用（如 Spring Boot、Node.js）建议设 30–60 秒；启动慢的可到 90 秒
- 数据库容器（PostgreSQL/MySQL）建议 45–120 秒，尤其带数据恢复或主从同步的场景
- 这个时间段内发生的失败 不计入 retries 计数，状态保持 starting，依赖服务也不会贸然启动
连续失败才报警：retries 要够稳、别太敏感
retries 不是“最多允许失败几次”，而是“连续失败多少次才信你真坏了”。它和 interval 共同决定从首次失败到标记 unhealthy 的总延迟。
- 设为 2 或 3 最常用：既避开瞬时抖动（比如某次 GC 导致响应超时），又不会拖太久才响应
- 设为 1：容易因网络波动、CPU 短暂争抢误标 unhealthy，不推荐生产环境
- 设为 5+：可能延误干预，比如服务已卡死，但要等 5×interval 才触发告警或重启
- 举例：interval=20s + retries=3 → 连续失败需耗时至少 60 秒才变 unhealthy
节奏要匹配服务特性：interval 和 timeout 得协同
interval 决定检查频率，timeout 决定单次检查能忍多久。两者不合理，重试机制就形同虚设。
- timeout 应略大于健康端点的 P95 响应时间（比如平均 1.2s，P95 是 2.8s，timeout 设 4s 较稳妥）
- interval 至少要是 timeout 的 2–3 倍，避免上一次检查还没结束，下一次就启动（造成并发干扰）
- 轻量 API 服务：interval=15s，timeout=3–5s
- 数据库或集成型服务：interval=45–60s，timeout=10–30s
命令本身得真实反映服务能力
再好的重试参数，也救不了一个只检查端口是否打开的假命令。退出码才是唯一依据：
- 返回 0 → Docker 记为成功，重置失败计数器
- 返回 1 → 记为失败，失败计数器+1
- 返回 2 → 禁用本次检查（Docker 忽略，不计数）
- HTTP 服务务必用
curl -f或wget --spider，确保 4xx/5xx 也返回非零码 - 无 HTTP 的服务，检查进程是否存在、TCP 连接是否通、关键文件锁是否就绪，比 ping 端口靠谱得多
