gin 不管理连接生命周期，依赖 net/http 的超时参数：readtimeout、writetimeout、idletimeout 和 readheadertimeout；必须显式设置 idletimeout（如60秒）并手动构建 http.server，弃用 r.run()。
Gin 本身不管理连接生命周期，底层完全依赖 net/http 的 HTTP/1.1 Keep-Alive 和超时控制
HTTP 服务器的超时参数决定非活跃连接何时关闭
Gin 没有自己实现连接池或心跳检测，它只是 net/http.Server 的封装。真正决定“非活跃连接是否释放”“释放多久后释放”的，是 http.Server 的四个超时字段：
-
ReadTimeout：从连接建立到读完请求头（含 body）的最大时间，超时则直接关闭连接 -
WriteTimeout：从开始写响应到写完的总耗时上限，超时也会断连 -
IdleTimeout：HTTP/1.1 Keep-Alive 空闲连接的最大存活时间（推荐显式设置，否则用默认值 0，即不限制空闲时间） -
ReadHeaderTimeout：仅限制读取请求头的时间，比ReadTimeout更细粒度
如果你没显式配置，Go 1.8+ 默认 IdleTimeout 是 0（不限空闲），而 ReadTimeout 和 WriteTimeout 也是 0（不限制），这会导致连接长期挂起、文件描述符泄漏——尤其在客户端异常断连但服务端未感知时。
如何正确设置 IdleTimeout 防止连接堆积
生产环境必须显式设置 IdleTimeout，典型值为 30–90 秒。Gin 启动时需绕过 r.Run()，手动构建 http.Server：
r := gin.Default()
r.GET("/health", func(c *gin.Context) { c.JSON(200, gin.H{"ok": true}) })
<p>srv := &http.Server{
Addr: ":8080",
Handler: r,
IdleTimeout: 60 <em> time.Second,
ReadTimeout: 30 </em> time.Second,
WriteTimeout: 30 * time.Second,
}
log.Fatal(srv.ListenAndServe())
</p>
注意：r.Run() 内部调用的是 http.ListenAndServe，无法传入自定义 http.Server 实例，所以必须弃用它。
Keep-Alive 失效或连接假死的常见表现
即使设置了 IdleTimeout，你仍可能观察到连接不释放，原因包括：
- 客户端（如某些旧版 curl、Postman 或移动 App）未发送
Connection: keep-alive，每次请求都新建 TCP 连接，IdleTimeout不生效 - 反向代理（Nginx / ALB）覆盖了
Keep-Alive头或自身设置了更长的 idle 超时，导致 Gin 层的IdleTimeout被绕过 - 客户端发起请求后中途断网，但未发送 FIN 包，服务端无法触发
read错误，只能靠IdleTimeout被动回收 - 使用了长连接 WebSocket（通过
gorilla/websocket）——它会接管连接，完全脱离http.Server的超时控制
验证是否生效：启动服务后，用 ss -tuln | grep :8080 观察 ESTABLISHED 连接数，空闲几十秒后应明显下降。
最易被忽略的是：Gin 的 Default() 中间件里 Recovery 和 Logger 不影响连接释放逻辑，但如果你在 handler 里用了阻塞操作（比如无超时的数据库查询、time.Sleep），会卡住整个 goroutine，导致 WriteTimeout 成为唯一兜底——别指望 IdleTimeout 能救活卡死的写响应。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
