gorilla/websocket 的 setpinghandler 不能直接当心跳用，因为它仅被动响应 ping 帧，不主动发送 ping，也不检测对方超时；真正的心跳需客户端和服务端双向定时收发 ping/pong 并检测延迟或缺失。
为什么 gorilla/websocket 的 SetPingHandler 不能直接当心跳用
它只是响应 Ping 帧，不主动发 Ping，也不检查对方是否超时。真正的心跳必须包含「客户端定时发 Ping」「服务端定时发 Ping」「双方都检测对方响应延迟或缺失」三个动作。
常见错误是只设了 SetPingHandler 就以为连接保活了，结果网络抖动时连接静默断开，业务无感知。
-
SetPingHandler是被动回调，只处理收到的 Ping；要发 Ping 得自己启 goroutine 调用WriteMessage(websocket.PingMessage, nil) - 必须配合
SetReadDeadline和SetWriteDeadline，否则阻塞读写会卡住心跳逻辑 - 超时时间要略大于心跳间隔（比如心跳 10s，Deadline 设 15s），避免误判
如何用 gorilla/websocket 实现双向心跳（含超时断连）
核心是读写协程分离 + 共享状态控制。服务端需同时管理「读超时」「写超时」「最后收到消息时间」三个状态。
典型结构：一个 goroutine 负责读（含 Ping 响应和业务消息），一个 goroutine 定时发 Ping，用 atomic 或 mutex 更新 lastPong 时间戳。
- 读循环里调用
conn.SetReadDeadline(time.Now().Add(pongWait))，并在收到 Pong 后更新lastPong - 写循环每
pingPeriod调用一次conn.WriteMessage(websocket.PingMessage, nil)，失败则关闭连接 - 另起 goroutine 每秒检查
time.Since(lastPong) > pongWait，超时就conn.Close()
// 示例片段：心跳检查 goroutine
go func() {
ticker := time.NewTicker(pingPeriod)
defer ticker.Stop()
for {
select {
case pongWait {
conn.Close()
return
}
conn.WriteMessage(websocket.PingMessage, nil)
}
}
}()
框架集成时容易忽略的 Deadline 冲突问题
很多 Web 框架（如 Gin、Echo）默认对整个 HTTP 连接设了 ReadTimeout/WriteTimeout，但 WebSocket 升级后这些配置仍可能干扰底层 conn 的 deadline 控制，导致心跳被框架层提前中断。
- Gin 中务必在升级前调用
c.Writer.WriteHeaderNow()并禁用中间件（尤其是 recovery 和 logger） - Echo 需用
c.Response().Upgrade()替代普通 write，并确保没有全局 timeout middleware 生效 - 所有
SetReadDeadline/SetWriteDeadline必须在 upgrade 完成后立即设置，且每次读写前都要重置
心跳间隔设多少才合理
不是越短越好。太短（30s）会导致断连发现延迟高，影响实时业务。
- 内网环境推荐
pingPeriod = 15s，pongWait = 25s - 公网弱网建议
pingPeriod = 20s，pongWait = 40s，并允许客户端自报能力（如通过 query 参数传heartbeat=30） - 注意 NAT 超时通常为 30–60s，心跳间隔必须小于该值，否则中间设备主动踢掉连接
实际部署时，最好把心跳参数做成可配置项，而不是硬编码——不同地区、不同终端类型（移动端 vs PC）的网络表现差异很大，统一值反而容易出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
