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 无消息断连策略）主动关闭连接。
更严重的是，原始代码中存在多个潜在风险点：
- ❌
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 }，改用受控的主循环 + 信号监听 + 错误传播机制。以下是推荐重构方案：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
func main() {
cexioConn := new(cexio.Connection)
// ... Connect & Authenticate (保持原有逻辑)
readChannel := make(chan cexio.IntraAppMessage, 25)
go cexioConn.ReadLoop(readChannel)
processor := Processor{
WatchPairs: [][2]string{{"BTC", "USD"}},
conn: cexioConn,
}
go processor.Process(readChannel)
// ✅ 替换 for { continue }：监听 OS 信号，优雅退出
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
select {
case <-sigChan:
fmt.Println("Received shutdown signal")
cexioConn.Disconnect()
return
}
}同时，务必修正 SendPing() 和 SendPong()：
// ✅ 正确的心跳实现：仅需发送 Ping 控制帧，并设置 ReadDeadline
func (c *Connection) SendPing() error {
// 发送标准 Ping 控制帧（非业务消息）
err := c.conn.WriteControl(websocket.PingMessage, nil, time.Now().Add(15*time.Second))
if err != nil {
return fmt.Errorf("failed to send ping: %w", err)
}
return nil
}
// ✅ 移除 SendPong() —— Gorilla 自动处理 Pong 响应
// 若需自定义 Ping 处理，可设置：
// c.conn.SetPingHandler(func(appData string) error {
// return c.conn.WriteControl(websocket.PongMessage, []byte(appData), time.Now().Add(15*time.Second))
// })此外，增强 ReadLoop 的健壮性：
func (c *Connection) ReadLoop(ch chan<- IntraAppMessage) {
// ✅ 设置读取超时，避免永久阻塞
c.conn.SetReadDeadline(time.Now().Add(30 * time.Second))
for {
_, msgBytes, err := c.conn.ReadMessage()
if err != nil {
if websocket.IsUnexpectedCloseError(err, "") {
ch <- IntraAppMessage{ProgramMessage: ProgramMessage{Error: "websocket closed unexpectedly"}}
} else {
ch <- IntraAppMessage{ProgramMessage: ProgramMessage{Error: err.Error()}}
}
return // 退出 goroutine，由上层决定是否重连
}
var m GenericMessage
if err = json.Unmarshal(msgBytes, &m); err != nil {
ch <- IntraAppMessage{ProgramMessage: ProgramMessage{Error: "json parse failed: " + err.Error()}}
continue
}
ch <- IntraAppMessage{SocketMessage: m}
// ✅ 重置读取超时
c.conn.SetReadDeadline(time.Now().Add(30 * time.Second))
}
}总结：120 秒断连表象下，根本原因常是程序结构缺陷而非网络配置。务必避免 for { continue } 这类反模式；优先使用信号监听 + 显式生命周期管理；严格区分业务消息与 WebSocket 控制帧；为所有 I/O 操作设置超时；并通过 channel 错误传递实现 goroutine 间故障感知。如此，才能构建稳定、可观测、可维护的 WebSocket 客户端。
