gin默认不处理请求超时，因其仅为路由框架，不自动注入超时context；必须通过中间件调用context.withtimeout替换c.request.context()、业务层显式监听ctx.err()并调用c.abort()阻断后续执行，三者缺一不可。
Gin 里设超时，不能只靠 http.Client.Timeout 或手写 time.After，必须用 context.WithTimeout + 中间件 + 业务层显式监听，三者缺一不可。
为什么 Gin 默认不处理请求超时
Gin 本身是 HTTP 路由框架，不介入底层连接或上下文生命周期管理。它把 *http.Request 包装成 *gin.Context，但不会自动为每个请求注入超时 context。如果你没主动传、没主动检查、没主动 abort，超时就只是个摆设。
-
router.Use(gin.Recovery())这类中间件不包含超时逻辑 -
http.Server.ReadTimeout/WriteTimeout是 TCP 层级的，只管连接建立后读/写首行或响应头，不管 handler 执行耗时 - 直接在 handler 里写
time.Sleep(10 * time.Second)，不配 context，Gin 完全无法中断它
用自定义中间件设请求处理超时（Timeout）
这是最常用也最容易出错的方式。核心是替换 c.Request.Context()，并确保 c.Abort() 阻断后续 handler。
- 必须调用
c.Abort()，否则c.Next()后的 handler 仍会执行，可能重复写响应或 panic - 中间件只负责设 context 和返回
504 Gateway Timeout，业务 handler 内仍要检查ctx.Err() == context.DeadlineExceeded - 如果 handler 启了子 goroutine（比如异步发消息），必须把
c.Request.Context()显式传进去，并在子 goroutine 中监听ctx.Done() - 示例中间件：
func Timeout(duration time.Duration) gin.HandlerFunc { return func(c *gin.Context) { ctx, cancel := context.WithTimeout(c.Request.Context(), duration) defer cancel() c.Request = c.Request.WithContext(ctx) c.Next() if ctx.Err() == context.DeadlineExceeded { c.Status(http.StatusGatewayTimeout) c.String(http.StatusGatewayTimeout, "request timeout") c.Abort() } } }
HTTP Client 请求下游服务时怎么设超时
你在 Gin handler 里调第三方 API，这时超时控制分两层：本请求的总时限（上一节中间件）、以及对下游的单次调用时限。后者必须用 context.WithTimeout + req.WithContext()。
- 别只设
http.DefaultClient.Timeout = 5 * time.Second—— 它无法覆盖已存在的 context 超时，且所有请求共用一个值 - 每次调下游前，都要新建 context：
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second)，再defer cancel() - 必须把 context 注入 request：
req = req.WithContext(ctx)，否则http.Client.Do(req)根本不感知超时 - 常见错误：写了
select { case 却没关掉正在 Do 的 goroutine，导致连接泄漏
容易被忽略的 TCP 连接阶段超时
你用 net/http 或 database/sql 连外部服务时，超时不止发生在读响应体，还卡在 DNS、TLS 握手、TCP 建连、甚至 write buffer 满的时候。这些必须用底层原生机制控制，不能靠 context 补救。
- Dial 阶段：用
&net.Dialer{Timeout: 3 * time.Second}，不是net.DialTimeout - 读操作：每次
conn.Read()前调conn.SetReadDeadline(time.Now().Add(2 * time.Second)) - 写操作：同样每次
conn.Write()前调conn.SetWriteDeadline(...)，不设写超时比读更危险 - DB 连接池：用
db.SetConnMaxLifetime和db.SetMaxOpenConns配合context，否则超时后连接还在池里空转
超时不是加个 timer 就完事，而是 context 信号 + 底层 deadline + 显式 cancel 的组合动作。漏掉任意一环，都可能让 goroutine、连接、内存缓慢堆积，直到某天凌晨三点报警响起来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
