Gorilla WebSocket 在无阻塞主 goroutine 时会因程序提前退出导致连接在约 120 秒后静默中断；根本原因是 main() 函数末尾的无限空循环 for { continue } 无法正确维持程序生命周期，应替换为更健壮的同步机制。
gorilla websocket 在无阻塞主 goroutine 时会因程序提前退出导致连接在约 120 秒后静默中断；根本原因是 `main()` 函数末尾的无限空循环 `for { continue }` 无法正确维持程序生命周期，应替换为更健壮的同步机制。
在使用 Gorilla WebSocket 与 CEX.IO 等交易所建立长连接时，开发者常遇到「连接稳定运行约 120 秒后突然停止接收消息」的问题。该现象并非由服务端 TTL（Time-To-Live）或心跳超时直接引发，而是一个典型的 Go 程序生命周期管理疏漏：main() 函数执行完毕后，整个进程优雅退出，所有子 goroutine（包括 ReadLoop 和 Processor.Process）被强制终止——即使它们仍在后台运行，Go 运行时也不会等待。
原始代码中这一问题的根源在于：
// ❌ 危险写法：看似“保持运行”，实则不可靠且易被编译器优化
for {
continue
}该空循环虽占用 CPU，但既不响应信号，也不参与任何同步协调，更重要的是：它无法阻止 main goroutine 的“完成”状态被运行时判定为程序就绪退出。尤其在某些 Go 版本或调度环境下，此循环可能被优化或因调度延迟导致主线程提前结束。
✅ 正确做法是使用标准同步原语，让 main() 主动等待关键 goroutine 完成，或监听系统信号实现优雅退出。推荐采用以下任一方式：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
✅ 方案一：使用 sync.WaitGroup（推荐用于守护型服务）
import "sync"
func main() {
var wg sync.WaitGroup
cexioConn := new(cexio.Connection)
// ... Connect & Authenticate ...
readChannel := make(chan cexio.IntraAppMessage, 25)
wg.Add(1)
go func() {
defer wg.Done()
cexioConn.ReadLoop(readChannel)
}()
processor := Processor{
WatchPairs: [][2]string{{"BTC", "USD"}},
conn: cexioConn,
}
wg.Add(1)
go func() {
defer wg.Done()
processor.Process(readChannel)
}()
// ✅ 主 goroutine 阻塞等待，确保程序持续运行
wg.Wait() // 等待所有工作 goroutine 结束（实际中通常永不返回）
}⚠️ 注意：
wg.Wait()将永久阻塞，适用于后台服务。如需支持热重启或信号退出，应结合os.Signal使用。
✅ 方案二：监听 OS 信号（生产环境首选）
import (
"os"
"os/signal"
"syscall"
)
func main() {
// ... 初始化连接、启动 goroutines ...
// ✅ 等待中断信号（如 Ctrl+C）
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
fmt.Println("Service started. Press Ctrl+C to exit.")
<-sigChan // 阻塞直到收到信号
fmt.Println("Shutting down...")
cexioConn.Disconnect() // 主动关闭连接
}? 补充建议：增强 WebSocket 心跳鲁棒性
虽然主 goroutine 问题是根本原因，但完善心跳逻辑可进一步提升稳定性：
-
避免重复发送 Ping/Pong：当前
SendPing()同时发业务消息（get-balance）和控制帧（PingMessage），不符合规范。应仅用WriteControl(websocket.PingMessage, ...)发送标准 Ping，并在SetPingHandler中自动回 Pong：c.conn.SetPingHandler(func(appData string) error { return c.conn.WriteControl(websocket.PongMessage, []byte(appData), time.Now().Add(10*time.Second)) }) -
设置读/写超时：在
Dialer中配置超时，防止卡死：dialer := websocket.Dialer{ HandshakeTimeout: 10 * time.Second, KeepAlive: 30 * time.Second, Proxy: http.ProxyFromEnvironment, }
✅ 总结
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| WebSocket 在 ~120s 后停止收包 |
main() 提前退出 → 进程终止 → 所有 goroutine 被杀 |
移除 for { continue }，改用 sync.WaitGroup 或 signal.Notify 阻塞主 goroutine |
ReadLoop 无声挂起 |
连接已关闭但 channel 未关闭， 永久阻塞
|
在 Disconnect() 后显式关闭 readChannel（需加锁保护）或使用带缓冲 channel + select 超时 |
遵循以上实践，即可彻底解决 Gorilla WebSocket “120秒断连”问题，构建高可用的实时行情订阅服务。
