服务降级需主动设计而非简单加fallback：用context控制超时，区分transient与permanent错误，降级逻辑独立封装、无副作用，并配合熔断与动态开关。
服务降级不是加个 fallback 就完事
Go 本身没有内置的降级机制（比如 Spring 的 @HystrixCommand），必须靠组合 context.Context、time.AfterFunc、错误分类和显式分支来实现。盲目套用“超时就走降级”会掩盖真实问题——比如下游返回了 503 Service Unavailable，但你只判断了超时，结果把业务错误当成了网络抖动处理。
用 context.WithTimeout 控制主调用，但降级逻辑必须独立封装
不能把降级代码塞进 defer 或 recover 里——那属于 panic 恢复，不是降级。真正的降级是「主动选择次优路径」，比如查缓存代替查 DB、返回默认值代替实时计算、调用轻量接口代替重逻辑。
- 主流程用
ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)，并确保所有下游调用（HTTP、gRPC、DB）都接收并传递该ctx - 降级函数必须是纯函数或无副作用函数：不改状态、不发日志、不触发告警（这些应在主流程失败后统一处理）
- 避免在降级分支里再起 goroutine 或调用另一个可能失败的服务——这会让降级链失控
func getUser(ctx context.Context, userID string) (*User, error) {
// 主调用
user, err := callUserService(ctx, userID)
if err == nil {
return user, nil
}
if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
return fallbackUser(userID), nil // 明确的降级入口
}
return nil, err
}
区分 transient error 和 permanent error 再决定是否降级
不是所有错误都该触发降级。比如 user not found 是业务正常态，不该走兜底；而 connection refused 或 i/o timeout 才是需要降级的 transient 场景。
- HTTP 客户端建议用
http.DefaultClient.Transport配置MaxIdleConnsPerHost和IdleConnTimeout，避免连接池耗尽导致的假超时 - 对 gRPC 调用，检查
status.Code(err)：只有codes.Unavailable、codes.DeadlineExceeded等才考虑降级；codes.NotFound或codes.InvalidArgument应直接返回 - 数据库操作中，
sql.ErrNoRows不是错误，是预期结果；而"dial tcp: i/o timeout"才要触发降级
降级开关必须可动态控制，且带熔断联动
硬编码的降级开关等于没开关。上线后发现降级逻辑有 bug，或者下游恢复了但你的服务还在返回默认值——这就成了故障放大器。
立即学习“go语言免费学习笔记（深入）”；
- 用原子变量 + HTTP handler 控制开关：
var enableFallback atomic.Bool，暴露/admin/feature/fallback?enable=true - 降级不应孤立存在：建议和
gobreaker这类库配合，当错误率连续 10 秒 > 50%，自动打开熔断器，此时所有请求直走降级，不再尝试主路径 - 记录降级发生次数和原因（如
"fallback_due_to_context_timeout"），但别在每次降级时打 info 日志——高频降级会导致日志风暴
降级最易被忽略的一点：它和重试不是互斥关系。先重试 2 次（间隔指数退避），再降级，比直接降级更稳妥；但重试必须带 ctx 并共享同一个 deadline，否则会延长整体延迟。
