标准circuitbreaker库不支持多级降级，因其仅提供开/关/半开三级状态且fallback为单一函数；而多级降级需依据失败类型、占比和频次动态选择缓存、静态兜底或拒绝服务等不同策略，须自定义带权重计数器与滑动窗口的状态机实现。
为什么标准 circuitbreaker 库不直接支持多级降级
Go 生态主流熔断库（如 sony/gobreaker、afex/hystrix-go）只提供「开 / 关 / 半开」三级状态，且 fallback 是单一函数。多级降级需要按失败程度逐层退化：比如一级降级查缓存，二级降级返回静态兜底数据，三级直接返回错误——这要求熔断器能感知失败“严重性”而非仅“是否失败”。gobreaker 的 OnStateChange 只通知状态跳转，不暴露失败原因或次数；hystrix-go 已归档，配置粒度粗，无法绑定不同错误类型到不同降级策略。
用 go.uber.org/ratelimit + 自定义状态机实现分层控制
真正可行的路径是放弃“黑盒熔断器”，自己维护一个带权重的失败计数器 + 状态机，并用限流器辅助控制降级流量比例。核心思路：不是等熔断“触发”才降级，而是根据最近 N 次调用中不同错误类型的占比，动态决定当前请求走哪一级 fallback。
-
errors.Is(err, ErrNetwork)计入网络失败计数；errors.Is(err, ErrTimeout)单独计数——这两类错误优先触发一级降级（缓存） - 当网络失败率 > 30% 且超时率 > 10%，自动启用二级降级（本地静态 map）
- 若连续 5 次调用都触发二级降级，直接升为三级（返回
http.StatusServiceUnavailable） - 用
ratelimit.New(10)控制二级降级的调用量，避免缓存穿透雪崩
func (c *MultiLevelCB) Allow(ctx context.Context) (level int, err error) 的设计要点
这个方法是中间件入口，必须做到零阻塞、低开销。不能在这里做真实调用或 IO，只做决策。
- 使用
sync/atomic维护三个uint64计数器（netFailCount、timeoutCount、fallbackHitCount），避免锁竞争 - 每 10 秒用
time.Ticker触发一次滑动窗口重置（不是清零，而是右移历史桶），保证统计时效性 - 返回的
level直接对应 HTTP 状态码层级：0=正常调用，1=缓存，2=静态兜底，3=拒绝服务 - 如果
ctx.Err() != nil，直接返回level=3，不计入任何计数器——超时/取消不属于下游故障，不该影响降级策略
HTTP 中间件里怎么嵌套调用不同 level 的 handler
别写成 if-else 嵌套。用切片索引更清晰：
立即学习“go语言免费学习笔记（深入）”；
handlers := []http.HandlerFunc{
fullServiceHandler, // level 0
cacheFallbackHandler, // level 1
staticFallbackHandler, // level 2
rejectHandler, // level 3
}
level, _ := cb.Allow(r.Context())
handlers[level](w, r)
注意：每个 handler 必须自带超时控制。比如 cacheFallbackHandler 内部用 context.WithTimeout(ctx, 50*time.Millisecond)，否则一级降级本身又变成瓶颈。另外，rejectHandler 要设置 w.Header().Set("X-RateLimit-Remaining", "0")，让上游网关知道这是主动熔断而非后端挂了。
多级降级真正的复杂点不在状态判断，而在各级 fallback 的数据一致性——缓存过期时间、静态数据更新机制、拒绝响应的可观测埋点，这些和熔断逻辑本身是正交的，但漏掉任何一个，降级就会变成事故放大器。
