Gin中间件不适合无损降级，因其同步不可中断，无法在不执行handler前提下安全替换下游依赖；降级必须在handler内通过上下文开关控制，并保持响应结构一致。
为什么 Gin 的中间件不适合直接做「无损降级」
因为 gin.HandlerFunc 是同步执行、不可中断的：一旦进入中间件链，后续 handler 就一定会被调用（除非显式 c.Abort() 或 panic）。所谓“无损降级”，本质是「在不改业务逻辑、不抛错、不丢请求的前提下，把下游依赖（如 DB/Redis/第三方 API）替换为兜底响应」——这需要在业务 handler 内部做控制，而非靠中间件拦截后绕过 handler。
真正可行的降级位置：在 handler 里用 context.WithValue 注入降级开关
推荐做法是把降级决策下放到 handler 内部，由中间件仅负责设置上下文状态，不干预执行流：
- 中间件读取配置（如 Redis 中的
feature:order-service:degrade）、请求头（X-Force-Degraded）或熔断器状态，调用c.Set("degraded", true)或写入c.Request.Context() - handler 中通过
c.MustGet("degraded")或c.Value("degraded")判断是否启用降级 - 降级逻辑必须和原逻辑保持相同返回结构（HTTP 状态码、JSON 字段、Header），否则前端会解析失败
示例片段：
// 中间件
func DegradationMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
// 检查全局降级开关（例如从 etcd 获取）
if isGlobalDegraded() {
c.Set("degraded", true)
}
c.Next()
}
}
// handler
func GetOrderHandler(c *gin.Context) {
if degraded := c.MustGet("degraded"); degraded == true {
c.JSON(200, map[string]interface{}{
"code": 0,
"data": map[string]string{"status": "mocked"},
})
return
}
// 原逻辑：调用 orderService.Get(...)
}
别在中间件里调 c.Abort() 后硬塞 JSON
这是常见误用：中间件发现要降级，直接 c.Abort() + c.JSON()。问题在于：
- 违反 Gin 的中间件职责边界 —— handler 才该决定返回什么
- 无法复用 handler 的日志、监控、traceID 注入等统一逻辑
- 若多个中间件都尝试 Abort，行为不可预测（比如鉴权中间件已 Abort，降级中间件再 Abort 会 panic）
- HTTP 状态码可能不一致（比如原 handler 返回 404，降级返回 200，前端路由或重试策略会出错）
更健壮的做法：用接口抽象 + 依赖注入替代硬编码降级
当降级逻辑变复杂（比如需查本地缓存、生成 mock 数据、调用备用服务），建议把业务逻辑封装成接口，运行时按条件注入不同实现：
- 定义
OrderService接口，含Get(id string) (Order, error) - 实现
RealOrderService和FallbackOrderService - 中间件设置 context key：
c.Request = c.Request.WithContext(context.WithValue(c.Request.Context(), serviceKey, fallbackImpl)) - handler 从 context 取服务实例，调用统一方法 —— 代码零修改，只换实现
这种模式能应对灰度、AB 测试、多级降级（缓存 → mock → 空响应）等真实场景，且测试友好。
关键点在于：降级不是“跳过业务”，而是“换一种方式完成业务”。所有路径最终都该走到同一个 handler 出口，否则就埋下了兼容性雷。
