仅设SetKeepAlive(true)不够用，因其仅触发内核级TCP探测（默认2小时才发首包）、易被NAT/防火墙丢弃、无法验证应用层存活；必须配合time.Ticker定时发轻量心跳包，并严格设置读写deadline实现可控、可验证、快速失败的保活机制。
只设 SetKeepAlive(true) 无法真正保活，必须配合应用层心跳包 + 读写 deadline 控制，否则连接会在 NAT/防火墙空闲超时（常见 30–300 秒）后悄无声息断开。
为什么 SetKeepAlive 不够用
TCP 层的 SetKeepAlive 仅触发内核级探测，默认首次探测要等 2 小时（Linux），且中间设备（如家用路由器、云厂商 SLB）普遍会丢弃或忽略这些底层包。你看到 Write 成功，不代表数据发到了对端——可能卡在 NAT 表里，对方早已关闭连接。
-
SetKeepAlivePeriod(30 * time.Second)在 Go 1.19+ 才支持，旧版需 syscall 设置，且最小生效值受 OS 限制（Linux 通常 ≥ 1s，实际四舍五入到秒） - 它不验证应用层存活：对端进程崩溃但 TCP 连接未关闭时，
KeepAlive仍认为“正常” - 无法感知静默丢包：NAT 超时后丢弃后续所有包，
KeepAlive探测包根本发不出去
用 time.Ticker 发心跳比 time.AfterFunc 更可靠
time.AfterFunc 每次递归调用容易 drift：上一次 Write 阻塞 3 秒，下一次就晚于预期；而 time.Ticker 是固定节奏驱动，适合强周期性任务。
- 正确写法：
ticker := time.NewTicker(20 * time.Second)，然后for range ticker.C中发包 - 错误写法：
time.AfterFunc(20*time.Second, sendPing)，并在sendPing末尾再调一次 —— 容易漏发或堆积 - 务必在连接关闭时显式调用
ticker.Stop()，否则 goroutine 泄漏
心跳必须带响应验证 + 双向 deadline
只发不收等于没做：发完 PING 后不读 PONG，就无法区分是网络抖动还是真断连。真正失效往往先体现在 Read 返回 io.EOF 或超时。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 客户端发
PING前设conn.SetWriteDeadline(time.Now().Add(5 * time.Second)) - 发完立刻
conn.SetReadDeadline(time.Now().Add(25 * time.Second))，然后Read等PONG - 服务端收到
PING后必须立即回PONG，并重置该连接的ReadDeadline - 每次成功
Read（无论业务包还是心跳）后，都得重设ReadDeadline，否则下次读直接超时
心跳包内容越轻越好，别碰 JSON 或变长字段
见过用 json.Marshal(map[string]string{"type":"ping","ts":time.Now().String()}) 的案例：时间字符串含空格、冒号、毫秒位数不定，被中间代理识别为非法协议直接断连。
- 推荐固定长度短包，例如
[]byte{0x01}或[]byte("P") - 避免换行符、空格、非 ASCII 字符，减少协议歧义和解析开销
- 服务端处理心跳逻辑必须嵌入主读循环，不能单独起 goroutine —— 否则心跳解析慢会阻塞整个连接的业务读取
- 心跳间隔务必小于最短 NAT 超时（建议 ≤ 25 秒），留出至少 5 秒缓冲
最容易被忽略的是 deadline 的重设时机：不是“设一次管全程”，而是每次 Read 或 Write 成功后都要立刻更新。漏掉一次，连接就可能在下个业务包到来前被误判为超时断开。
