go无自动降级机制，必须手动用errors.is(err, context.deadlineexceeded) || errors.is(err, context.canceled)判断超时/取消，降级函数须类型严格匹配、无副作用、仅用本地缓存或内存计算，且置于service层与熔断协同。
Go 没有自动降级机制，加个 fallback 函数不等于完成降级——它可能根本不会被调用，或者调用时已破坏一致性。真正的降级必须手动判断错误语义、显式跳转、严格约束行为边界。
如何正确判断该不该走降级分支
不能靠字符串匹配或简单等号比较错误值，否则会漏掉真实可降级场景，或把业务错误误判为故障。
-
errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled)是唯一健壮的超时/取消判断方式；只写err == context.DeadlineExceeded会漏掉 gRPC 流被主动关闭、HTTP/2 请求被前端中止等常见context.Canceled场景 - 对 gRPC 错误，别直接用
status.Code(err)判断后就跳降级——底层仍是 context 包装的错误，仍要先过errors.Is - HTTP 客户端错误中，
"dial tcp: i/o timeout"可降级，但"404 Not Found"或"400 Bad Request"是业务态，不应进降级 - 数据库操作里，
sql.ErrNoRows是预期结果，不是 transient 故障；而驱动报的"server closed the connection"才该触发降级
降级函数必须满足哪些硬性约束
降级不是“兜底容错”，而是“主动切换路径”。它的行为比主流程更严格，否则会放大故障。
- 签名必须完全一致：如果主函数是
func GetUser(id string) (*User, error)，降级函数也必须返回(*User, error)，哪怕error是nil - 禁止任何副作用：不能发 HTTP 请求、查 DB、写日志（告警应在主流程失败后统一处理）、起 goroutine、调用
time.Now()或rand.Intn() - 避免返回零值结构体：
&User{}序列化后是{"name":"","age":0}，前端易误判为真实空数据；应改用DefaultUser()显式构造，字段赋值明确 - 所有数据必须来自本地缓存或纯内存计算，禁止跨服务调用——否则降级链本身就成了新的故障点
为什么不能把降级逻辑塞进 handler 层
降级必须放在 service 层，且仅读本地缓存或纯内存计算。handler 层只负责接收请求、校验参数、调用 service 并返回响应。
- 把降级塞进 handler 会导致业务耦合：同一个
GetUser逻辑在多个 handler 里重复实现，开关、监控、熔断无法统一控制 - service 层能天然复用 context 超时和熔断器状态；handler 层再包一层
context.WithTimeout容易和上游 timeout 冲突，造成双重 cancel - 动态开关（如配置中心下发的
degrade.enabled.user）和打点监控（如degrade.hit.user）必须与 service 绑定，才能准确反映真实降级率 - 若配合熔断器（如
sony/gobreaker），其Execute方法必须包裹 service 调用，而不是 handler 入口
超时控制与降级的协同要点
用 context.WithTimeout 防止阻塞只是第一步，关键是如何让超时真正导向可控的降级路径。
- 主调用必须传入 context，并确保下游（HTTP client、gRPC conn、DB driver）都接收并传递该 ctx；否则
ctx.Done()不会触发 - 不要在 defer 中做降级：defer 是 panic 恢复机制，不是降级——panic 是异常崩溃，超时是预期中的可控失败
- 别用
time.AfterFunc单独起 goroutine 做降级：竞态风险高，无法保证与主流程 cancel 同步；应始终基于ctx.Err()显式分支 - 超时阈值要分层设置：比如主服务设 800ms，其依赖的用户中心设 300ms，推荐用
context.WithTimeout(parentCtx, 300*time.Millisecond)向下透传
最容易被忽略的是错误分类粒度——很多团队只区分“成功/失败”，但降级决策必须区分 transient（可重试、可降级）和 permanent（业务态、不可降级）错误。这个判断一旦出错，降级就从保险丝变成定时炸弹。
