降级回调必须幂等且无副作用，因半开状态下试探请求可能误触发写操作导致脏数据；禁止数据库写、动态查缓存或外部调用，仅允许读取本地只读数据，兜底值需预序列化并监控执行次数。
gobreaker 的降级回调必须是幂等且无副作用的，否则在熔断器反复进出半开状态时会引发数据不一致或重复提交。
为什么降级回调不能写数据库写操作
熔断器在“半开”状态下会试探性放行少量请求。如果降级逻辑里包含 db.Exec("INSERT ...") 或 cache.Set("user:123", fallback)，而此时真实服务其实已恢复，但降级路径仍被误触发，就会导致脏数据或覆盖正确结果。
常见错误现象：用户刷新页面后看到“默认头像”，再刷一次却变成“真实头像”，第三次又变回默认——这不是缓存失效，而是降级逻辑在不同请求间非一致地执行了写操作。
- 降级函数只应读取本地变量、常量或只读缓存（如
sync.Map中预加载的兜底值） - 绝对避免调用任何外部写接口，包括日志系统（
log.Printf可以，但slf4go.WriteError这类带上报的不要进降级路径） - 若必须记录降级发生，用原子计数器（
atomic.AddInt64(&fallbackCount, 1)）代替打点日志
gobreaker 的 Execute 回调签名限制
gobreaker.CircuitBreaker.Execute 接收一个返回 (interface{}, error) 的函数，但它的降级逻辑只能通过闭包捕获变量，无法直接传参——这意味着你没法在每次调用时动态决定返回哪个兜底值。
典型陷阱：把用户 ID 从主逻辑透传进降级函数，结果发现 userID 是上一次调用的残留值（闭包变量未及时更新）。
- 正确做法：在
Execute外层先准备好所有降级所需数据，比如fallbackUser := getUserFallbackByID(userID)，再放进闭包 - 禁止在降级函数内部重新查 DB 或调用其他服务——那已经不是降级，是绕过熔断器的二次调用
- 如果兜底数据依赖上下文（如语言、租户），必须提前提取并固化，不能靠
r.Header.Get("Accept-Language")动态获取
一致性兜底值怎么生成才可靠
真正高压场景下，连内存分配都可能成为瓶颈。用 fmt.Sprintf 拼接 JSON 字符串、或每次 new struct 都会触发 GC 压力，导致降级路径本身变慢甚至失败。
性能影响明显：某支付网关在峰值时降级响应 P99 从 2ms 涨到 18ms，排查发现是降级函数里用了 json.Marshal。
- 预序列化：启动时就把常用兜底结构体转成
[]byte，降级时直接copy返回 - 复用对象：用
sync.Pool管理临时 buffer，但注意 pool 的 Get/.Put 必须成对，别漏掉 - 避免反射：不要用
map[string]interface{}做通用兜底，类型固定时用具体 struct 更快
降级逻辑自身没监控就等于没降级
很多团队只监控“熔断是否打开”，却从不看“降级函数执行了多少次”。结果线上降级频繁触发，没人知道——直到用户投诉“为什么首页老显示默认推荐？”
容易被忽略的地方：降级函数执行异常（比如 panic）不会触发熔断器重试，而是直接向上抛错，等于降级失败，但指标里只记了一次“熔断拒绝”，掩盖了真实问题。
- 给降级函数加
recover()，记录 panic 并返回安全兜底值 - 暴露
fallback_total{service="user",reason="timeout"}这类 Prometheus 指标，和熔断器状态联动看板 - 配置中心（如 etcd）里设个开关
/config/fallback/enabled，支持紧急关闭某条降级路径做对比验证
