c.Request.Context() 不能直接用 context.WithTimeout 包裹，因其已含 Gin 管理的关键数据（如 Keys、Errors、Params）和 cancel 逻辑；正确做法是基于它新建 context、替换 c.Request.Context() 并调用 c.Abort() 阻断后续执行，且业务 handler 必须主动适配 ctx.Err() 或使用支持 context 的 API。
为什么 c.Request.Context() 不能直接用 context.WithTimeout 包一层就完事？
因为 c.Request.Context() 已经是 Gin 内部管理的上下文，它可能已被中间件链或框架自身修改（比如加了 trace ID、deadline 等）。直接套一层 context.WithTimeout 后赋回 c.Request，虽然能生效，但会丢失原有上下文里的关键数据（如 gin.Context 自带的 Keys、Errors、Params），且后续中间件若依赖原始 context 的 cancel 逻辑（比如日志中间件监听 Done()），可能无法正确感知超时终止。
正确做法是：基于 c.Request.Context() 创建新 context，并显式替换请求对象；同时必须调用 c.Abort() 阻断后续 handler 执行 —— 否则超时后仍会继续走完所有 handler。
-
c.Request = c.Request.WithContext(ctx)是必须的，否则下游 handler 拿不到新 context -
c.Abort()必须在检测到ctx.Err() == context.DeadlineExceeded后立即调用，否则c.Next()之后的 handler 还会执行 - 不要省略
defer cancel()，哪怕只用一次 —— 泄露 cancel 函数会导致 goroutine 无法被回收
Timeout 中间件里为什么必须检查 ctx.Err() 而不是只靠 select？
因为 Gin 的 handler 是同步执行的，ctx.Done() 只是通知信号，不自动中断当前函数栈。如果你只在中间件里创建 timeout context，但业务 handler 里没主动监听 ctx.Done() 或检查 ctx.Err()，那超时到了也不会退出 —— 尤其当 handler 里有阻塞 IO（如数据库查询、HTTP 调用）且这些调用本身不支持 context 时，整个请求会卡死到超时时间结束才返回。
所以超时控制是“两层协作”：中间件负责设 context 并兜底响应；业务 handler 必须自己做适配。
- DB 查询要用
db.QueryContext(ctx, ...)，而不是db.Query(...) - HTTP 调用要用
http.DefaultClient.Do(req.WithContext(ctx)) - 自定义 long-running loop 必须手动
select { case - 即使用了
context.WithTimeout，不检查ctx.Err()就等于没超时
goroutine 场景下传 ctx 为什么不能直接用 c？
因为 *gin.Context 不是线程安全的，它的 Keys、Errors、index 等字段会被多个 goroutine 并发读写。如果在 handler 里启动 goroutine 并直接传入原始 c，可能出现 panic（如 concurrent map read and map write）或读到脏数据（比如 c.Get("user_id") 返回空或旧值）。
Gin 提供了 c.Copy()，它返回一个只读副本，内部复制了 Request、Keys、Errors 等字段，但禁止修改 index 和 handlers —— 适合异步任务使用。
- 必须用
c.Copy()，不能用c原样传进 goroutine -
c.Copy()不继承Request.Context()的 cancel 行为，需手动传入 timeout context：cCopy.Request = cCopy.Request.WithContext(timeoutCtx) - 如果 goroutine 里还要调用其他支持 context 的库（如
redis.Client.SetContext），必须显式传入这个新 context
全局超时 vs 接口级超时，哪个更实用？
接口级超时更可控。全局超时（比如用 http.Server.ReadTimeout）作用于整个连接生命周期，包括 TLS 握手、header 解析、body 读取等，一旦触发会直接关闭连接，客户端收不到任何响应；而接口级超时（通过中间件）只限制 handler 执行阶段，能返回明确错误码（如 504 Gateway Timeout）和可读提示，也方便按路径差异化设置（如上传接口设 30s，查询接口设 2s）。
但要注意：接口级超时无法覆盖 request body 读取阶段 —— 如果客户端发了个巨量 body，而你又没在 handler 开头用 c.Request.Body 做流式读取或限速，timeout 中间件根本不会触发，因为还没走到 c.Next()。
- 大文件上传必须配合
c.Request.MultipartForm或io.LimitReader控制 body 大小 - 全局
ReadTimeout仍建议设（比如 30s），防住恶意慢速攻击 - 接口级 timeout 值应略小于全局 ReadTimeout，避免冲突
实际中最容易被忽略的点是：超时 context 必须从入口一路透传到最深的 IO 调用点，中间任何一环漏掉，整条链就失效。比如 DB 层用了老版本 driver 不支持 context，或者某段 legacy 代码硬编码了 time.Sleep(10 * time.Second)，那再好的 timeout 中间件也拦不住。
