直接用 gobreaker——它是 go 社区最成熟、被 grpc-go 和 go-zero 等生产级框架验证过的实现，自己手写易漏并发安全、滑动窗口计数、超时重置等关键细节。
熔断器该用 gobreaker 还是自己手写？
直接用 gobreaker —— 它是 Go 社区最成熟、被 grpc-go 和 go-zero 等生产级框架验证过的实现，不是玩具库。自己从零实现状态机（closed/open/half-open）、滑动窗口计数、超时重置，容易漏掉并发安全或恢复策略的边界条件。比如 gobreaker 默认用 time.Now() 做超时判断，但如果你在测试中 mock 时间，它不支持注入时钟，这时才需要考虑轻量封装。
gobreaker 怎么集成到 HTTP handler 中？
别包装整个 handler，只包裹可能失败的下游调用（如 HTTP client 请求、DB 查询）。典型错误是把 http.ServeHTTP 套进熔断器，这会让 404 或路由错误也被统计为失败，导致误熔断。
实操建议：
- 为每个外部依赖（如用户服务、支付网关）单独配一个
gobreaker.CircuitBreaker实例，避免故障扩散 - 设置
MaxRequests为 1（默认值），防止半开状态下并发请求打垮下游 - 用
ReadyToTrip函数自定义失败判定：比如只把5xx和连接超时算作失败，忽略404 - 示例中不要直接传
context.Background()，而是透传上游 context，确保熔断器内的超时能被 cancel
熔断后返回什么响应才不算“雪崩”？
返回 503 Service Unavailable + 明确提示（如 {"error": "user-service unavailable"}），而不是透传下游错误或空 JSON。关键点在于：客户端必须能识别这个响应并触发降级逻辑（如返回缓存数据、默认头像），否则熔断只是把错误从下游搬到上游。
常见坑：
- 没设
Content-Type: application/json，前端解析失败，转而报 JS 错误，掩盖了真实问题 - 错误体里塞了堆栈（如
err.Error()），暴露内部服务名或路径，违反最小信息原则 - 没加
Retry-Afterheader，客户端疯狂重试，反而加剧压力
怎么验证熔断器真在起作用？
靠日志和指标，别靠肉眼等三分钟看是否“自动恢复”。gobreaker 提供 cb.State() 和 cb.Ready()，但生产环境要导出 Prometheus 指标：
- 用
gobreaker.NewCustomEventReporter注册回调，上报onStateChange到 metrics - 监控三个核心指标：失败请求数、熔断触发次数、半开状态持续时长
- 压测时故意让下游返回 500，观察
gobreaker的Counters是否递增，且后续请求是否跳过执行直接返回
最容易被忽略的是：熔断器本身有内存占用，如果为每个租户动态生成 CB 实例却忘了回收，会引发 goroutine 泄漏。上线前务必用 pprof 抓一次 goroutine profile。
