net.conn.setkeepalive不能替代空闲超时，因其仅控制内核tcp保活探测（延迟高、不可控、无go层回调），而空闲超时需应用层用setreaddeadline/setwritedeadline在每次i/o前重置计时器来实现。
为什么 net.Conn.SetKeepAlive 不能替代空闲超时
很多人以为开启 TCP keepalive 就能自动断掉长时间没数据的连接，其实不是。net.Conn.SetKeepAlive 只控制底层 TCP 的保活探测包（默认系统级间隔，Linux 通常是 2 小时），它不感知应用层逻辑——比如客户端发完请求就挂起、不再读响应，或者服务端写完数据后一直等下一条指令。这种“静默占用”必须由应用自己管。
真正需要的是：连接建立后，每次有读/写活动就重置计时器；一旦超时无任何 I/O，就主动关闭连接。
-
SetKeepAlive是内核行为，不可控、延迟高、不触发 Go 层回调 - 空闲超时必须在 Go 层用
SetReadDeadline和SetWriteDeadline配合业务逻辑手动维护 - HTTP/1.1 的
Keep-Alive: timeout=30是建议值，客户端不一定遵守，服务端仍需自己裁决
如何用 SetReadDeadline 实现服务端空闲检测
最常用也最直接的方式：每次调用 conn.Read 前设置一个相对当前时间的读截止时间。关键在于“每次读之前都重设”，而不是只设一次。
典型错误是只在连接刚建立时设一次 deadline，结果连接一动不动就永远卡着。正确做法是把 deadline 设置嵌入到读循环里：
for {
conn.SetReadDeadline(time.Now().Add(30 * time.Second))
n, err := conn.Read(buf)
if err != nil {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
log.Println("idle timeout")
return
}
return
}
// 处理 buf[:n]
}
- 务必在
Read调用前设置，否则可能漏掉刚到来的数据 - 不要用
time.AfterFunc单独起 goroutine 管理 timeout——竞态风险高，且无法感知实际 I/O 活动 - 如果协议支持多路复用（如 WebSocket），需在每个消息解析后重设，而不是每字节都设
http.Server 的 IdleTimeout 为什么有时不生效
Go 1.8+ 提供了 http.Server.IdleTimeout，但它只对 HTTP/1.x 的“keep-alive 连接空闲期”起作用，且依赖底层 net.Listener 正确实现 SetDeadline。常见失效场景：
- 使用自定义
net.Listener（如带 TLS 终止的代理层）但没透传 deadline 设置 - HTTP/2 连接不受
IdleTimeout控制——它由http2.Server.IdleTimeout单独管理，且默认为 0（不限制） - 连接上正有长轮询（如
text/event-stream）或流式响应（如Transfer-Encoding: chunked），只要写操作持续，就不算“idle”
验证是否生效：抓包看 FIN 是否在空闲期后发出，或在 http.Server.Handler 中打印 http.Request.RemoteAddr 和时间戳，观察连接复用情况。
客户端如何安全地维持长连接并感知服务端断连
客户端不能只靠 conn.Write 不报错就认为连接还活着。服务端可能已关闭连接但 FIN 还没到达，或者中间网络设备（如 NAT 网关）悄悄清除了连接状态。
可靠做法是：发送心跳请求 + 设置读超时，并检查返回是否完整：
conn.SetReadDeadline(time.Now().Add(10 * time.Second))
_, err := conn.Write([]byte("PING\n"))
if err != nil { return }
buf := make([]byte, 4)
n, err := conn.Read(buf)
if err != nil || n != 4 || string(buf) != "PONG" {
// 连接已断或异常
return
}
- 心跳内容要简单、可预测，避免和业务协议混淆（例如用固定长度纯文本而非 JSON）
- 读超时必须比心跳间隔短，否则会卡住；建议设为间隔的 60%~80%
- 不要在写完心跳后立刻
Read——有些服务端会批量响应，需确保读取完整应答
空闲超时不是配置开关，而是读写路径上的必经逻辑分支。最容易被忽略的是：写操作也要设 SetWriteDeadline，尤其在大文件上传或流式推送场景下——写阻塞同样会导致连接“假活”。
