go中无开箱即用的优雅降级模块，所有降级逻辑必须手动编写、显式触发、严格约束边界；service层是唯一合法落点，需用context判断超时（errors.is(err, context.deadlineexceeded) || errors.is(err, context.canceled)），降级分支仅允许读本地lru缓存或返回纯内存构造体，禁止发起新请求、调用time.now()等副作用操作，fallback函数签名须与主逻辑完全一致。
Go里没有“优雅降级模块”这回事——所有降级逻辑必须手动编写、显式触发、严格约束边界，框架不兜底，panic不等于降级，fallback也不会自动执行。
service层才是降级逻辑的唯一合法落点
handler层只做参数校验和响应包装，把降级塞进去会导致复用困难、熔断失效、超时判断错位。
- service方法必须接收
ctx context.Context，并在每次下游调用后立刻判断错误语义 - 主调用返回
err != nil时，不能堆到函数末尾统一处理，得立刻分支 - 降级分支只能读本地
LRU cache或返回DefaultUser()这类纯内存构造体 - 禁止在降级里调用
http.Get、db.Query、time.Now()或任何可能阻塞/失败的操作
errors.Is(err, context.DeadlineExceeded)是唯一可靠超时判断
很多降级没触发，不是逻辑写错了，而是超时判断方式不健壮。
- 别用
err == context.DeadlineExceeded——漏掉context.Canceled会导致前端关闭页面时直接返回500 - 别用
strings.Contains(err.Error(), "timeout")——"i/o timeout"、"context deadline exceeded"、"transport: context deadline exceeded"全都不一样 -
gRPC调用失败时，status.FromError(err).Code()可能是codes.DeadlineExceeded，但底层仍是context错误，仍要走errors.Is -
HTTP客户端错误中，"404 Not Found"或sql.ErrNoRows是业务正常态，不该进降级分支
gobreaker.Execute不会自动跳转到fallback
它只在熔断打开时返回gobreaker.ErrOpen，你得自己捕获并调用fallback。
-
gobreaker.CircuitBreaker.Execute第一个参数必须是可执行函数，比如client.Do(req)、stub.GetUser(ctx, req)、db.QueryRow() - 返回值必须是
(interface{}, error)：成功时返回结果（哪怕nil），失败时返回非nil错误 - HTTP 5xx、gRPC
codes.Unavailable、dial tcp: i/o timeout都得主动转成error，否则不计入失败计数 - 别在
Execute里做重试、log、metric上报——这些会污染失败判定逻辑 - 正确流程是：
res, err := cb.Execute()→if errors.Is(err, gobreaker.ErrOpen)→ 手动调用你的降级函数
本地LRU缓存是降级稳定性的关键
Redis缓存失效时，热点key过期瞬间大量请求穿透到下游，如果下游又挂了，所有请求立刻走降级——这会让兜底逻辑本身成为瓶颈，甚至拖垮整个服务。
- 降级函数签名必须和主逻辑完全一致，比如都返回
(*User, error)，且内部不能发新请求、不改全局状态、不调rand.Intn() -
&User{}是危险的——序列化后是{"name":"","age":0}，前端可能当成真实空数据；应显式初始化字段 - 人工开关优先级高于熔断状态，运维灰度下线服务时，靠配置中心强制开启降级比等失败率统计更及时
- 每个
GetUser(id string)的降级函数也必须返回(*User, error)，哪怕error是nil
真正难的不是写fallback函数，而是守住边界：不跨层、不发网、不碰时间、不依赖外部状态。一旦越界，降级就从保命手段变成新的故障源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
