Go TCP连接必须自己实现应用层Ping-Pong，仅调用conn.SetKeepAlive(true)不足；需每20–30秒定时发"PING"并等待"PONG"响应，配合time.NewTicker、select超时控制、每次读写前重设Read/WriteDeadline，且中间件proxy_read_timeout须大于心跳间隔×1.5。

Go TCP 连接必须自己实现应用层 Ping-Pong

仅调用 conn.SetKeepAlive(true) 不足以保活。TCP 层 KeepAlive 是操作系统级探测，触发慢（Linux 默认 2 小时）、不可控、且中间设备（NAT/防火墙）常静默丢弃探测包。真实业务中，连接往往在 5 分钟内就被网关切断，而你毫无感知。

必须在应用层设计 Ping-Pong 交互：客户端定时发 "PING"，服务端收到后立刻回 "PONG"；客户端发完立刻 Read 等待响应，并设读超时。只发不收、或只收不验证，等于没做。

• 心跳内容必须是固定字符串（如 "PING"/"PONG"），禁用 JSON、带时间戳、含空格或换行符——某些代理会直接拒收
• 间隔建议 20–30 秒：太短加重负担，太长无法及时发现断连
• 不要用 time.AfterFunc 链式调用，它易 drift；必须用 time.NewTicker 固定节奏驱动

gorilla/websocket 的 PingMessage 不是“自动心跳”

gorilla/websocket 的 PingMessage 是控制帧，但库不会自动发送，也不会自动响应。你必须手动启动 goroutine 调用 WriteControl，同时服务端必须注册 SetPongHandler，否则客户端发的 Ping 会被静默丢弃，连接很快因超时关闭。

常见错误写法：conn.WriteMessage(websocket.PingMessage, nil) —— 这会失败，因为控制帧只能用 WriteControl 发送。

• 正确发 Ping：conn.WriteControl(websocket.PingMessage, nil, time.Now().Add(5*time.Second))，第三个参数是写超时，必填
• 服务端必须设：conn.SetPongHandler(func(string) error { conn.SetReadDeadline(time.Now().Add(45 * time.Second)); return nil })
• SetPongHandler 内禁止任何阻塞操作（如 DB 查询、HTTP 调用），它运行在读协程中，一卡整个连接就 hang 住

ReadDeadline 和 WriteDeadline 必须每次读写前重设

SetReadDeadline 和 SetWriteDeadline 是绝对时间点，不是持续周期。设一次就不管，超时逻辑立即失效。例如你设了 ReadDeadline = now.Add(45*time.Second)，但之后 10 秒才读到消息，那剩余 35 秒就作废了——下次读之前必须重设。

真正可靠的做法是：每次成功 ReadMessage 或 Read 后，立刻重置 ReadDeadline；每次成功 WriteControl 或 WriteMessage 后，立刻重置 WriteDeadline。

• 推荐值：ReadDeadline ≥ 心跳间隔 × 1.5（如心跳 30s，ReadDeadline 设 45s）；WriteDeadline 可略短（如 30s），避免写阻塞太久
• 别依赖 SetPingHandler 自动重置 ReadDeadline——它只在收到 Pong 时重置，而业务消息也该重置
• 客户端若同时收业务消息和 Pong，需统一用同一个时间戳更新 lastActive，不能只靠 Pong

Nginx / ALB 等中间件会无声截断连接

代码再严谨，过不了 Nginx 就白搭。proxy_read_timeout 默认 60 秒，而你的服务端心跳间隔 30 秒、ReadDeadline 设 45 秒，看似安全，实则 Nginx 在第 61 秒直接断开连接，且不通知上下游。

这不是 Bug，是配置缺失。所有中间件都需显式放宽空闲超时，且必须大于服务端最大允许空闲窗口（即 ReadDeadline 值）。

• Nginx 至少配：proxy_read_timeout 75; + proxy_set_header Connection '';
• AWS ALB 默认空闲超时 60 秒，需在监听器设置里调高（支持 1~3500 秒）
• 如果用了自定义协议（非 WebSocket），还要确认中间件是否支持长连接升级头，否则可能降级为 HTTP/1.1 短连接

真正的难点不在发 Ping，而在如何把“连接还活着”这个事实，从 TCP 层、中间件层、应用层三者之间对齐。漏掉任意一层，心跳就形同虚设。