熔断是Go服务应对高并发和依赖不稳的第一道防线，通过gobreaker库实现状态机控制、可观测指标和真实降级，需配合超时与谨慎重试。
在高并发或依赖服务不稳定时，Go 服务容易因级联失败而雪崩。熔断（Circuit Breaker）不是“等它挂了再处理”，而是主动感知失败、快速切断异常调用，并在合适时机试探恢复——这是保障系统稳定的第一道防线。
用 github.com/sony/gobreaker 实现轻量熔断
Go 社区最成熟、零依赖的熔断库是 gobreaker。它基于 Netflix Hystrix 的状态机设计（Closed → Open → Half-Open），配置简洁，适合大多数 HTTP、RPC 或 DB 调用场景。
- 安装：
go get github.com/sony/gobreaker - 定义熔断器：设置失败阈值（如连续 5 次失败）、超时时间（如 1s）、重置间隔（如 60s）
- 包裹业务逻辑：把可能出错的操作（如 http.Do、db.Query）放进
cb.Execute()中执行
熔断状态与行为必须可观察
光有熔断不够，得知道它什么时候跳闸、为什么没恢复。gobreaker 提供 cb.State() 和 cb.Name()，建议结合 Prometheus 暴露以下指标：
- circuit_breaker_state{breaker="user_service"}：0=Closed, 1=Open, 2=HalfOpen
- circuit_breaker_calls_total{outcome="success|failure|rejected"}：统计各结果次数
- 日志中记录
StateChange事件（如 Closed→Open），便于排查突增失败是否触发了熔断
降级逻辑要真正可用，不能只是返回空
当熔断器打开（Open 状态），cb.Execute() 会直接返回 gobreaker.ErrOpenState。这时你要提供有意义的降级响应，而不是 panic 或裸奔返回 error：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 接口：返回缓存数据、兜底静态文案、或上一次成功结果（带 stale 标识）
- 用户中心类服务：降级为只读模式（如允许查资料，禁止修改头像）
- 避免降级嵌套：别在降级函数里再调另一个可能熔断的服务，否则等于绕过保护
熔断不是银弹，需配合超时与重试
单独开熔断，不设超时，请求仍会堆积；盲目重试失败接口，反而加速熔断。正确组合方式是：
- 所有外部调用必须带 context.WithTimeout（如 800ms），比熔断超时略短
- 重试仅用于临时性错误（如网络抖动），对 5xx 或熔断拒绝，应直接降级
- 可使用
github.com/cenkalti/backoff/v4控制重试策略，但重试上限 ≤ 2 次
基本上就这些。熔断本身不复杂，但容易忽略状态可观测性和降级真实性。上线前用 goroutine 打满失败请求验证跳闸逻辑，再模拟恢复流量看 Half-Open 是否生效——稳住系统，往往就靠这三步。
