首选sony/gobreaker而非已归档的hystrix-go，因其无全局状态、兼容context.Context、被go-zero等主流框架验证；每个下游服务须配独立实例，Execute仅包裹真实调用，fallback仅在ErrOpen或panic时触发，且须配合context.WithTimeout与Prometheus监控。
Go 语言微服务里用熔断器，不是为了“高大上”，而是防止一个下游服务挂掉，把整个学习系统拖垮——比如用户查单词时，例句服务超时或崩了，不该让整个接口卡住或雪崩。
为什么 hystrix-go 不再推荐用
它早在 2021 年就归档（Archived），不再维护，且依赖过时的 sync/atomic 模式和全局状态，和现代 Go 的 context、error handling 习惯冲突。实际项目中遇到并发下状态错乱、panic 在 hystrix.Do 内部、无法透传 trace ID 等问题很常见。
- 替代方案首选
sony/gobreaker：无全局状态、支持自定义事件回调、天然兼容context.Context - 轻量场景可考虑
matryer/xgb：纯函数式，不依赖任何第三方，但需手动管理状态生命周期 - 别硬套 Spring Cloud Alibaba 那套配置式熔断逻辑——Go 里更推荐在 HTTP client 层或 RPC 调用点显式 wrap
gobreaker.Ready() == true 不能当健康检查用
这个方法只反映熔断器当前是否允许请求通过，不校验下游真实连通性。曾有团队把它塞进 k8s livenessProbe，结果下游服务已死，但熔断器还处在半开状态，probe 一直返回成功，Pod 没被驱逐。
- 健康检查必须走真实探针：比如对例句服务发一个带
timeout=200ms的 HEAD 请求 -
gobreaker.State()可用于日志或 metrics 上报，但别用于决策路由或存活判断 - 半开（
HalfOpen）状态下，首次请求失败会立刻切回Open；成功则重置计数器——这点要结合你服务的失败容忍率调参
在 gRPC 客户端里加熔断，别动 server 端拦截器
熔断是客户端行为，作用对象是“我调别人”，不是“别人调我”。在 server 端加熔断逻辑，既没意义，又干扰链路追踪和错误分类。
立即学习“go语言免费学习笔记（深入）”；
- 正确位置：封装一层
ExampleClient，所有GetExamples调用都经过cb.Execute - 示例伪代码：
func (c *ExampleClient) GetExamples(ctx context.Context, req *pb.ExampleReq) (*pb.ExampleResp, error) { return c.cb.Execute(func() (interface{}, error) { return c.grpcClient.GetExamples(ctx, req) }) } - 注意：gRPC 的
ctx必须透传进Execute的闭包，否则超时和取消无法生效 - 别把
gobreaker.Settings里的Timeout和 gRPC 自身的ctx.Timeout混为一谈——前者是熔断器等待响应的上限，后者是整个调用生命周期上限，建议前者设为后者的 70%
学习类服务的熔断阈值不能照搬电商
查单词、看释义这类请求失败影响的是用户体验，不是资金安全。设成“5 秒内失败 10 次就熔断”，可能刚上线就被误熔——学生网络抖动、CDN 缓存未命中、小语种词库加载慢都会触发。
- 建议起始配置：
Requests: 10,Interval: 60 * time.Second,Timeout: 2 * time.Second,VolumeThreshold: 5 - 关键指标优先看
cb.Stats().Requests和cb.Stats().Failures的比值，而不是绝对失败次数 - 对低频冷门语言（如斯瓦希里语）接口，可按
language_code动态设置gobreaker.Settings，避免一刀切
最常被忽略的一点：熔断器本身没监控就等于没装。至少要把 OnStateChange 回调打到日志，并聚合到 Prometheus 的 gobreaker_state{service="examples"} 指标里——否则下次半夜告警，你得先猜是下游崩了，还是熔断器自己卡在半开状态不动了。
