必须用 gobreaker 而非已归档的 hystrix-go；每个下游服务需独立 CircuitBreaker 实例，gobreaker.Execute 仅包裹实际网络调用并返回 (interface{}, error)，fallback 需手动触发且签名一致，Timeout/Interval 与单次超时无关，须接入 Prometheus 监控。
为什么直接用 gobreaker 会踩坑？
因为 gobreaker 默认的熔断策略对 HTTP 客户端不友好：它把整个 Do() 调用当做一个“操作单元”，而一次 HTTP 请求可能因网络超时、TLS 握手失败、服务端 5xx 等多种原因失败，但这些原因不该一视同仁地计入熔断统计。比如 DNS 解析失败或连接被拒绝（net.OpError）属于瞬时底层错误，重试更合理；而服务端持续返回 503 才该触发熔断。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要直接包装
http.Client.Do，而是封装业务级调用函数（如GetUser(ctx, id)），让熔断逻辑感知语义而非原始 error - 用
gobreaker.WithSettings自定义ReadyToTrip函数，只对明确的业务失败码（如http.StatusServiceUnavailable或自定义错误类型）计数 - 避免在
OnStateChange回调里做阻塞操作（如写日志到磁盘），否则会拖慢状态切换
如何让降级逻辑真正“可配置”而不是硬编码？
硬编码 fallback 返回值（比如固定返回空用户结构体）会导致后续调用方无法区分是真实数据还是兜底值，也难以做灰度或 AB 测试。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 降级函数必须接收原始参数和原始 error，例如
func(ctx context.Context, id string, err error) (User, error)，这样能基于id做缓存查询或查本地影子库 - 通过
context.Value或显式传入fallbackOptions结构体控制降级行为：是否启用、超时时间、是否记录 metric - 降级函数内部应设独立超时（如
context.WithTimeout(ctx, 100*time.Millisecond)），防止 fallback 本身拖垮主链路
熔断器状态变更后，如何避免请求堆积？
当熔断器从 HalfOpen 切回 Open 时，如果正在试探的请求还没完成，新进来的请求会立刻被拒绝——但若此时有大量并发请求涌入，可能瞬间打爆 fallback 逻辑或下游缓存。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
gobreaker.Breaker.Execute外层加一层限流（如golang.org/x/time/rate.Limiter），仅对HalfOpen状态下的试探请求限流，不影响Closed状态的正常流量 - 使用
sync.Pool复用熔断器状态检查所需的临时对象（如 error 切片），避免 GC 压力干扰响应延迟 - 在
ReadyToTrip中加入滑动窗口计数（而非简单计数器），避免突发毛刺误触发熔断；gobreaker自带的defaultSettings是固定窗口，需自行替换为github.com/uber-go/ratelimit类似机制
HTTP 客户端怎么和熔断+降级联动？
直接给 http.Client 设置 Timeout 和 Transport 不足以支撑防护逻辑，关键是要把重试、熔断、降级三者串成一条可控链路。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
github.com/hashicorp/go-retryablehttp替代原生http.Client，它的CheckRetry可判断是否重试（如对net.ErrClosed重试，对404不重试） - 在 retry 的
Backoff阶段注入熔断器检查：if !breaker.IsAllowed() { return 0, errors.New("breaker open") } - 最终 fallback 不走网络，而是查本地内存缓存（
map[string]User+sync.RWMutex）或预加载的 JSON 文件，确保毫秒级响应
复杂点在于状态同步：熔断器打开时，要主动清掉相关接口的本地缓存，否则 fallback 返回过期数据；这个清理动作不能放在熔断回调里，得由调用方在收到 breaker.ErrOpen 后显式触发。
