降级成败关键在于精准识别可降级错误，errors.as 能穿透包装错误安全断言类型，须显式检查、统一 context 超时管控、避免降级中二次阻塞或 panic，并用包装错误充分测试。
Go 中用 errors.As 判断错误类型做降级
降级逻辑成败关键不是“有没有 fallback”，而是“能不能精准识别该降级的错误”。errors.As 是 Go 1.13+ 推荐的错误类型断言方式，比直接类型断言（err.(*MyError)）更安全，能穿透包装错误（比如 fmt.Errorf("wrap: %w", err)）。
常见错误现象：降级没触发，日志里明明报了 redis: connection refused，但代码还在走主链路——大概率用了 == 比较错误字符串，或漏了对 fmt.Errorf 包装层的处理。
- 只对明确声明为可降级的错误类型做
errors.As，比如自定义的*redis.TimeoutError、*pgconn.PgError，别试图匹配所有网络错误 - 如果上游库没暴露具体错误类型（如某些 SDK 只返回
error），就自己封装一层，用errors.Join或自定义 wrapper 包装后再抛出 -
errors.As返回bool，必须显式检查，不写if errors.As(err, &target) { ... }而是直接if errors.As(err, &target)就够了
降级路径里避免二次 panic 或阻塞
降级本身要是“轻量且确定”的。常见反模式：主调用失败后，在降级逻辑里又去查一次数据库、又发一次 HTTP 请求、甚至调用另一个可能超时的 RPC —— 这会让问题雪上加霜。
使用场景：缓存失效时查 DB；DB 不可用时返回兜底静态数据；第三方支付失败时切到模拟支付结果。
立即学习“go语言免费学习笔记（深入）”；
- 降级返回值必须和主路径类型一致，否则编译不过；如果主路径返回
(User, error)，降级也得返回(User, nil)或(User{}, nil)，不能返回(nil, err) - 降级函数内部禁止调用任何可能 panic 的代码（比如未判空的
map[key]），兜底数据建议提前初始化好，而不是每次降级都 new - 如果降级逻辑涉及 goroutine 或 channel，必须设超时（
time.After或context.WithTimeout），否则主线程可能被卡住
用 context.WithTimeout 控制主流程与降级的总耗时
用户感知的是整体响应时间，不是“主流程超时了，降级再跑 2 秒也没关系”。必须把主流程和降级逻辑包在同一个 context.Context 下，统一管控 deadline。
性能影响：不加总超时，降级可能比主流程还慢；加了但没传透，等于白加。
- 主调用前先派生带 timeout 的 ctx：
ctx, cancel := context.WithTimeout(parentCtx, 800*time.Millisecond) - 主调用和降级函数都接收这个
ctx，并在内部检查ctx.Err() != nil提前退出 - 别在降级函数里重新
context.WithTimeout，否则会覆盖父级 deadline，导致总耗时失控 - 如果主流程用了
http.Client，记得把ctx传给req.WithContext(ctx)，而不是只靠 client.Timeout
测试降级逻辑必须覆盖 error wrapping 场景
线上实际错误几乎都被层层包装过，单元测试如果只用 errors.New("timeout") 模拟，根本测不出 errors.As 是否真生效。
容易踩的坑：本地 mock 错误类型能过，一上生产就失效——因为真实环境里 Redis 客户端返回的是 *redis.RedisError，被 fmt.Errorf("cache get: %w", err) 包了一层。
- 测试时用
fmt.Errorf("op failed: %w", yourCustomErr)构造包装错误，再传给被测函数 - 验证降级是否触发，不能只看返回值，还要打日志或用
testify/assert检查是否进了降级分支 - 兼容性注意：Go 1.13+ 才支持
%w和errors.Is/As，低于此版本需升级或改用第三方错误库（如pkg/errors）
最麻烦的不是写降级逻辑，而是确保每一层错误传递都保留原始类型信息。wrapper 多一层，errors.As 就多一次穿透，漏一层，降级就哑火。
