降级逻辑优先放在 service 层。handler 层仅负责请求接收、参数校验、调用 service 和返回响应；service 方法应基于 context 判断降级，降级分支须纯内存或本地缓存，兜底函数需无副作用、零延迟，并配合缓存预热、互斥重建与本地 LRU 提升稳定性。
降级逻辑该放在 handler 还是 service 层？
优先放在 service 层。handler 层只负责接收请求、校验参数、调用 service 并返回响应；把降级逻辑塞进 handler 会导致业务耦合、复用困难，也难以统一熔断/超时控制。
典型错误是：在 http.HandlerFunc 里写两套 HTTP 调用（主依赖 + 备用依赖），一旦备用逻辑也要加缓存、重试、限流，立刻失控。
- service 方法应接收上下文
ctx context.Context，并主动判断是否触发降级（例如通过ctx.Err() == context.DeadlineExceeded） - 降级分支必须是纯内存计算或本地缓存读取，禁止再发网络请求
- 若降级结果需格式兼容主逻辑，建议用同一结构体，仅字段赋值来源不同
如何用 context.WithTimeout + recover 实现无侵入式兜底？
不能只靠 recover() 捕获 panic —— 大部分超时、连接拒绝不会 panic，而是返回 error。真正可靠的方式是组合 context.WithTimeout 和显式错误判断。
示例场景：调用外部用户服务失败时，返回默认用户信息：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
// 主调用
user, err := fetchUserFromRemote(ctx, userID)
if err != nil {
// 判断是否值得降级：网络类错误才兜底，参数错误不兜底
if errors.Is(err, context.DeadlineExceeded) ||
strings.Contains(err.Error(), "i/o timeout") ||
strings.Contains(err.Error(), "connection refused") {
return getDefaultUser(), nil
}
return nil, err
}
- 不要用
err == nil作为降级唯一条件，有些 SDK 在超时后仍返回nil结果 + 非空 error - 避免用
errors.Unwrap逐层解包，直接用errors.Is或字符串匹配更稳定 - 兜底函数
getDefaultUser()必须无副作用、零延迟，禁止含 time.Now()、rand.Intn() 等不可控行为
Redis 缓存失效时怎么防止击穿导致全量降级？
当热点 key 过期瞬间大量请求穿透到下游，如果下游又挂了，所有请求立刻走降级——这会让兜底逻辑本身成为瓶颈，甚至拖垮整个服务。
关键不是“要不要降级”，而是“降级能不能扛住流量”。解决方案必须包含缓存预热与互斥重建：
- 使用
SET key value EX 300 NX命令尝试占位，仅一个 goroutine 执行回源，其余等待或读旧值 - 降级数据也建议写入本地 LRU（如
github.com/hashicorp/golang-lru），避免每次降级都构造对象 - 对降级响应增加简单随机抖动（如
time.Sleep(time.Microsecond * time.Duration(rand.Intn(50)))），缓解瞬时并发
Go 的 defer 不适合做降级清理？
是的。defer 在函数 return 后才执行，无法干预主流程的响应生成。比如你希望「主调用失败 → 立即返回降级 JSON → 记录日志」，把日志记录写在 defer 里，就可能在降级返回后很久才打点，监控告警滞后。
降级动作必须同步完成，且顺序可控：
- 降级前先检查资源可用性（如本地缓存是否存在、内存是否充足）
- 降级响应体应提前序列化好，避免在降级路径中调用
json.Marshal引发 panic - 日志记录和指标上报要放在降级逻辑块内部，而不是靠 defer 补漏
最易被忽略的是：降级不是“有就行”，而是“快、稳、可预期”。很多团队实现了一堆 fallback，却没压测过降级路径的 P99 延迟——它往往比主路径还慢，因为加了锁、日志、序列化、甚至远程配置拉取。
