gin中间件设超时只控制handler执行，不控制下游调用；必须在http client等各层显式传ctx并配置dialcontext、tlshandshaketimeout等多级超时。
强依赖接口不设超时，等于把整个服务的稳定性押在下游身上。Gin 本身不处理 RPC 超时，它只管 HTTP 请求生命周期；真正需要控制的是你调用下游服务（比如另一个微服务）的 client 层——比如 http.Client、grpc.ClientConn 或 go-zero 的 rpcx.Client。
为什么 Gin 中间件里加 timeout.WithTimeout 没用？
很多人试图在 Gin 中间件里对整个 handler 加 context.WithTimeout，但这只控制 handler 执行时间，**不控制你内部发起的 http 请求或 RPC 调用**。一旦下游卡住、没响应，你的 handler 可能早被 cancel 了，但那个 goroutine 里的 http.Do() 还在等，造成泄漏。
- 错误写法：
ctx, cancel := context.WithTimeout(c.Request.Context(), 500*time.Millisecond)然后传给业务逻辑，但业务里又用了一个没带 context 的http.DefaultClient - 正确做法：所有外部调用必须显式接收并使用传入的
ctx，且 client 必须配置Timeout或用ctx控制底层连接 - 常见漏点：数据库连接池（
sql.DB）、Redis client（redis.Client）、自定义 HTTP client 都要确认是否支持 context 传递
HTTP client 超时必须分三层配
只设 http.Client.Timeout 是不够的，它只覆盖“从 connect 完成到读完 body”的时间。真实链路中还有 DNS 解析、TCP 建连、TLS 握手等环节，这些都可能卡死。
-
Transport.DialContext：控制建连超时（含 DNS + TCP），建议设为3s -
Transport.TLSHandshakeTimeout：TLS 握手超时，建议3s -
Timeout（顶层）：整个请求生命周期上限，建议5s，且必须小于 handler 的 context timeout - 示例：
client := &http.Client{<br> Timeout: 5 * time.Second,<br> Transport: &http.Transport{<br> DialContext: (&net.Dialer{<br> Timeout: 3 * time.Second,<br> KeepAlive: 30 * time.Second,<br> }).DialContext,<br> TLSHandshakeTimeout: 3 * time.Second,<br> },<br>}
降级逻辑不能只靠 defer recover
panic 恢复只能兜底程序崩溃，对超时、网络错误、5xx 返回码这类“业务失败”完全无效。降级必须是显式判断 + 明确 fallback 路径。
- 错误姿势：用
defer func(){ if r := recover(); r != nil { ... } }()捕获超时 ——http.Client不会 panic，只会返回 error - 正确姿势：检查
err类型，区分context.DeadlineExceeded、net.ErrClosed、io.EOF等，并触发对应 fallback - 示例降级分支：
resp, err := client.Do(req.WithContext(ctx))<br>if err != nil {<br> if errors.Is(err, context.DeadlineExceeded) {<br> c.JSON(200, gin.H{"data": defaultData, "fallback": "timeout"})<br> return<br> }<br> c.JSON(503, gin.H{"error": "downstream unavailable"})<br> return<br>} - 注意：降级数据要轻量，避免再触发一次外部调用（比如 fallback 里又查一次 Redis）
真正的难点不在写几行超时代码，而在于每个下游 client 实例是否统一注入了带超时的 context、是否所有 error 分支都被覆盖、fallback 数据是否经过压测验证可用。线上一个没设 DialContext 的 HTTP client，足以让整条链路在 DNS 故障时集体 hang 死。
