SetPingHandler不能直接保活，因为它仅被动响应Ping帧、不主动发Ping、也不检测超时；真正的心跳需客户端和服务端双向定时收发Ping/Pong并检测延迟或缺失，否则Nginx或防火墙空闲超时后连接会静默断开。
gorilla/websocket 的 SetPingHandler 不能当心跳用，必须手动发 PingMessage + 双向超时检测，否则连接会在 Nginx 或防火墙空闲超时后静默断开。
为什么 SetPingHandler 不能直接保活
SetPingHandler 只是注册一个回调函数，用来响应客户端发来的 Ping 帧并自动回 Pong；它不主动发送 Ping，也不检查对方是否超时。常见错误是设了这个 handler 就以为连接稳了，结果网络抖动时连接已断，服务端还一直等不到 Pong，业务完全无感知。
真正的心跳必须包含三个动作：WriteMessage(websocket.PingMessage, nil) 主动发、SetPongHandler 被动收、time.Since(lastPong) > pongWait 主动判超时。
- 漏掉
WriteMessage：服务端不发 Ping，中间设备（如 Nginx 默认proxy_read_timeout 60s）会先断连 - 漏掉
SetPongHandler：客户端发的 Ping 没人响应，Pong 不会自动触发SetReadDeadline更新 - 漏掉超时检查：仅发 Ping 不检测响应，等于没心跳
如何在 Gin 中正确启用双向心跳
Gin 本身不处理 WebSocket，所有逻辑都落在 gorilla/websocket 的 *websocket.Conn 上。升级完成后，必须立刻分离读写 goroutine，并为每个连接维护独立心跳状态。
立即学习“go语言免费学习笔记（深入）”；
- 读 goroutine 中调用
conn.SetReadDeadline(time.Now().Add(pongWait))，并在每次收到消息（含websocket.PongMessage）后更新lastPong时间戳 - 写 goroutine 每
pingPeriod（建议设为pongWait * 0.9）调用conn.WriteMessage(websocket.PingMessage, nil)；失败立即conn.Close() - 另起一个 goroutine 每秒检查
time.Since(lastPong) > pongWait，超时则主动关闭连接 -
pongWait必须严格小于路径上所有中间设备超时（如 Nginx 设为 55s，不能等于 60s）
容易被忽略的 Deadline 冲突和 goroutine 泄漏
读写超时必须分开设置，且不能只设一次。常见错误是把 SetReadDeadline 放在循环外，或与 SetWriteDeadline 共用同一值——这会导致读卡死在 ReadMessage，或写卡死在 WriteMessage，进而拖垮整个连接生命周期管理。
-
conn.SetReadDeadline必须在每次ReadMessage前重置，不是升级后设一次就完事 -
conn.SetWriteDeadline应设为较短值（如 10s），防止 write 阻塞导致心跳 goroutine 无法退出 - 连接关闭时若未捕获
websocket.CloseAbnormalClosure、io.EOF或net.OpError，reader/writer goroutine 会永远卡在[IO wait]状态，无法回收 - 所有心跳 goroutine 必须绑定连接生命周期，不能全局复用 ticker；否则 conn 关闭后仍往已失效连接写帧，直接 panic
连接池里的心跳状态怎么存才安全
如果用了连接池（比如 map[*Client]bool），lastPong 不能存在全局变量或共享 map 里——高并发下竞态风险极高。正确做法是把时间戳作为字段嵌入 *Client 结构体，并用 atomic.Time 或 mutex 保护更新操作。
- 不要用
time.Now().Unix()存整数再比较，精度不够，且跨核时钟可能漂移 - 避免在
SetPongHandler回调里直接操作连接池 map，它运行在 reader goroutine 上，和注销逻辑可能并发冲突 - 心跳检查 goroutine 应该从连接池中按需取 client，而不是遍历全部连接——百万连接时全量扫描代价太大
- 客户端断连时，务必确保所有相关 goroutine（reader、writer、heartbeat checker）都已退出，再从池中移除 client
最危险的坑不在代码写法，而在部署环境：Nginx、ALB、云防火墙的空闲超时值，永远比你代码里的 pongWait 更早触发。上线前必须确认链路每一环的超时配置，否则心跳再准也没用。
