直接用 context.WithTimeout 会失效，因为 Gin 的 *gin.Context 不感知子 context 的取消，需基于 c.Request.Context() 派生并注入 c.Request。
为什么直接用 context.WithTimeout 会失效？
在 Gin 中，很多人习惯在 handler 里调用 context.WithTimeout 包裹下游调用（比如 HTTP 请求或数据库查询），但发现超时后 handler 仍继续执行，甚至返回了结果。这是因为 Gin 的 *gin.Context 是基于 HTTP 连接生命周期管理的，它本身不参与 Go 原生 context.Context 的取消传播——你新建的子 context 被 cancel 了，但 Gin 的 c 对象没感知，也不会中断写响应或后续逻辑。
正确做法：用 c.Request.Context() 做源头
Gin 在每次请求开始时，会把底层 http.Request.Context() 绑定到 *gin.Context 上，这个 context 才是真正与连接生命周期联动的。只要下游操作接收并尊重这个 context，超时或客户端断开时它就会自动 cancel。
- 所有支持 context 的标准库调用（如
http.Client.Do、database/sql.QueryContext）必须传入c.Request.Context()，而不是自己 new 一个 - 不要用
c.Copy().Request.Context()或context.Background()替代，前者复制的是已绑定的 context，后者完全脱离请求生命周期 - 若需额外超时控制（比如限定 DB 查询最多 800ms），再基于
c.Request.Context()派生：ctx, cancel := context.WithTimeout(c.Request.Context(), 800*time.Millisecond)，并在 defer 中调用cancel()
中间件中提前注册超时，避免每个 handler 重复写
如果全站统一 3s 超时，推荐在中间件里设置，而不是每个 handler 自己处理。Gin 本身不提供内置超时中间件，但可用标准方式实现：
func TimeoutMiddleware(timeout time.Duration) gin.HandlerFunc {
return func(c *gin.Context) {
ctx, cancel := context.WithTimeout(c.Request.Context(), timeout)
defer cancel()
c.Request = c.Request.WithContext(ctx)
c.Next()
// 注意：这里无法主动终止正在写的 response，只能靠下游操作检查 ctx.Err()
if ctx.Err() == context.DeadlineExceeded {
c.AbortWithStatusJSON(http.StatusGatewayTimeout, gin.H{"error": "request timeout"})
}
}
}
关键点：
立即学习“go语言免费学习笔记（深入）”；
- 必须用
c.Request.WithContext()把新 context 注入 request，否则下游拿不到 -
c.AbortWithStatusJSON只在超时发生且 handler 尚未写响应时生效；若下游已开始写 body（比如流式响应），Gin 不会强行中断连接 - 该中间件要放在路由注册前，且不能放在
gin.Logger()之后——否则日志可能记录超时前的状态
容易被忽略的坑：HTTP 客户端和数据库驱动是否真支持 cancel？
即使你传了带 cancel 的 context，如果下游组件不检查或忽略 ctx.Err()，超时就形同虚设。
-
net/http.DefaultClient支持，但自定义http.Client必须确保Transport和CheckRedirect等字段不屏蔽 context（例如旧版http.Transport在某些 TLS 场景下可能卡住） -
database/sql的QueryContext/ExecContext接口才支持 cancel；直接用Query就不会响应 cancel - 第三方 SDK（如 AWS SDK Go v2）基本都支持 context，但 v1 版本多数不支持，务必查文档确认方法签名是否含
ctx参数 - goroutine 泄漏风险：启动 goroutine 但没监听
ctx.Done()，会导致超时后协程持续运行
真正的超时控制不是加一行 WithTimeout 就完事，而是整条调用链都得对 ctx.Err() 做响应。最常出问题的地方，往往在你自己写的异步逻辑或封装的工具函数里。
