用gobreaker的cb.Execute包装调用最稳妥，但需手动分类错误、显式传context、为每个依赖配独立熔断器实例；否则因HTTP非2xx不报错、SDK空响应nil error、context超时被吞等问题，熔断逻辑失效。
直接上结论：用 gobreaker 的 cb.Execute 包装调用是最稳妥的起点，但必须手动分类错误、显式传 context、为每个依赖配独立熔断器实例——否则熔断逻辑大概率失效。
为什么不能直接用 http.Client.Do 套一层 gobreaker？
因为 gobreaker 默认只把 error != nil 当作失败，而很多真实场景下它根本收不到错误：
- HTTP 500 或 404 返回码被
http.Client认为“成功”，err是nil，但业务已失败 - 某些云厂商 SDK（如 AWS Go SDK）超时后返回空响应 +
nilerror，或自定义*smithy.OperationError类型，gobreaker不识别 -
context.DeadlineExceeded被吞掉，没转成可统计的 error，失败率永远为 0
结果就是：服务已经连续 20 次 503，熔断器还稳坐 Closed 状态。
如何正确包装第三方 API 调用？
核心是三件事：构造带上下文的请求、统一错误判定、交给熔断器执行。示例代码中关键点如下：
// 创建独立熔断器（每个下游服务一个）
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-api",
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 5
},
OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
log.Printf("[cb] %s state change: %s -> %s", name, from, to)
},
})
<p>// 包装调用
result, err := cb.Execute(func() (interface{}, error) {
ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
defer cancel()</p><pre class="brush:php;toolbar:false;">req, _ := http.NewRequestWithContext(ctx, "GET", "https://pay.example.com/v1/status", nil)
resp, err := client.Do(req) // 注意：client 是预配置好 Transport 的
if err != nil {
return nil, err // 网络层错误直接上报
}
defer resp.Body.Close()
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("HTTP %d", resp.StatusCode) // 业务失败也转 error
}
body, _ := io.ReadAll(resp.Body)
return json.RawMessage(body), nil})
-
ctx必须通过http.NewRequestWithContext注入，不能只靠client.Timeout - 所有非 2xx 响应码必须显式转成
error，否则不计入失败统计 - 每个下游（支付、短信、地图）都要有自己独立的
cb实例，避免互相干扰
容易被忽略的 Transport 配置坑
即使你写了 context.WithTimeout，如果 http.Transport 没配对，DNS 解析、连接建立、TLS 握手阶段仍可能卡死：
-
DialContext缺失 → DNS 查询阻塞无法取消 -
IdleConnTimeout过长 → 复用脏连接导致后续请求 hang 住 -
ResponseHeaderTimeout未设 → header 没回来就一直等，不触发 context 取消
正确初始化 client 示例：
client := &http.Client{
Transport: &http.Transport{
DialContext: (&net.Dialer{Timeout: 3 * time.Second}).DialContext,
IdleConnTimeout: 30 * time.Second,
ResponseHeaderTimeout: 2 * time.Second,
TLSHandshakeTimeout: 3 * time.Second,
},
}
真正麻烦的从来不是写几行熔断代码，而是把错误归因到具体环节——HTTP 状态码、SDK 自定义错误、context 取消时机、Transport 底层行为，四者稍有错位，熔断器就形同虚设。
