Gin高并发TCP连接超时本质是net/http.Server生命周期管理未匹配业务场景，需显式配置ReadTimeout、ReadHeaderTimeout和IdleTimeout三参数，并同步调优Nginx代理层与下游依赖的上下文超时联动。
高并发下 Gin 应用出现 TCP 连接超时，本质不是 Gin 框架的问题，而是 net/http.Server 层的连接生命周期管理没对齐业务场景。直接调 engine.ReadTimeout 或改 Nginx proxy_read_timeout 只能缓解表象，治标不治本。
为什么 ReadTimeout / WriteTimeout 在高并发下失效
这两个字段是 http.Server 级别配置，作用于整个 TCP 连接（含 TLS 握手、header 解析、body 读取），一旦触发就粗暴关闭连接，不走 Gin 中间件链，也不调 c.Abort()。更关键的是：
- 它们无法区分路由——你给上传接口配了 10 分钟，登录接口也得等满 10 分钟才断开
- 高频短连接场景下，
ReadTimeout会把刚建连还没发请求的空闲连接提前干掉，造成大量connection reset by peer - Go 1.26+ 默认
ReadTimeout=0，但底层 TCP keepalive 仍可能在 2 小时后断连，日志里只显示read: connection timed out，无从定位
真正该调的三个 timeout 参数
必须显式初始化 http.Server 实例，并设置以下三项（Gin 的 Run() 内部只是个封装）：
-
ReadTimeout：控制“从连接建立到读完 request header”的最大时间，建议设为5 * time.Second（防慢速攻击） -
ReadHeaderTimeout：仅限制“读 header”的耗时，和 body 无关，建议3 * time.Second（比 ReadTimeout 更精准） -
IdleTimeout：控制“连接空闲多久后关闭”，这才是高并发下防 TIME_WAIT 堆积的关键，建议60 * time.Second
示例：
srv := &http.Server{
Addr: ":8080",
Handler: r, // gin.Engine
ReadTimeout: 5 * time.Second,
ReadHeaderTimeout: 3 * time.Second,
IdleTimeout: 60 * time.Second,
}
srv.ListenAndServe()反向代理层必须同步调整
Nginx 或 Envoy 不只是转发，它本身也维护连接池。若只调 Go 层，Nginx 仍可能先断连：
-
proxy_connect_timeout 3s：和 Go 的DialContext超时对齐 -
proxy_send_timeout 30s：对应下游写响应的上限（尤其流式接口） -
proxy_read_timeout 60s：必须 ≥ Go 的IdleTimeout，否则 Nginx 先关连接 - 禁用
proxy_buffering off：避免 Nginx 缓冲响应体导致 Go 层感知不到写阻塞
连接池与上下文超时必须联动
TCP 连接超时只是入口，真正的瓶颈常在下游依赖。比如 DB 查询卡住，会让连接一直挂着不动，最终被 IdleTimeout 干掉：
- 所有下游调用（
db.QueryContext()、redis.Client.Do(ctx, ...)、http.Client.Do(req.WithContext(c.Request.Context()))）必须传入原始请求的context.Context - MySQL 连接池要设
db.SetConnMaxLifetime(1*time.Hour)，防止连接老化后被 MySQL 主动 kill 导致i/o timeout - Redis PoolSize 至少设为预估峰值并发的 1.5 倍，否则 goroutine 会在
pool.Get()上排队，间接拖长连接生命周期
最易被忽略的一点：Gin 的 c.Request.Context() 是随连接创建的，但如果你在 handler 里启了子 goroutine 去做异步操作（如上报日志），必须显式传入这个 ctx 并监听 ctx.Done()，否则连接已断，后台还在跑，资源持续泄漏。
