服务端需手动注册SetPongHandler并配合SetReadDeadline实现可靠心跳；用time.Ticker每25秒发Ping，WriteControl需设写超时；客户端应额外发JSON心跳包并与服务端ACK交互；Nginx等中间件proxy_read_timeout须大于服务端最大空闲窗口。
服务端怎么发 Ping 并正确响应 Pong
gorilla/websocket 不会自动回 Pong，必须手动注册 SetPongHandler，否则客户端发来的 Ping 会被丢弃，导致连接被误判为失效。同时，仅靠响应 Pong 还不够——你得用 SetReadDeadline 把“最后收到消息时间”和“超时窗口”绑死，不然心跳就形同虚设。
- 每次收到 Pong 后立刻调用
conn.SetReadDeadline(time.Now().Add(60 * time.Second))，重置读超时 - 用
time.Ticker每25 * time.Second主动发一次WriteControl(websocket.PingMessage, nil, ...)，别用WriteMessage——后者不支持控制帧 - 务必在
WriteControl中传入合理的 deadline（比如time.Now().Add(5 * time.Second)），否则写失败时 goroutine 会卡住 - 不要在
SetPongHandler里做耗时操作，它运行在读协程中，阻塞会导致整个连接 hang 住
客户端要不要自己发心跳包
浏览器原生 WebSocket 会自动响应服务端 Ping，但只靠这个不够：它无法探测服务端是否真在线，也缺乏可观测性。所以建议客户端额外发 JSON 心跳包，比如 {"type":"heartbeat"}，和服务端心跳解耦，便于日志追踪和协议扩展。
- 用
setInterval每30 * time.Second调用ws.send(JSON.stringify({type:'heartbeat'})) - 服务端收到后应返回 ACK（如
{"type":"heartbeat_ack"}），而不是只回 Pong；这样客户端才能区分“网络通但服务挂了”和“纯网络断开” - 客户端需维护
lastReceivedAt时间戳，若 60 秒内既没收到业务消息、也没收到 ACK 或 Pong，就触发重连 - 别把心跳逻辑塞进
onmessage回调里做判断——它可能被大量业务消息淹没，应独立计时
为什么 Nginx 一上就掉连接
不是代码问题，是中间件默认超时比你的心跳还短。Nginx 的 proxy_read_timeout 默认 60 秒，而你的服务端 Ping 间隔设成 30 秒、超时设成 45 秒，看似合理，但实际经过 Nginx 后，它会在第 61 秒直接切断连接，且不通知上下游。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须把 Nginx 配置里的
proxy_read_timeout改成至少75s（大于服务端最大空闲窗口） - 加上
proxy_set_header Connection ''，防止 Nginx 复用连接干扰 WebSocket 升级头 - 如果用了负载均衡器（如 AWS ALB），同样要检查其空闲超时设置，常见值是 60~3500 秒不等，不能假设它“默认兼容”
- 上线前务必用
tcpdump抓包验证：确认 Ping 帧真正到达客户端，且 Pong/ACK 确实返回到了服务端
WriteMessage 并发写崩溃怎么办
gorilla/websocket 的 WriteMessage 和 WriteControl 都不是并发安全的。一旦心跳协程、业务写协程、错误关闭协程三者同时调用写方法，大概率触发 panic: write tcp ... use of closed network connection 或更隐蔽的 data race。
立即学习“go语言免费学习笔记（深入）”；
- 最稳方案是只留一个写协程，所有写请求走
chan []byte或chan Message通道 - 心跳协程不直接调用
WriteControl，而是发信号到写通道，由统一写协程处理 - 如果坚持多点写，必须对
*websocket.Conn加互斥锁（sync.Mutex），但要注意锁粒度——别把WriteControl和Close包进同一把锁，否则关连接时会死锁 - 永远在写之前检查
conn.IsClosed()（需自行封装或用conn.WriteMessage返回的 error 判断），别依赖 defer 或外部状态标记
心跳机制本身不难写，难的是它暴露的是整个链路的脆弱性：Nginx 配置、负载均衡策略、客户端休眠行为、甚至 TLS 握手重试都会干扰它。别只盯着 Go 代码，上线前一定要在真实部署拓扑里跑满 2 小时压力测试，看连接是否真能扛过三次心跳周期。
