gorilla/websocket的Ping/Pong必须手动启用：服务端需设SetPongHandler重置读超时并启动独立goroutine每25秒调用WriteControl发Ping，且读写超时须严格小于Nginx等中间设备空闲超时。
gorilla/websocket 的 Ping/Pong 必须手动启用
默认情况下，gorilla/websocket 不会自动发送 PingMessage，也不会自动响应 PongMessage —— 它只提供注册处理器的能力，不主动触发心跳。如果你没显式调用 SetPingHandler 或启动定时 WriteControl，连接在 Nginx、ALB 或防火墙空闲超时后就会被静默断开。
服务端保活的关键是「双向驱动」：既要接收客户端 Pong（靠 SetPongHandler），也要定期发 Ping（靠独立 goroutine + conn.WriteControl）。漏掉任意一端，都可能造成单向失联。
-
SetPongHandler应该做两件事：重置读超时（conn.SetReadDeadline），并清空应用层心跳计时器（比如更新c.HeartbeatTime） - 发送 Ping 的 goroutine 必须绑定连接生命周期，不能全局复用；否则某个连接关闭后，还在往已失效的
*websocket.Conn写控制帧，会 panic -
pingPeriod建议设为pongWait * 0.9，确保 Ping 总是在对端Pong超时窗口内到达，避免误判为失联
读超时和写超时必须分开设置且严格小于中间设备超时
常见错误是把 ReadDeadline 和 WriteDeadline 都设成同一个值（比如 60 秒），或直接忽略写超时。这会导致两个问题：一是连接卡在 conn.ReadMessage 时无法及时感知断连；二是 conn.WriteMessage 在网络拥塞或对端崩溃时无限阻塞，拖垮整个 goroutine。
更危险的是，这个超时值必须比你所经路径上所有中间设备的空闲超时更短。例如 Nginx 默认 proxy_read_timeout 60s，那你的 pongWait 就得 ≤ 55s，否则 Nginx 先断，而你的服务还傻等 Pong。
立即学习“go语言免费学习笔记（深入）”；
-
pongWait = 55 * time.Second（适配常见反向代理） -
writeWait = 10 * time.Second（防止 write 卡死，失败后应 close 连接） -
conn.SetReadDeadline(time.Now().Add(pongWait))必须在每次ReadMessage前重置，不是只设一次
连接异常关闭时，goroutine 泄漏比内存泄漏更致命
每个 WebSocket 连接通常对应至少两个 goroutine：reader 和 writer。如果连接因网络闪断、客户端强制 kill 进程等原因关闭，而你的清理逻辑没覆盖到 io.EOF、websocket.CloseAbnormalClosure 或 net.OpError，这两个 goroutine 就会永远卡在 ReadMessage 或 select 上，状态显示为 [IO wait]，但实际已不可回收。
这不是“等待 IO”，而是“死等一个永远不会来的字节”。几百个连接就可能拖慢调度器，几千个就可能让 runtime.GOMAXPROCS 失效。
- 所有
ReadMessage调用必须包裹在for循环里，并检查返回 error 是否为websocket.IsCloseError或errors.Is(err, io.EOF) -
writergoroutine 必须监听连接关闭信号（比如通过done chan struct{}），不能只依赖send chan关闭 - 建议在
defer conn.Close()前显式调用conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseGoingAway, ""))，确保对端收到标准关闭帧
聚合读取场景下，别用 channel 直接转发原始 []byte
当你要把数百个 WebSocket 连接的消息统一汇入一个 chan []byte 供下游消费时，直接转发原始字节切片看似简单，实则埋雷：不同连接的 message 可能指向同一底层数组（gorilla/websocket 内部缓冲区复用），一旦某个连接 goroutine 继续读、覆盖了旧数据，下游拿到的就是脏内容。
这个问题在高并发聚合场景下极难复现，但一旦发生，消息错乱、JSON 解析失败、甚至 panic 都可能出现。
- 必须做深拷贝：
data := make([]byte, len(message)); copy(data, message) - 更稳妥的做法是立刻解码为结构体（如
json.Unmarshal），再转成带来源标识的事件对象，避免后续处理再碰原始字节 - 如果坚持用字节流，建议配合
sync.Pool管理临时[]byte缓冲区，而不是每次都make
真正难的不是写心跳，而是让心跳在连接生命周期的每个退出点都被正确终止；不是开 goroutine，而是确保它在连接关闭那一刻必然结束。保活逻辑的健壮性，藏在所有 error 分支和 defer 里，不在主流程中。
