TCP连接会悄无声息断开是因为NAT/防火墙等中间设备存在5–30分钟空闲超时，而Go的net.Conn不感知此状态；需应用层主动发带验证响应的心跳包，并结合SetReadDeadline实现可靠保活。
为什么 TCP 连接会悄无声息地断开
不是网络突然挂了才断连，而是中间 NAT 设备、防火墙、负载均衡器普遍有连接空闲超时（通常 5–30 分钟），一动不动就回收连接。Go 的 net.Conn 本身不感知这个，Write 可能还成功（数据进了内核发送缓冲区），但对端早已关闭——你发出去的心跳包根本没走远。
- 别依赖
conn.SetDeadline单纯防本地阻塞，它不解决中间链路静默断连 - 心跳必须由应用层主动发起，且要带可验证的响应（比如回传时间戳或序列号）
- 服务端不能只靠
Read返回io.EOF才清理连接——客户端可能卡在半路，连接状态已失效
用 SetReadDeadline + 定时 Write 实现可靠心跳
核心思路：每次成功读/写后重置读超时；心跳定时器只负责发包，不等响应；真正判断是否存活，看下一次 Read 是否超时。
- 客户端侧：启动一个
time.Ticker，每 25 秒调用conn.Write发一个短心跳包（如[]byte{0x01}），同时确保每次Read前都调用conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 服务端侧：同样为每个连接维护读超时，收到心跳后立刻重置，不响应也行（减小开销），但必须更新 deadline
- 注意
SetReadDeadline影响后续所有Read，包括心跳包的读取，所以心跳处理逻辑必须包含在正常读循环里，不能单独 goroutine 阻塞读
// 示例：服务端读循环片段
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() {
// 连续两次读超时才判定断连
if lastReadTimeout {
closeConn(conn)
return
}
lastReadTimeout = true
continue
}
closeConn(conn)
return
}
lastReadTimeout = false
handlePacket(buf[:n])
}
KeepAlive 系统级选项只能辅助，不能替代应用层心跳
Go 的 net.Conn 支持 SetKeepAlive 和 SetKeepAlivePeriod，但这只是启用 TCP 层的 SO_KEEPALIVE，默认间隔是 2 小时（Linux），且无法穿透大部分中间设备——NAT 早把你踢了，TCP keepalive 根本发不到对端。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 开启方式：
tcpConn.SetKeepAlive(true)+tcpConn.SetKeepAlivePeriod(30 * time.Second)（需 Go 1.19+） - 仅建议作为兜底：防止进程僵死连接占用资源，但业务逻辑绝不能依赖它保活
- Windows 默认 keepalive 时间更长，行为不一致，跨平台部署时尤其不可靠
心跳包设计和连接管理容易被忽略的细节
心跳不是发个字节就完事，协议设计和状态同步才是关键。
立即学习“go语言免费学习笔记（深入）”；
- 心跳包要有唯一标识（如递增
seq或时间戳），服务端可识别重复包、乱序包，避免误判 - 不要在心跳 goroutine 里直接
conn.Write并忽略错误——如果写失败（比如连接已关），得通知主读循环退出 - 连接池或长连接管理器中，必须把心跳失败与业务读写失败同等对待：立即标记为“待驱逐”，不再分发新请求
- 测试时用
iptables -A OUTPUT -p tcp --dport 8080 -j DROP模拟单向丢包，比直接kill -9更真实
真正难的不是发心跳，而是让整个连接生命周期里的读、写、超时、错误、重连全部串成一条因果链——任何一个环节断掉，都会让“长连接”变成“伪长连接”。
