go微服务中熔断与降级必须用专门库（如sony/gobreaker）配合状态机，因标准库无失败率统计、半开探测等能力；重试不等于熔断，需显式定义失败判定、降级响应及可观测埋点。
Go 微服务中，熔断与降级不能靠 if err != nil 硬扛，必须用专门的库配合明确的状态机控制；否则服务雪崩时你连日志都来不及打。
为什么标准 net/http 或 grpc-go 自带重试不等于熔断
HTTP 客户端重试只解决瞬时网络抖动，但无法识别“下游持续超时/大量 500”这类系统性故障。熔断核心是状态感知 + 自动隔离，而 Go 标准库完全不维护调用历史、失败率、半开探测等状态。
-
http.Client的Timeout和Transport设置只能控制单次请求，不会阻止后续请求继续压向已崩溃的服务 -
grpc-go的WithBlock或FailFast是连接级策略，不是业务调用级熔断 - 自己手写计数器 +
time.AfterFunc模拟熔断极易出竞态，且难支持滑动窗口、自动恢复等关键行为
用 sony/gobreaker 实现生产级熔断（推荐）
这是目前 Go 生态最轻量、无依赖、被 go-micro 和 kratos 等框架默认集成的熔断器。它基于状态机（Closed → Open → Half-Open），支持自定义失败判定、超时、滑动窗口计数。
- 初始化时指定
Settings：比如Interval: 60 * time.Second（滑动窗口长度）、Timeout: 10 * time.Second（熔断后保持 Open 的最短时间） - 失败判定靠
ReadyFunc返回error，建议包装 HTTP status code 或 gRPCstatus.Code()，不要只判err != nil - 每次调用前必须用
cb.Execute包裹，它会自动路由到 fallback 或直接 panic（取决于配置） - 示例片段：
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{ Name: "user-service", MaxRequests: 5, Interval: 30 * time.Second, Timeout: 5 * time.Second, ReadyToTrip: func(counts gobreaker.Counts) bool { return counts.TotalFailures > 3 && float64(counts.TotalFailures)/float64(counts.Requests) > 0.6 }, }) _, err := cb.Execute(func() (interface{}, error) { return callUserService(ctx, req) })
降级逻辑必须显式声明，不能藏在 recover 里
熔断器触发后，Execute 会返回预设错误（如 gobreaker.ErrOpenState），此时你要主动提供兜底数据或空响应——这不是异常处理，而是业务契约的一部分。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 场景下，降级可返回缓存值、静态 JSON 或默认对象，但要确保
Content-Type和结构体字段兼容原接口 - gRPC 场景下，降级必须返回合法的
*pb.Response，不能返回nil或类型错配的 struct - 避免在降级函数里再发起外部调用（比如查 Redis 失败又去查本地文件），这会让降级本身成为新瓶颈
- 关键路径上，建议把降级逻辑提前注册为闭包，而非运行时 if-else 判断，减少分支开销
别忽略熔断器的可观测性埋点
线上出问题时，你没法靠 fmt.Println 查熔断器状态。gobreaker 提供 cb.State() 和 cb.Counts()，但必须主动上报，否则等于没开。
- 每分钟采集一次
State()（gobreaker.StateClosed/Open/HalfOpen）推送到 Prometheusgobreaker_state{service="xxx"} - 用
Counts()中的TotalRequests、TotalFailures计算失败率，设置告警阈值（如 5 分钟内失败率 >80%） - 注意：gobreaker 默认不记录具体失败原因，如需定位是超时还是 503，得在
Execute的闭包里手动打日志
真正难的不是接入熔断器，而是定义清楚“什么算失败”“降级返回什么才不影响前端渲染”“熔断多久后试探性放行”。这些决策必须和产品、前端、SRE 对齐，代码只是执行载体。
