grpc拦截器中熔断逻辑需复用全局gobreaker.breaker实例，按服务/方法维度初始化；执行前检查与执行后更新须通过b.execute而非手动判断状态；错误分类应基于status.convert(err).code()；降级需返回合法响应类型和status.error，避免破坏协议兼容性。
gRPC拦截器里怎么加熔断逻辑
直接在 UnaryInterceptor 或 StreamInterceptor 里塞熔断判断是可行的，但容易漏掉状态同步和错误分类——比如 codes.Unavailable 和 codes.DeadlineExceeded 都该触发熔断，而 codes.InvalidArgument 不该。熔断器（如 gobreaker.Breaker）必须放在拦截器闭包外，否则每次调用都新建实例，完全失效。
- 拦截器函数内只做「执行前检查」和「执行后更新」，不创建新熔断器
- 熔断器实例应全局复用，建议按服务/方法维度初始化，例如用
map[string]*gobreaker.Breaker - 注意 gRPC 错误需用
status.Convert(err)提取真实 code，原生err.Error()无法可靠判断失败类型
包装函数如何透传 context 并保留 deadline
手动包装 UnaryClientInterceptor 时，如果直接用 ctx = context.WithTimeout(ctx, time.Second*5) 覆盖原始 context，会破坏上游传入的 deadline 和 cancel 信号。正确做法是复用原 context，仅在需要时叠加值（如 traceID），或用 context.WithValue 注入额外元数据。
- 永远优先使用
ctx原始值调用invoker，不要替换它 - 若需统一超时，应在 dial 时通过
grpc.WithTimeout（已废弃）或更推荐：在客户端构造时设grpc.DefaultCallOptions，或由上层业务控制 - 熔断失败时返回
status.Error(codes.Unavailable, "circuit open")，而非 panic 或裸 err，确保 gRPC 协议兼容
为什么熔断器状态在并发下会不准
多个 goroutine 同时调用同一熔断器的 Execute 方法时，gobreaker 默认是线程安全的，但如果你在拦截器里手动读写 State() 并据此跳过调用，就可能引发竞态——因为状态可能在你读完后立刻切换。
- 不要用
if b.State() == gobreaker.StateOpen来绕过调用；必须走b.Execute流程，让它内部处理状态跃迁 - 避免在拦截器里对同一熔断器频繁调用
ReadyToTrip或OnSuccess等内部方法 - 测试时用
go test -race跑并发场景，尤其关注拦截器中对共享 breaker 的读写
降级逻辑怎么写才不破坏 gRPC 返回结构
降级不是随便 return nil 或空 struct，gRPC 方法签名固定，必须返回对应响应类型和 error。常见错误是降级时 new 一个空 *pb.Response{} 却忘了设置 required 字段，导致下游 JSON 序列化 panic。
- 降级响应应尽量复用原 pb 生成的默认值，例如
resp := &pb.GetUserResponse{}，再填充必要字段 - error 必须是
status.Error，且 code 建议用codes.FailedPrecondition或codes.Unavailable，避免用codes.OK掩盖失败 - 如果降级依赖本地缓存，注意缓存 key 是否包含 context 中的 auth info 或 tenant id，否则可能返回错用户的数据
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
