net.Conn.Read不返回io.EOF不代表连接存活，因TCP双向状态机不感知业务在线性；NAT超时、断电等场景下Read会无限阻塞，Write可能仍成功，必须依赖应用层心跳+短时SetReadDeadline（25–30秒）主动探测。
为什么 net.Conn.Read 不返回 io.EOF 就代表连接还活着
因为 tcp 连接是双向状态机，内核只管收发缓冲区和 ack 序列，不关心业务是否“真在线”。客户端断电、nat 超时、防火墙静默丢包后，conn.write 可能仍成功（数据进了发送缓冲区），conn.read 却一直阻塞——它等的不是“对端关连接”，而是“对端发来的数据”，而对方早已不回包了。
常见错误现象：
服务端 goroutine 卡在 conn.Read 上数小时不退出；客户端重连后旧连接还在内存里占着资源；监控显示“1000 个连接活跃”，实际 300 个已失效。
- 别依赖
io.EOF做连接清理依据：它只在对端明确发 FIN 或 RST 时才出现，而 NAT 超时、中间设备回收连接时根本不会触发 -
conn.SetReadDeadline必须每次Read前调用，且超时时间要短于中间设备空闲阈值（通常设为 25–30 秒） - 心跳包必须由应用层主动发，不能只靠
SetKeepAlive：Linux 默认 keepalive 探测间隔是 2 小时，Go 的SetKeepAlivePeriod虽可设为 30 秒，但多数云负载均衡器、家用路由器根本不转发 keepalive TCP 包
心跳包必须带可验证响应，不能只发不收
单纯往 conn.Write 里塞 []byte{0x01} 是无效的。如果服务端不解析、不响应、也不重置读超时，那这个包就只是“单向噪音”，起不到检测作用。
使用场景：
游戏服务器中玩家挂机 28 分钟后，客户端未发任何业务包，仅靠心跳维持连接；微服务注册中心要求实例每 15 秒上报一次心跳并等待 ACK，超时三次即下线。
- 服务端收到心跳后，必须立刻调用
conn.SetReadDeadline更新超时时间，否则下次Read仍会因旧 deadline 触发超时 - 心跳响应建议含时间戳或序列号（如
binary.Write(&buf, binary.BigEndian, uint64(time.Now().UnixNano()))），避免伪造包干扰判断 - 客户端心跳定时器（
time.Ticker）只负责发包，不阻塞等待响应；存活判定交给下一次Read是否超时——这才是轻量又可靠的逻辑
SetKeepAlive + SetKeepAlivePeriod 为什么不能替代应用层心跳
Go 1.19+ 支持 tcpConn.SetKeepAlive(true) 和 tcpConn.SetKeepAlivePeriod(30 * time.Second)，但这只是启用内核 TCP 层的 SO_KEEPALIVE，行为受系统全局参数制约，且穿透性极差。
性能 / 兼容性影响：
在 AWS ALB、阿里云 SLB、华为云 ELB 等主流负载均衡器后面，keepalive 探针大概率被直接丢弃；Android/iOS 移动端热点 NAT 超时普遍为 5–10 分钟，keepalive 来不及触发就被清连接了。
- Linux 上需同时修改三个 sysctl 参数才能真正缩短探测周期：
net.ipv4.tcp_keepalive_time、net.ipv4.tcp_keepalive_intvl、net.ipv4.tcp_keepalive_probes，而这会影响本机所有 TCP 连接 - macOS 和 Windows 对 keepalive 参数支持更弱，部分版本甚至无法单独 per-connection 设置
- 即使 keepalive 成功发出，它只探测“链路是否通”，不验证“对端进程是否存活”——服务端进程卡死但 socket 未关，keepalive 仍能通过
客户端重连时容易忽略的半开连接残留
客户端崩溃后重启，新连接建立成功，但旧连接在服务端可能还处于 ESTABLISHED 状态长达几十分钟——这不是 bug，是 TCP 协议设计使然。此时若服务端没做心跳检测，就会持续给一个不存在的客户端发消息、占 goroutine、耗内存。
容易踩的坑：
用 map 存连接时只靠 conn.RemoteAddr() 当 key，导致新老连接冲突；清理连接时只 close conn，忘了从 session 管理结构中 delete 对应项；心跳超时后只 close conn，没通知上层业务做资源释放（如踢出房间、注销 token）。
- 每个连接必须绑定唯一 ID（如 UUID 或自增 int64），不能仅靠地址+端口识别
- 心跳失败后，清理动作要原子：close conn → 从管理 map 中 delete → 触发 callback（如通知 registry 下线）
- 服务端读循环里一旦
err != nil且非 timeout，应立即 break 并 cleanup；连续两次 read timeout 才判定断连，避免偶发网络抖动误杀
真实问题往往不在“怎么发心跳”，而在“谁来信得过地判断它失效了”。应用层心跳不是加一层冗余，而是把连接状态的解释权从不可控的中间网络，拿回到自己手里。
