Gin默认不处理客户端超时，因其仅封装net/http且遵循Go“超时由业务决定”的设计哲学；必须显式配置context超时中间件、http.Client超时及http.Server的Read/WriteTimeout三者协同防护。
为什么 Gin 默认不处理客户端超时
Gin 本身只是封装了 net/http，它不自动设任何超时——包括连接、读、写或整个请求生命周期。这意味着如果后端服务卡住、下游 API 响应慢、或网络中断，c.Next() 可能无限挂起，goroutine 泄漏，连接堆积。这不是缺陷，是 Go 的设计哲学：超时策略必须由业务决定。
用 context.WithTimeout 写中间件控制单请求生命周期
这是最常用也最可控的方式，适用于绝大多数 API 场景。核心是把带超时的 context.Context 注入请求，并在超时后中止后续 handler：
-
c.Abort()必须加，否则即使 context 已 cancel，后续 handler 仍会执行 - handler 内部若启动子 goroutine（比如调用第三方服务），必须显式传入该 context 并监听
ctx.Done()，否则子 goroutine 不受超时约束 - 中间件只负责兜底响应（如返回
http.StatusGatewayTimeout），业务逻辑里仍需主动检查ctx.Err() == context.DeadlineExceeded来提前退出耗时操作
示例中间件：
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()
}
}
}注册方式：router.GET("/api/data", Timeout(5*time.Second), dataHandler)
立即学习“go语言免费学习笔记（深入）”；
HTTP 客户端发起请求时也要设超时
如果你的 Gin handler 里要调用其他服务（比如用 http.Client 请求下游 API），那这个 client 自身也必须设超时。否则中间件超时了，但 goroutine 里还在等一个没设超时的 client.Do()，照样卡死。
- 最简方式：
&http.Client{Timeout: 8 * time.Second}，覆盖 DNS + 连接 + 写 + 读全过程 - 精细控制需自定义
http.Transport：比如DialContext控连接、ResponseHeaderTimeout控首字节响应、TLSHandshakeTimeout控 HTTPS 握手 - 错误判断别用
err == context.DeadlineExceeded，要用errors.Is(err, context.DeadlineExceeded)或net.Error.Timeout()
别忽略服务端 TCP 层的 Read/Write 超时
Gin 中间件和 http.Client 超时都作用于应用层逻辑，但底层 TCP 连接本身也可能僵死。比如客户端断开后没发 FIN，服务端还傻等读数据——这时靠 http.Server 的 ReadTimeout 和 WriteTimeout 才能真正释放连接。
- 这两个字段必须显式设置，Go 默认为 0（即永不超时）
-
ReadTimeout从连接建立开始计时，到读完完整 request body 结束；WriteTimeout从 request header 解析完开始，到 response body 全部写出结束 - 它们和中间件超时不冲突，而是互补：中间件控业务逻辑耗时，Server 级超时控网络层僵死
启动时配置：srv := &http.Server{Addr: ":8080", Handler: router, ReadTimeout: 10 * time.Second, WriteTimeout: 10 * time.Second}
实际部署时，这三个层面（中间件 context、client 超时、server Read/Write）往往都要配，且数值需有梯度：比如中间件设 5s，client 设 8s，server 设 10s，避免因某一层未触发而让请求“漏过去”。
