gobreaker熔断需先确保超时生效再统计失败：http请求必须用context.withtimeout并透传至transport层，readytotrip应基于滑动窗口失败率而非连续失败数，timeout与context超时不可混用，fallback须独立实现。
直接结论：延迟本身不是问题，但不加控制的延迟会拖垮整个调用链；熔断不是替代超时的方案，而是对“超时+失败”模式的统计响应——必须先确保超时生效，再让熔断器感知失败。
为什么gobreaker.Execute里HTTP请求还是卡死？
常见现象是熔断器配置了Timeout: 5 * time.Second，但实际请求卡住20秒才返回context.DeadlineExceeded，熔断器完全没反应。
- 根本原因：gobreaker只看
Execute包裹函数返回的error是否为nil，而很多HTTP SDK在超时后返回nil, nil或自定义结构体（比如resp.Err == "timeout"），gobreaker默认不认为这是失败 -
http.Client.Do必须配合context.WithTimeout使用，且要显式传入：req = req.WithContext(ctx)或用http.NewRequestWithContext构造 - Transport层未配
DialContext和ResponseHeaderTimeout时，DNS解析、TCP建连、TLS握手阶段无法被context中断，超时就形同虚设 - 别复用
http.DefaultClient——它没设任何timeout，一个慢请求会阻塞整个连接池
gobreaker.ReadyToTrip怎么写才不误判？
错误写法：counts.ConsecutiveFailures > 3。这会导致短暂抖动（如网络闪断）就触发熔断，尤其在低QPS服务上极不稳定。
- 推荐用比例+窗口组合：
float64(counts.TotalFailures)/float64(counts.TotalRequests) > 0.5 && counts.TotalRequests > 10，避免冷启动或偶发失败误熔断 -
Interval设太短（如5 * time.Second）会让计数窗口过小，无法反映真实稳定性；建议设为业务SLA的3–5倍（比如支付接口SLA是800ms，窗口至少设3秒） -
MaxRequests只在HalfOpen状态生效，控制试探请求数量，不是并发限制——别把它当成限流用 - 如果下游是gRPC，注意gRPC状态码
codes.DeadlineExceeded需手动转成error，否则gobreaker收不到失败信号
熔断器和context.Timeout能共用一个时间值吗？
不能。两者语义完全不同，混用会导致策略失效。
-
context.WithTimeout是单次请求的硬性截止线，单位是毫秒级，比如800 * time.Millisecond -
gobreaker.Settings.Timeout是熔断器保持Open状态的持续时间，单位是秒级，比如60 * time.Second——它决定多久后尝试半开探测 - 如果把两者都设成
5 * time.Second，会出现熔断刚打开就立刻进入半开，反复震荡 - fallback逻辑必须独立于熔断器：gobreaker不提供fallback，得在
Execute的闭包外手动处理error，或封装一层统一降级入口
最易被忽略的点：熔断器只解决“要不要发请求”，不解决“发了之后怎么快”。真正的延迟优化永远始于transport层配置和context传递，而不是堆砌更多中间件。一个没配DialContext的client，再好的熔断器也救不了它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
