Go降级需手动判断错误语义并显式跳转，唯一健壮超时判断是errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled)，降级函数须无副作用、类型严格匹配、纯内存计算，禁止网络调用，且须动态开关、打点监控并与熔断协同。
Go 没有自动降级机制，加个 fallback 函数不等于完成降级——它可能根本不会被调用，或者调用时已破坏一致性。必须手动判断错误语义、显式跳转、严格约束降级行为边界。
errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) 是唯一健壮的超时判断方式
很多开发者只检查 err == context.DeadlineExceeded，漏掉 context.Canceled，结果上游主动中断请求（比如前端关闭页面、gRPC 流取消）时直接返回 500，完全没走降级分支。
- gRPC 调用失败时，
status.FromError(err).Code()可能是codes.DeadlineExceeded，但底层仍是 context 错误包装，仍要走errors.Is判断 - 别用
strings.Contains(err.Error(), "timeout")—— HTTP/HTTP2/gRPC/数据库驱动返回的错误文本不一致，"i/o timeout"、"context deadline exceeded"、"transport: context deadline exceeded"都可能出现 - HTTP 客户端错误中，
"dial tcp: i/o timeout"可降级，但"404 Not Found"或sql.ErrNoRows是业务正常态，不应进降级分支
降级函数必须无副作用、类型严格匹配、禁止远程调用
降级不是“兜底容错”，而是“主动切换路径”。它的行为比主流程更严格，否则会放大故障。
-
func GetUser(id string) (*User, error)的降级函数也必须返回(*User, error)，哪怕error是nil - 避免返回零值结构体：
&User{}序列化后是{"name":"","age":0}，前端易误判为真实空数据；改用DefaultUser()显式构造，字段赋值明确 - 禁止在降级里起 goroutine、发 HTTP 请求、查 DB、写日志（告警日志应在主流程失败后统一处理）、调用
time.Now()或rand.Intn() - 别用全局变量存默认实例——并发修改风险高；每次新建开销极小，别省这点内存
降级逻辑必须放在 service 层，且仅读本地缓存或纯内存计算
handler 层只负责接收请求、校验参数、调用 service 并返回响应。把降级塞进 handler 会导致业务耦合、复用困难，也难以统一熔断/超时控制。
立即学习“go语言免费学习笔记（深入）”；
- service 方法应接收
ctx context.Context，并在每次下游调用后立刻判断是否触发降级——堆到函数末尾统一处理，中间逻辑可能已依赖未初始化的返回值，引发 panic - 降级分支必须是纯内存计算或本地缓存读取（如
sync.Map、bigcache、lru.Cache），禁止再发网络请求 - 缓存 key 要包含业务维度（如用户 ID、地区），不能只用原始参数；用
singleflight.Group防雪崩，但注意它默认广播错误结果，需手动包装：只在err == nil时才写入缓存 - HTTP 客户端必须显式禁用重试、缩短
Transport.DialContext和ResponseHeaderTimeout，否则 DNS 卡住或 header 不回都会拖长等待
硬编码降级开关等于没开关，必须动态可配且与熔断联动
生产环境上线后发现降级逻辑有 bug，或者下游已恢复，你的服务还在返回默认值——这就是硬编码开关的代价。
- 降级开关必须从配置中心（如 etcd/Nacos）加载，并定期刷新；避免重启生效
- 每个降级分支必须打日志 + 打点：
metrics.Counter("user_service_fallback_total").Inc()，否则无法感知是否被误触发 - 熔断器（如
sony/gobreaker）打开时，应联动关闭对应降级——否则熔断后还在返回默认值，下游恢复了你也收不到流量 - 提供管理接口（如
/admin/degrade/enable?service=user&mode=cache），方便人工干预
最容易被忽略的一点：降级和熔断不是二选一，而是协同策略。强一致性操作（如扣库存、资金流水）不该降级，应走熔断或重试；而查询类、推荐类、非核心展示类操作才适合降级。混淆这两者，轻则掩盖问题，重则导致数据不一致。
