go标准库无内置熔断器，http.client.timeout仅控制单次超时，无法实现失败率统计与状态切换；需用sony/gobreaker等库或手写三态逻辑（closed/open/halfopen）实现真正熔断。
Go 标准库没有内置熔断器，circuitbreaker 不是语言特性，必须靠第三方库或手写逻辑实现；直接用 net/http 发请求永远不会自动熔断。
为什么不能只靠 http.Client.Timeout 做熔断
http.Client.Timeout 只控制单次请求超时，不统计失败率、不切换状态、不阻断后续请求——它连“断路”两个字都够不上。
常见误用场景：
- 把
Timeout设成 100ms，以为能防雪崩，结果下游持续 500 错误，客户端还在疯狂重试 - 加了
Retry逻辑但没配熔断，错误堆积后拖垮调用方 CPU 和连接数
真正需要的是：连续失败 N 次 → 切到 Open 状态 → 拒绝新请求 → 定期试探性放行（half-open）→ 成功则恢复（closed）。
用 sony/gobreaker 包最省事
这是目前最轻量、无依赖、文档清晰的 Go 熔断库。它不侵入 HTTP 层，你只需把 http.Do 包进它的执行函数里。
关键配置项说明：
-
MaxRequests：半开状态下允许试探的最大请求数（建议设为 1 或 3） -
Interval：从Open切回HalfOpen的等待时间（如30 * time.Second） -
Timeout：熔断器自身状态保持时间（不是 HTTP 超时），超时后自动尝试恢复 -
ReadyToTrip函数决定何时跳闸：比如连续 5 次 error 就return true
示例片段：
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-api",
MaxRequests: 3,
Interval: 30 * time.Second,
Timeout: 1 * time.Minute,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures >= 5
},
})
<p>// 使用时包装 http.Do
_, err := cb.Execute(func() (interface{}, error) {
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
if resp.StatusCode >= 400 {
return nil, fmt.Errorf("HTTP %d", resp.StatusCode)
}
return resp, nil
})
</p>
自己实现简易版要盯住三个状态边界
如果不想引入外部依赖，可用 sync/atomic + time.Timer 手写，但必须显式处理三类状态转换：
-
Closed→Open：失败计数达阈值，立刻停发新请求，并启动一个Timer记录熔断开始时间 -
Open→HalfOpen：Timer 到期后，把状态设为HalfOpen，并重置失败计数 -
HalfOpen→Closed：试探请求成功 → 清零计数、切回Closed；失败 → 计数+1，若超限立即回Open
容易漏掉的点：
- 并发请求下
state读写没加锁或没用atomic，导致状态错乱 - 没区分「请求发起失败」和「业务返回错误」，把 400 当作熔断依据，实际可能是参数错
-
HalfOpen期间没做请求限流，一次涌进 100 个试探请求，压垮下游
HTTP 客户端集成时绕不开的坑
熔断器只是决策层，HTTP 客户端才是执行体。这两层粘合处最容易出问题：
- 别在
RoundTripper里硬塞熔断逻辑——它不感知业务语义，无法判断 429 是限流还是故障 - 错误分类要细：网络错误（
net.OpError）、TLS 握手失败、HTTP 5xx、429、甚至 gRPC 的Unavailable都该进失败计数；400/401 不该算 - 日志必须带熔断器当前状态（
gobreaker.State()）和失败原因，否则线上排查时分不清是下游挂了还是熔断器误判 - 测试时用
httptest.Server模拟下游，手动关服务触发Open，再开服务验证是否自动恢复——光测单元逻辑没用
真实环境里，熔断阈值不是拍脑袋定的。先开 metrics 上报失败率和状态切换次数，再根据 P95 延迟和错误毛刺周期反推 Interval 和 ConsecutiveFailures。
