Go断路器通过错误率驱动状态切换：Closed时统计失败率，超阈值切Open，超休眠期切HalfOpen，仅一次试探请求成功才恢复Closed；gobreaker需调低RequestVolumeThreshold适配低流量，HTTP调用须完整包裹Run并处理Body/状态码，多服务须独立实例避免干扰。
Go 断路器状态怎么判断是否该熔断
断路器不是靠计时器自动翻转状态，而是靠失败/成功事件驱动——每次调用 Execute 前，它先检查当前状态和滑动窗口内的错误率。状态只有三种：StateClosed、StateOpen、StateHalfOpen，切换完全由策略决定，不依赖外部调度。
常见错误是以为 “超时就熔断”，其实超时只是触发一次失败计数；真正熔断要看最近 RequestVolumeThreshold 次请求里失败占比是否超过 ErrorThresholdPercentage。
-
StateClosed：正常转发，同时统计失败次数和总请求数 -
StateOpen：直接返回错误，不调用下游，等SleepWindow时间后自动切到StateHalfOpen -
StateHalfOpen：只放行一次请求，成功则恢复StateClosed，失败则重置回StateOpen
用 github.com/sony/gobreaker 实现时要注意哪些参数
gobreaker 是 Go 生态最常用的断路器库，但它的默认配置对微服务场景偏保守：比如 RequestVolumeThreshold 默认是 100，意味着前 100 次请求里错误率再高也不会熔断——这在低流量接口上等于失效。
真实服务中建议按接口 QPS 和容忍度调低：
立即学习“go语言免费学习笔记（深入）”；
- QPS RequestVolumeThreshold: 10，
ErrorThresholdPercentage: 50 - 关键路径接口（如支付）：
SleepWindow: 30 * time.Second，避免过早试探失败 - 注意
Timeout是单次请求超时，和断路器无关；熔断逻辑不感知 context deadline
示例初始化：
var cb *gobreaker.CircuitBreaker
cb = gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-service",
Timeout: 5 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 3 // 更激进的失败判定
},
OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
log.Printf("CB %s state changed: %v -> %v", name, from, to)
},
})
为什么 Execute 包裹 HTTP 调用后还是 panic
根本原因：断路器只捕获你传给它的函数里抛出的 panic，不会拦截底层 HTTP client 的 panic（比如 json.Unmarshal 失败、空指针解引用）。如果 Run 函数里没 recover，panic 会穿透出去。
典型踩坑点：
- 把整个
http.Do+json.Decode写进Run，但没处理 response.Body.Close，导致连接泄漏，后续请求卡死 - 误把
context.WithTimeout放在Execute外层，断路器无法感知超时，仍会计为失败 - 忘记对
err != nil做区分：网络错误要计入失败，业务错误（如 400）通常不应触发熔断
正确写法要点：
- HTTP 调用必须包在
Run函数内 - 所有 error 判定逻辑放在
Run里，包括 status code 检查 - 显式调用
defer resp.Body.Close()，哪怕在 error 分支
多个微服务共用一个断路器实例会有什么问题
会互相干扰——比如 A 服务连续失败导致断路器打开，B 服务的请求也会被拒绝，即使 B 完全健康。这不是 bug，是设计使然：gobreaker.CircuitBreaker 是状态独占的，没有路由或标签能力。
解决方式只有两个：
- 每个下游服务配独立断路器实例，用 map 或 sync.Map 管理：
breakers["user-service"] - 改用支持命名空间的库（如
resilience-go），但它在 Go 里生态弱、文档少，维护成本高
别图省事复用实例，线上故障时很难定位是哪个服务拖垮了整个断路器状态。
状态机本身不复杂，难的是怎么让失败判定贴合业务语义——比如重试后的成功要不要算进半开试探？下游返回 503 是否该计入失败？这些细节不写进代码注释，下次接手的人准懵。
