retries表示连续失败多少次才标记容器为unhealthy，用于容忍网络抖动或启动延迟；需配合start_period宽限期（如40s）和合理timeout（5s）、interval（10s）协同生效。
直接在 healthcheck 块里设 retries 就行，这是 Docker Compose 原生支持的参数，专门用来应对网络抖动、服务启动慢等短暂异常，避免一次失败就误判为不健康。
retries 是什么，为什么能防抖动
retries 表示「连续失败多少次才标记容器为 unhealthy」。它不关心单次失败原因，只统计连续失败次数。网络抖动通常只影响个别请求，只要不是每次都失败，就不会触发误判。
- 设为 3：允许中间出现 1–2 次超时或连接拒绝，仍保持 healthy 状态
- 设为 5：适合启动慢、依赖多的服务（如 Java 应用连数据库），但别盲目拉高，会延迟真实故障发现
- 值为 1（默认值）风险最高——一次 curl 超时或 DNS 解析稍慢，立刻变 unhealthy
必须搭配 start_period 才真正有效
retries 单独起不了作用。如果服务刚启动还在加载，健康检查就开始计数，那前几次失败全算进 retries，等于没防抖动。
- start_period 是容器启动后「不计入重试计数」的宽限期
- 推荐设为 30s–60s：覆盖大多数 Web 服务初始化时间（Spring Boot、Node.js 等）
- 期间即使检查失败，也不消耗 retries 计数，真正从第 30 秒起才开始“认真计数”
timeout 和 interval 也要配合调优
retries 再大，如果单次检查太容易超时，照样白搭。关键参数要协同：
- timeout: 5s：比默认 30s 更合理；太短（如 1s）易被瞬时卡顿打中，太长（如 15s）拖慢整体判断节奏
- interval: 10s：每 10 秒查一次，平衡灵敏度与资源开销；比默认 30s 更及时，又不会像 2s 那样刷屏式探测
- 三者组合效果：每 10 秒查一次，每次最多等 5 秒，连续失败 3 次才报警 → 实际容忍窗口约 30 秒内的偶发抖动
一个稳妥的生产级配置示例
以下适用于 Nginx、PHP-FPM、Python Flask 等常见 Web 服务：
healthcheck:test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 10s
timeout: 5s
retries: 3
start_period: 40s
注意：/health 是只读端点，不带副作用；若用 / 或带参数的 URL，需确认其幂等性。
