Gorilla WebSocket 连接在约 120 秒后静默断开，通常并非由服务端 TTL 或心跳超时直接导致，而是因主 goroutine 意外阻塞或退出，致使程序提前终止——最典型的陷阱是 main 函数末尾使用无限空循环 for { continue }，掩盖了实际的 panic、goroutine 泄漏或连接管理缺陷。

gorilla websocket 连接在约 120 秒后静默断开，通常并非由服务端 ttl 或心跳超时直接导致，而是因主 goroutine 意外阻塞或退出，致使程序提前终止——最典型的陷阱是 `main` 函数末尾使用无限空循环 `for { continue }`，掩盖了实际的 panic、goroutine 泄漏或连接管理缺陷。

在您提供的代码中，main() 函数末尾的 for { continue } 看似用于“保持程序运行”，实则隐藏了关键问题：它使 main goroutine 占用全部控制权，却未处理任何错误信号、未响应 OS 信号（如 SIGINT），更无法优雅关闭连接。一旦 ReadLoop 或 Process 中发生不可恢复错误（例如网络闪断、JSON 解析失败、channel 阻塞），程序既不崩溃也不退出，而是陷入“假活”状态——表面仍在运行，但 readChannel 无消费者响应、ping/pong 逻辑失效，最终因服务端心跳超时（如 CEX.IO 的默认 120s 无消息断连策略）主动关闭连接。

更严重的是，原始代码中存在多个潜在风险点：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• ❌ SendPong() 实现错误：先调用 WriteJSON("pong")，又重复调用 WriteControl(websocket.PongMessage, ...)。根据 WebSocket 协议，Pong 是控制帧，应由底层自动响应 Ping；手动发送 Pong 消息 + 控制帧易引发协议冲突或服务端拒绝。
• ❌ ReadLoop 缺乏读取超时与重连机制：c.conn.ReadMessage() 默认无超时，若网络卡顿或服务端异常，goroutine 将永久阻塞，ch 通道持续满载而无人消费，导致后续 ReadLoop 迭代无法启动。
• ❌ main 中未捕获 goroutine panic：ReadLoop 或 Process 若 panic，将静默终止，main 却仍在空转，难以定位故障。

✅ 正确做法是：移除 for { continue }，改用受控的主循环 + 信号监听 + 错误传播机制。以下是推荐重构方案：

SendPing()