仅设setkeepalive(true)无法真正保活tcp连接，必须在应用层实现带响应验证的心跳逻辑；否则nat、防火墙会在30–300秒内静默断连，而write可能成功返回造成“连接活着”的假象。
只设 SetKeepAlive(true) 无法真正保活 TCP 连接，必须在应用层实现带响应验证的心跳逻辑；否则 NAT、防火墙会在 30–300 秒内静默断连，而你的 Write 还可能成功返回，造成“连接活着”的假象。
为什么 SetKeepAlive 不够用
TCP 层的 SO_KEEPALIVE 默认 2 小时才发第一个探测包，且中间设备（如阿里云 SLB、家用路由器）普遍忽略或丢弃这些底层包。Go 的 SetKeepAlivePeriod（1.19+ 支持）最小生效值受 OS 限制（Linux 通常 ≥ 1s），即使设成 10 * time.Second，也仅触发内核探测，不保证对端响应、不感知应用层崩溃。
常见错误现象：
-
conn.Write一直成功，但后续业务数据发不出去 - 服务端
Read突然卡住或返回io.EOF，无任何前置错误 - 连接看似活跃，实则已被 NAT 回收，新请求全失败
用 time.Ticker 发心跳 + SetWriteDeadline 防卡死
别用 time.AfterFunc 或 time.Sleep 循环——前者易 drift，后者无法响应连接关闭信号。固定节奏驱动才是保活底线。
- 启动
ticker := time.NewTicker(25 * time.Second)（略小于最短 NAT 超时，如 30s 设备留 5s 缓冲） - 每次发包前必须调
conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，超时就关连接 - 心跳内容用固定长度二进制，比如
[]byte{0x01}，避免 JSON、换行符、不定长字段引发代理拦截 - 写失败时检查错误类型：
io.EOF、net.ErrClosed、os.SyscallError（含ETIMEDOUT、ECONNRESET）应立即conn.Close()并退出 goroutine
读超时必须每次 Read 后重置
很多人设一次 SetReadDeadline 就不管了，结果心跳包刚到，deadline 已过期，下一次 Read 直接报 i/o timeout。这不是网络问题，是逻辑漏设。
- 无论读到的是业务数据还是心跳包，只要
n, err := conn.Read(buf)中err == nil，就必须立刻重置：conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 服务端若不响应心跳（只更新 deadline），可省掉
PONG序列，降低开销；但客户端必须等PONG才算本次心跳有效 - 连续两次
Read超时（net.Error.Timeout()）才判定断连，避免单次抖动误杀
gorilla/websocket 的 Ping/Pong 更省心但仍有坑
它原生支持 PingMessage（9）和 PongMessage（10），比自定义协议更可靠，但参数配置不当照样失效。
- 服务端必须设
conn.SetPongHandler（哪怕空实现），否则收到Ping不自动回Pong，客户端会超时 -
pingPeriod建议设为pongWait * 0.9，例如pongWait = 60 * time.Second→pingPeriod = 54 * time.Second - 客户端若用
SetPingHandler自动回Pong，注意不要在 handler 里做阻塞操作（如 DB 查询），否则会拖垮整个连接读循环 - 别依赖
WriteControl成功就认为连接可用——它只写入内核缓冲区，真校验得看下一次Read是否及时返回
最易被忽略的一点：所有定时器（time.Ticker、time.AfterFunc）在连接关闭时必须显式 Stop()，否则 goroutine 泄漏，连接数上去后内存持续增长。这不是理论风险，是线上高频踩坑点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
