熔断必须主动包装调用并统计失败/超时，延迟本身非错误，需用context.WithTimeout将超时转为error，并在ReadyToTrip中采用滑动窗口失败率判断，避免误熔断。
不能靠 gin.Recovery() 或中间件自动识别高延迟并熔断——它只处理 panic，不感知响应慢。 真正的熔断必须主动包装外部调用、统计失败/超时、维护状态机。延迟本身不是错误，但超时或连续超时会触发失败计数，这才是熔断起点。
为什么 HTTP 延迟不会自动触发 gobreaker
gobreaker 的 Execute 只把 error 当失败，而 http.Get 即使耗时 10 秒只要没超时、没断连，就返回 nil error —— 它根本不会进失败统计。你得自己把“延迟超标”转成错误。
- 必须用
context.WithTimeout包装请求，否则http.Client不会中断，Execute一直卡住 - 别只检查
err != nil；还要判断resp.StatusCode >= 500或业务异常码，手动return fmt.Errorf("bad status: %d", resp.StatusCode) -
ReadyToTrip回调里别只看ConsecutiveFailures，建议用滑动窗口失败率：counts.TotalFailures / counts.Requests > 0.3，避免偶发抖动误熔断
如何把一次 HTTP 调用变成可熔断的单元
核心是三件事：传 context、显式判错、类型安全返回。漏掉任何一环，熔断器要么不统计失败，要么 panic。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
http.NewRequestWithContext(ctx, ...)构造请求，确保 ctx.Done() 能中断底层连接 - 在
Execute函数体内，defer resp.Body.Close()必须写，否则连接泄漏 - 返回值是
(interface{}, error)，调用方必须做类型断言：user := result.(*User)，否则 runtime panic - 不要在
Execute里写time.Sleep或长循环，会阻塞熔断器状态更新周期
熔断器总在 Closed/Open 之间抖动？先查这三点
这不是库的问题，而是配置或使用方式偏差导致状态无法稳定。
立即学习“go语言免费学习笔记（深入）”；
-
Timeout字段不是 HTTP 超时，而是「Open 状态维持多久后进入 Half-Open」，别和context.WithTimeout混用 - 每个下游服务只建一个
gobreaker.CircuitBreaker实例（如cbUserSvc），别按接口或请求新建 -
MaxRequests: 1+Interval: 0这类配置会让熔断器极度敏感，推荐设为MaxRequests: 10、Interval: 60 * time.Second
真正难的不是加库，而是定义“什么算失败”——超时、5xx、空响应、还是业务错误码？这个边界必须由业务逻辑明确划出，熔断器只执行判断。
