Go长连接需自实现应用层Ping-Pong保活，核心是“自适应”心跳：依据连接状态（healthy/unstable/dead）动态调整间隔，用单ticker+状态机驱动；每次Read前必须重设SetReadDeadline；心跳包须为无歧义固定字节序列。
Go 长连接不能靠 SetKeepAlive 自动保活，必须自己实现应用层 Ping-Pong；所谓“自适应”，不是指自动调参，而是根据连接真实响应行为动态调整心跳节奏——比如连续超时就降频，稳定则维持或微升，避免无差别高频探测加重网络和对端负担。
为什么固定间隔心跳在生产中会失效
硬编码 20 秒发一次 "ping" 看似简单，但实际会踩三个坑：
- 网络抖动时连续几轮
Write或Read超时，却仍按原节奏重试，加剧丢包和队列积压 - 客户端休眠或弱网（如地铁隧道）下，服务端持续发 ping，对方无法响应，连接资源卡死不释放
- 高并发场景下，所有连接统一用同一间隔，容易在整点/半点形成流量尖峰，触发防火墙限速或 NAT 表项刷新失败
真正需要的不是“更频繁”，而是“更聪明”：连接健康就少扰动，异常初现就收敛节奏，确认死亡就快速清理。
用 time.Ticker + 状态机实现可退避的心跳驱动
别用 time.AfterFunc 嵌套启新定时器，它无法控制节奏漂移。正确做法是用单个 time.Ticker 驱动状态机，每次 tick 根据当前连接状态决定动作：
- 状态
healthy：正常发"ping"，成功收到"pong"后保持当前间隔（如 30s） - 状态
unstable（连续 2 次超时或io.EOF）：将心跳间隔翻倍（如 60s），并重置计数器 - 状态
dead（累计超时 ≥ 3 次，或write: broken pipe）：停止 ticker，触发onDead回调，由上层关闭连接
关键代码片段（非完整）：
type heartbeatState int
const (
healthy heartbeatState = iota
unstable
dead
)
<p>func (h *Heartbeat) run() {
ticker := time.NewTicker(h.interval)
defer ticker.Stop()</p><pre class='brush:php;toolbar:false;'>for {
select {
case <-h.ctx.Done():
return
case <-ticker.C:
switch h.state {
case healthy:
h.sendPing()
if !h.waitPong(10 * time.Second) {
h.state = unstable
h.interval *= 2
ticker.Reset(h.interval)
}
case unstable:
// 继续以加长间隔探测，不降级也不升级
case dead:
h.onDead()
return
}
}
}}
SetReadDeadline 必须每次读前重设，且不能只设一次
很多人设一次 conn.SetReadDeadline(time.Now().Add(45 * time.Second)) 就以为万事大吉，结果连接卡在 Read 上十几分钟才超时。原因在于：
-
SetReadDeadline是绝对时间戳，不是相对偏移量；一旦超时或读到数据，该 deadline 就失效 - 心跳逻辑里，你既可能读业务数据，也可能读
"pong"，每次Read前都得重设 deadline，否则后续读操作永远不超时 - 不要在
SetPongHandler里重设 —— 它只在收到 Pong 时触发，而你还要读业务帧；应在每次Read调用前显式设置
典型错误写法：conn.SetReadDeadline(time.Now().Add(45 * time.Second)) 放在协程开头；正确写法是：
buf := make([]byte, 4)
conn.SetReadDeadline(time.Now().Add(10 * time.Second))
n, err := conn.Read(buf[:])
if err != nil {
// 处理超时、EOF、net.OpError 等
}
// 下次 Read 前还得再 SetReadDeadline心跳包内容必须无歧义、无解析依赖
别用 JSON、带空格的字符串、或含时间戳的动态内容发心跳。曾有服务因发 {"type":"ping","ts":"2026-05-23T23:30:00Z"} 被企业防火墙识别为“非法协议”直接 RST。真正可靠的心跳只有两种：
- 固定字节序列：
[]byte{0x01}或[]byte("ping")（4 字节，无换行） - 长度+内容二进制帧：
[1]byte + [4]byte "ping"，先读 1 字节判断类型，再按需读后续
服务端收到后，若匹配 "ping"，立即回 "pong"（同样 4 字节），不做任何额外处理——包括不记录日志、不查 DB、不走中间件。延迟哪怕多 1ms，都可能让心跳误判成超时。
最易被忽略的一点：自适应不是靠算法多 fancy，而是靠每个连接独立维护状态、独立管理 ticker、独立重设 deadline。共享 ticker 或共用一个 lastPong 时间戳，在高并发下必然出现竞争和误判。
