gobreaker.Execute 必须包裹完整调用链，涵盖网络请求、body读取、反序列化及轻量校验等所有可能出错环节；fallback需绕过熔断器且无副作用；重试与熔断应正交配置，避免混淆超时与探测间隔。
gobreaker.Execute 必须包裹完整调用链，不能只包 HTTP client
熔断器不是“开关”，而是对整个业务操作失败信号的统计与响应。常见错误是只把 http.Get 包进 cb.Execute，但忽略后续的 io.ReadAll、JSON 解析或数据库写入——这些环节出错不会触发熔断计数，导致“熔断形同虚设”。
正确做法是把从发起请求到获取可用结果的全过程封装为一个函数：
- 包含网络调用、body 读取、反序列化、甚至轻量校验逻辑
- 所有可能返回 error 的步骤都应在该函数内完成，且 error 必须显式返回（panic 不会被
gobreaker捕获） - 若需 fallback，必须在
cb.Execute外部处理，例如：if err != nil { return fallbackData(), nil }
重试要和熔断正交配置，别混用超时和失败阈值
http.Client.Timeout 控制单次请求挂起上限，gobreaker.Settings.Timeout 控制熔断开启后多久进入半开状态，两者语义完全不同。混淆会导致：
- 设
Timeout: 1 * time.Second—— 熔断器 1 秒后就试探，但下游服务实际恢复需 10 秒，反复失败 - 设
MaxRequests: 1—— 半开状态下只允许 1 次试探，失败即退回 open，永远无法恢复 - 重试次数 > 熔断失败阈值（如连续失败 3 次触发熔断，但重试 5 次）—— 熔断根本不会生效
推荐组合：
- 重试最多 3 次，指数退避 + jitter（如 100ms/200ms/400ms + 随机偏移）
- 熔断
ReadyToTrip判定基于窗口内失败率，例如counts.Failures / counts.TotalRequests > 0.5 -
Interval: 60 * time.Second，Timeout: 30 * time.Second，留出足够探测窗口
go-zero breaker 可直接复用，但要注意它不自动 retry
如果你项目已用 go-zero，它的 core/breaker 模块可直接 import 使用，无需额外依赖。但它只做状态管理，不内置重试逻辑：
- 调用方式是
brk.Do(func() error { ... })，返回 error 后需自行决定是否重试 - 它的
breaker.NewBreaker()默认使用 Google 自适应算法（基于失败率动态调整阈值），比固定阈值更抗抖动 - 注意：它不提供
Execute那样的(interface{}, error)返回形式，只返回error，适合纯副作用操作
示例：
brk := breaker.NewBreaker()
err := brk.Do(func() error {
_, err := http.DefaultClient.Do(req)
return err
})
if err != nil {
// 此处可加 retry，但必须自己实现，brk 不参与
}
fallback 逻辑必须绕过熔断器，且不能有副作用
降级不是“再试一次”，而是快速返回安全兜底值。最容易被忽略的是：
- fallback 函数如果也调用了同一熔断器（比如又去查缓存服务），而该缓存服务恰好也熔断了，就会陷入嵌套失败
- fallback 中执行写 DB 或发 MQ —— 这类操作失败会污染主链路熔断统计，且违背“轻量”原则
- 返回
nil或空结构体前没做零值检查，导致上层 panic
稳妥做法：
- fallback 只读本地变量、常量或预加载缓存（如
sync.Map存的默认推荐列表） - 绝不调用任何外部依赖，包括日志系统（用
log.Printf而非logger.Error） - 类型断言前先判断
result != nil，避免cb.Execute返回nil, err时直接 panic
熔断和重试的边界很薄：重试试图挽救临时故障，熔断则承认当前不可恢复。真正难的是判断什么时候该停手——比如连续三次超时后，到底是网络问题（该重试），还是对方服务已死（该熔断）。这没法靠库自动区分，得靠你对下游 SLA 和错误码的明确约定。
