Gin 默认不处理TCP层心跳包超时，因其仅运行于net/http之上，而TCP连接空闲超时由底层net.Listener和操作系统控制；http.Server.IdleTimeout才真正管理连接空闲时长，需显式设置。
为什么 Gin 默认不处理 TCP 层心跳包超时
Gin 本身是 HTTP 路由框架，运行在 net/http 之上，而 HTTP 是无状态短连接协议（即使用了 Keep-Alive，也是应用层复用）。真正的 TCP 连接空闲超时、心跳探测、FIN/RST 响应等，由底层 net.Listener 和操作系统 TCP 栈控制，Gin 完全不感知。你看到的 ReadTimeout / WriteTimeout 实际是 http.Server 的字段，只约束单次请求的读写耗时，不是连接空闲超时。
常见误判现象：curl -v http://localhost:8080/api 发起后立刻断网，服务端数分钟才报错——这不是 Gin 或 HTTP 超时没生效，而是 TCP 连接仍处于 ESTABLISHED 状态，内核尚未触发保活重传失败。
-
http.Server.ReadTimeout只限制从Accept到读完 request header 的时间，不包含 body 流式上传或长连接空闲 -
http.Server.IdleTimeout才真正控制连接空闲时长（Go 1.8+ 支持），但默认为 0（禁用），必须显式设置 - Linux 内核的
tcp_keepalive_time（默认 7200 秒）远大于业务需求，不能依赖它做快速断连
如何用 http.Server.IdleTimeout 精准控制空闲连接生命周期
这是最直接、最符合 Go 原生语义的方式。Gin 启动时传入自定义 http.Server，显式启用并设置 IdleTimeout：
srv := &http.Server{
Addr: ":8080",
Handler: r, // your *gin.Engine
IdleTimeout: 30 * time.Second,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
}
log.Fatal(srv.ListenAndServe())
注意：IdleTimeout 从最后一个 response 写完或 request 读完开始计时，期间无任何数据收发即触发关闭。它对 HTTP/1.1 Keep-Alive 和 HTTP/2 都有效。
- 若客户端每 25 秒发一次
OPTIONS /health心跳，IdleTimeout=30s就能保证连接不被误杀 - 值设太小（如
5s）会导致正常慢客户端频繁断连；太大（如5m）则无法及时释放僵尸连接 - 该字段与
KeepAlive（TCP 层 socket 选项）无关，Go 不暴露SetKeepAlive给http.Server，需手动干预 listener
需要更细粒度控制？用 net.ListenConfig 设置 TCP keepalive
当你要在连接建立瞬间就开启系统级心跳探测（比如防止 NAT 设备静默丢弃连接），就得绕过 http.ListenAndServe，自己构造 listener：
lc := &net.ListenConfig{
KeepAlive: 15 * time.Second,
}
l, err := lc.Listen(context.Background(), "tcp", ":8080")
if err != nil {
log.Fatal(err)
}
srv := &http.Server{Handler: r, IdleTimeout: 30 * time.Second}
log.Fatal(srv.Serve(l))
这里 KeepAlive 是传给 setsockopt(SO_KEEPALIVE) 的间隔，实际行为取决于 OS：Linux 下会设 tcp_keepalive_time，Windows 下是 KeepAliveTime。它和 IdleTimeout 是互补关系——前者让内核主动探测，后者让 Go 主动关闭。
- 仅设
KeepAlive不设IdleTimeout：内核可能探测到断连，但 Go 不知道，连接对象仍驻留内存 - 仅设
IdleTimeout不设KeepAlive：空闲连接要等到超时才关，期间无法感知中间网络设备已断开 - 生产环境建议两者都设，且
KeepAlive （例如 15s vs 30s），确保探测早于超时
客户端不发心跳怎么办？用 context.WithTimeout 在 handler 内兜底
有些老旧设备或嵌入式客户端根本不发心跳，只维持 TCP 连接空转。此时仅靠服务端超时不够，得在业务逻辑中埋点检测：
r.GET("/stream", func(c *gin.Context) {
ctx, cancel := context.WithTimeout(c.Request.Context(), 45*time.Second)
defer cancel()
<pre class="brush:php;toolbar:false;">c.Stream(func(w io.Writer) bool {
select {
case <p>})</p>关键点：c.Request.Context() 会继承 http.Server.IdleTimeout 的截止时间，但你在 handler 中用 context.WithTimeout 可覆盖它，实现 per-request 级别的精细控制。
- 不要用
time.Sleep模拟长轮询——它阻塞 goroutine，无法响应连接中断 - 所有阻塞 I/O（如
conn.Read,db.QueryRow）必须传入带超时的context，否则IdleTimeout触发时 goroutine 仍卡住 - WebSocket 场景同理，用
conn.SetReadDeadline+context双保险，因为gorilla/websocket不自动继承http.Server超时
真正难的不是设哪个参数，而是厘清「TCP 连接空闲」「HTTP 请求处理」「业务逻辑执行」三层超时的边界。一个参数改错，轻则连接泄漏，重则雪崩。别指望 Gin 自动帮你串起来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
