Go网络服务必须实现应用层心跳包，因为TCP Keep-Alive默认2小时才触发探测，且中间设备会主动断连，仅靠SetReadDeadline无法感知静默断连，需每次Read前动态设超时并双向验证心跳响应。
不引入应用层心跳包，go网络服务在多数真实网络环境中无法及时感知连接失效——这不是代码写得不够好，而是tcp协议和操作系统内核的保活机制根本达不到业务级可用性要求。
为什么TCP Keep-Alive默认2小时才触发探测
TCP Keep-Alive是内核级机制，其行为由三个不可控参数决定：tcp_keepalive_time（空闲多久开始探测，默认7200秒）、tcp_keepalive_intvl（探测间隔，默认75秒）、tcp_keepalive_probes（失败重试次数，默认9次）。这意味着：即使对端已断电或进程崩溃，本端最早也要等2小时+675秒（约3小时）才能收到ECONNRESET或判定连接死亡。业务系统不可能容忍这种延迟。
- Go的
net.Dialer.KeepAlive只影响Go标准库内部连接池（如http.Transport），不修改内核参数，也不能缩短首次探测等待时间 - 调用
tcpConn.SetKeepAlivePeriod()仅在Linux 3.7+生效，且仍受限于tcp_keepalive_time基线 - 中间设备（NAT网关、云负载均衡器）常主动kill空闲连接，它们根本不看TCP Keep-Alive包，只按自身超时策略（如5~30分钟）断连
只靠SetReadDeadline为什么拦不住“静默断连”
SetReadDeadline只在调用Read()时起作用。如果客户端彻底下线但服务端没再读取数据（比如连接处于空闲等待状态），读超时永远不会触发。此时连接句柄仍被持有，goroutine卡在conn.Read()阻塞，内存与文件描述符持续泄漏。
- 典型误用：
conn.SetReadDeadline(time.Now().Add(30 * time.Second))只设一次，后续无重置 → 超时后Read()返回io.EOF或timeout，但若连接已断开而服务端未读，该deadline毫无意义 - 正确做法：每次
Read()前都动态更新deadline，且必须配合心跳响应验证（例如收到"ping"必须回"pong"，否则单向通也不代表业务层存活） - 更隐蔽的问题：某些代理或防火墙会劫持并丢弃心跳包，但允许业务数据通过——这时
Read()能成功，Write()也看似正常，唯独心跳无响应，必须靠双向确认机制暴露
应用层心跳必须自己定义协议语义
OS层和Go运行时都不理解你的业务逻辑。“连接可写”不等于“服务可调用”。一个RPC服务可能TCP连接完好，但goroutine全部卡死在数据库锁上，此时发Write()仍成功，但Ping()方法永远不返回。
- 心跳不能只是发个
\x00字节：必须走完整业务路径（如调用注册的PingRPC方法、或解析并应答自定义帧头），否则测的是传输层，不是服务层 - 必须区分心跳超时与业务超时：RPC框架的
context.WithTimeout应独立于连接读写超时，避免慢查询误判为连接死亡 - 服务端清理连接时，不能只
conn.Close()：需同步从map[connID]*Session中删除、通知注册中心下线、释放关联的资源（如用户session、缓存锁）——这些动作OS完全不参与
真正容易被忽略的点在于：心跳间隔与超时阈值不是越小越好。30秒心跳+10秒超时看似灵敏，但在高并发场景下可能引发雪崩式重连；而把心跳包和业务包共用同一套序列号/加密逻辑，又会导致心跳失败时业务请求也被拒绝。平衡点必须结合网络RTT分布、服务SLA、以及中间设备策略来实测校准，没有通用值。
