Gin中超时控制必须用context.WithTimeout，HTTP客户端超时无效；熔断器需手动处理context超时错误并全局单例；降级须轻量且不依赖外部调用；异步任务需单独管理context与重试。
gin 中超时控制必须用 context.WithTimeout，不是 HTTP 超时
很多人误以为给 http.Client 设置 Timeout 就够了，其实 Gin 里真正起作用的是请求上下文的超时。Gin 的 handler 执行生命周期由 context.Context 控制，HTTP 客户端超时只影响下游调用，不终止当前 handler。
-
context.WithTimeout(c.Request.Context(), 3*time.Second)是唯一能中断 gin handler 执行的手段 - 必须在中间件里重写
c.Request：c.Request = c.Request.WithContext(ctx) - 后续所有业务逻辑（包括子 goroutine）都得显式检查
ctx.Err()，否则超时后仍会继续跑 - 别漏掉
c.Abort()—— 否则c.Next()之后的 handler 还会执行，可能重复写响应或 panic
熔断器要和超时联动，不能只靠 sony/gobreaker 自身配置
sony/gobreaker 默认只统计函数执行结果，但 Go 微服务里最常见失败原因是 context 超时，而 ctx.Err() == context.DeadlineExceeded 不会被自动计入失败计数。必须手动包装调用逻辑：
- 每次调用外部服务前，先判断
ctx.Err()，如果是超时，主动返回 error（比如errors.New("timeout")） - 把整个调用包裹进
cb.Execute()，且确保 error 类型一致（避免熔断器因 error 类型不同漏判） - 熔断器
ReadyToTrip函数建议同时检查ConsecutiveFailures和ConsecutiveSuccesses，防止抖动误熔 - 不要把熔断器实例定义在 handler 内——它必须是全局单例，否则每个请求新建一个就失去统计意义
降级逻辑必须轻量，且不能依赖任何可能再次超时的组件
降级不是“换个地方再试一次”，而是快速兜底。一旦触发熔断或超时，降级函数里不能再发起新的网络请求、DB 查询或调用其他服务。
- 推荐方案：返回本地缓存（
sync.Map或ristretto）、静态默认值、或上一次成功结果（需带时间戳校验新鲜度） - 如果要用 Redis 缓存做降级，必须单独配一套短超时（如
100ms）的 client，并且降级路径里不走熔断器——否则可能形成嵌套熔断 - 切忌在降级函数里调用
time.Sleep或复杂计算，它应该在微秒级完成 - 前端需要明确区分“无数据”和“服务不可用”，所以降级响应的
code字段应设为独立错误码（如50301），而不是复用 503
异步任务场景下，超时+熔断+降级全部失效，必须换思路
当 handler 启动 goroutine 做后台任务（比如发消息、同步数据），前面所有机制都不再适用——因为主流程已返回，context 已 cancel，熔断器状态也不再更新。
立即学习“go语言免费学习笔记（深入）”；
- 这类接口不该设短超时，而应立即返回任务 ID + 成功状态（
202 Accepted），让客户端轮询或监听 webhook - 后台 goroutine 必须用新 context（如
context.Background()），并自行管理重试与熔断（可复用同一gobreaker.CircuitBreaker实例） - 严禁在 goroutine 里访问
*gin.Context的任何字段（c.Param、c.Keys、c.Request等），只能提前拷贝所需值（字符串、int、结构体副本） - 降级在此类场景中体现为“任务提交成功但执行失败”，应记录日志并触发告警，而不是返回给用户
log.Printf("timeout on %s: %v", c.Request.URL.Path, ctx.Err()) 和熔断器状态回调。 
