go-zero熔断器默认不启用，需显式配置circuitBreaker: true或传入breaker中间件；其googleBreaker采用滑动窗口+动态权重计算dropRatio，受WindowDuration、buckets、protection、MinRequests和k参数影响，Acceptable函数须轻量。
go-zero熔断器默认不启用，必须显式配置或调用
很多人以为只要用了go-zero，熔断就自动生效——其实不是。REST或RPC接口默认不带熔断中间件，除非你手动启用。框架只在rest.MustNewServer或zrpc.MustNewClient内部按需创建熔断器，但前提是配置里开了开关，或者代码里显式传入breaker拦截器。
常见错误现象：
- 服务已持续失败，但上游还在疯狂重试，日志里全是超时，却没看到
ErrServiceUnavailable - 配置写了
circuitBreaker字段，但启动后core/breaker/breaker.go里压根没进allow()逻辑
实操建议：
- REST服务：在
service.yaml中明确添加circuitBreaker: true，并确保rest.MustNewServer加载了该配置 - RPC客户端：使用
zrpc.RpcClientConf{Middlewares: []string{"breaker"}}显式启用 - 自定义拦截器场景：直接调用
breaker.DoWithAcceptable(...)，别依赖“自动注入”
错误率阈值不是固定百分比，而是滑动窗口+动态权重计算
go-zero的googleBreaker不简单统计“失败数 / 总请求数”，它用的是带时间桶和加权接受数的自适应公式：dropRatio = (total - protection - weightedAccepts) / (total + 1)。这意味着即使错误率看起来只有30%，也可能因近期桶内失败集中而触发熔断。
立即学习“go语言免费学习笔记（深入）”；
关键影响点：
-
WindowDuration（默认60s）和buckets（默认40）共同决定每个桶粒度（如1.5s），高频短时抖动更容易被捕捉 -
protection（默认5）是硬性保护基数，低流量下防止误判；若MinRequests设太小（如20），小流量接口极易进入Open态 -
k参数（敏感度系数，默认1.5）越高，对失败越敏感；生产环境建议保持1.5~1.8，避免毛刺误熔
示例：某接口QPS仅2，但连续3次失败，若MinRequests=5，此时total=3 ，熔断器仍处于<code>Closed，不会触发；但若设成MinRequests=2，立刻满足条件，dropRatio可能跳变到0.4以上，直接开闸。
熔断与限流必须状态协同，否则会互相抵消
限流器放行的请求，如果下游已熔断，结果只是把排队等待变成快速失败；反过来，熔断器半开试探时若被限流拦住，会导致恢复延迟甚至卡死在Half-Open。go-zero本身不强制二者联动，得靠你补逻辑。
容易踩的坑：
- 在
tokenlimit.Limiter.Wait()前没检查breaker.State()，导致Open状态下仍消耗令牌 -
RequestVolumeThreshold（熔断统计最小请求数）设得比限流QPS还低，比如限流100 QPS，却设MinRequests=50，结果每秒都满足条件，熔断器频繁震荡 - 没覆盖
Half-Open状态下的试探请求限流，导致恢复期涌入流量压垮刚缓过来的下游
实操建议：
- 封装统一调用函数，在
limiter.Wait()之前加判断：if brk.State() == breaker.Open { return errors.New("circuit breaker is open") } -
MinRequests建议设为限流阈值的1.2~1.5倍（如限流100，设120），保证统计窗口有足够样本又不过于敏感 - 半开期间允许的试探请求数，应单独用一个轻量级限流器控制（如
rate.NewLimiter(rate.Every(100*time.Millisecond), 1)）
自定义Acceptable函数决定哪些错误算“失败”，这点常被忽略
熔断器不是一出错就熔，它只对acceptable返回false的错误计数。默认实现是errors.Is(err, context.DeadlineExceeded) || errors.Is(err, syscall.ECONNREFUSED)这类底层故障，但业务错误（如UserNotFound）默认不算失败——这很合理，但如果你没看源码，可能误以为“所有err都会触发熔断”。
典型问题场景：
- 下游返回
500 Internal Server Error，但你的HTTP client没包装成error，或包装成了user.ErrInvalidParam，结果熔断器完全无视 - RPC调用返回
status.Code() == codes.Unavailable，但没在Acceptable里判断，导致持续失败却不熔断
正确做法：
- 在
breaker.DoWithAcceptable里传入自定义函数，明确标出需要熔断的错误类型 - 对gRPC调用，建议包含：
codes.Unavailable、codes.Internal、codes.DeadlineExceeded - 对HTTP调用，可判断
resp.StatusCode >= 500或特定错误body字段（如err.Code == "SERVICE_UNREACHABLE"）
最易被忽略的一点：Acceptable函数运行在熔断器上下文中，不能做耗时操作（如DB查询、HTTP调用），否则会拖慢整个熔断判断链路。
