Go熔断需手动组装，gobreaker.Execute必须传可执行函数而非客户端对象，返回(interface{}, error)，错误需显式转error，fallback仅在Open或panic时触发，超时与窗口参数须合理配置，监控不可少。
Go 里没有“语言学习式熔断”这回事——熔断降级不是靠语法糖或编译器特性自动推导出来的，它必须靠你对错误类型、调用边界和状态流转的明确判断来手动组装。所谓“语言学习思路”，其实是把 Go 的 error 处理模型、函数一等公民特性、context 生命周期这些原生机制，当成积木去搭熔断逻辑，而不是幻想有个 go run --circuit-breaker 这样的命令。
gobreaker.Execute 只能包 Do()，不能包整个 client
常见错误是把 *http.Client 或 *grpc.ClientConn 直接传给 gobreaker.Execute，结果熔断器根本统计不到失败——因为没真正发请求。它只认「执行动作」，不认「连接对象」。
-
gobreaker.Execute第一个参数必须是可执行函数，比如client.Do(req)、stub.GetUser(ctx, req)、db.QueryRow(...) - 返回值必须是
(interface{}, error)：成功时返回结果（哪怕nil），失败时返回非nil错误 - HTTP 5xx、gRPC
codes.Unavailable、dial tcp: i/o timeout都得主动转成error，否则不计入失败计数 - 别在
Execute里做重试、log、metric 上报——这些会污染失败判定逻辑
fallback 不是自动触发，必须显式判断 gobreaker.ErrOpen
gobreaker.Execute 的第三个参数（fallback 函数）只在两种情况下被调用：熔断器处于 Open 状态（返回 gobreaker.ErrOpen），或主函数 panic。它不会捕获超时、503、context canceled 等常规错误。
- 正确流程是：
res, err := cb.Execute(...)→if errors.Is(err, gobreaker.ErrOpen)→ 手动调用你的降级函数 - 降级函数签名必须和主函数完全一致，例如主函数是
func() (*User, error)，fallback 也得是这个类型 - 降级函数内部禁止访问 DB、调其他服务、起 goroutine；推荐从
sync.Map或本地 LRU cache 读缓存，或用DefaultUser()构造静态响应 -
&User{}是危险的——序列化后是{"name":"","age":0}，前端可能当成真实空数据；应显式初始化字段
Timeout 和 Interval 不是单次调用超时，别和 context.WithTimeout 混用
Timeout 是“熔断后多久尝试半开”，Interval 是“滑动窗口多长时间重置”，二者都跟单次请求超时无关。设错会导致恢复延迟或误判抖动。
立即学习“go语言免费学习笔记（深入）”；
-
Timeout建议设15 * time.Second：太短（如5s）会让半开探测过于激进；太长（如60s）下游已恢复，你还在休眠 -
Interval控制失败率统计周期，选30s ~ 2m；设成5s容易把一次网络抖动当持续故障 -
MaxRequests别设1：半开刚进就因单次失败又切回Open，实际建议 ≥10 - 单次调用超时必须用
context.WithTimeout单独控制，和熔断器解耦
没监控的熔断等于黑盒拉闸
熔断器本身不暴露状态，gobreaker.Metrics 必须接入 Prometheus，否则你无法知道它什么时候开了、为什么开、fallback 是否被频繁触发。
重点盯三个指标：circuit_breaker_state（当前状态）、circuit_breaker_failure_count（失败次数）、circuit_breaker_fallback_count（降级调用次数）。其中 circuit_breaker_fallback_count 突增，往往意味着下游真的挂了，而不是你配错了阈值——这点最容易被忽略。
