如何在 Golang 框架中管理大量的 WebSocket 僵尸连接并自动清理-Golang-PHP中文网

net/http 默认不关闭空闲 websocket 连接，因其仅管理 http 生命周期，升级后连接脱离控制；需在每次 readmessage 前调用 setreaddeadline 配合客户端心跳，并捕获 net.errdeadlineexceeded 后主动关闭连接。

如何在 golang 框架中管理大量的 websocket 僵尸连接并自动清理

为什么 `net/http` 默认不关闭空闲 WebSocket 连接

Go 标准库的 http.Serve 不感知 WebSocket 协议语义，它只管 TCP 连接生命周期。一旦升级为 WebSocket（比如用 gorilla/websocket 调用 Upgrader.Upgrade），后续读写完全脱离 HTTP Server 控制——连接不会因超时自动断开，也不会被 http.Server.ReadTimeout 或 WriteTimeout 影响。

这意味着：客户端断网、杀进程、切后台却不发 close 帧时，服务端 socket 会持续处于 ESTABLISHED 状态，conn.ReadMessage 阻塞等待，内存和文件描述符缓慢堆积。

典型表现是 lsof -i :8080 | wc -l 持续上涨，但活跃消息量几乎为零
netstat -an | grep :8080 | grep ESTABLISHED | wc -l 和监控中“在线用户数”严重不符
用 pprof 查看 goroutine，大量卡在 websocket.(*Conn).ReadMessage 或 net.Conn.Read

用 `SetReadDeadline` + 心跳检测主动驱逐僵尸连接

核心思路不是等系统回收，而是让每个连接自己“汇报健康状态”。必须在每次 ReadMessage 前设置读截止时间，并配合客户端定时 ping（或服务端定期 write ping）。

以 gorilla/websocket 为例，关键不在连接建立时设一次 deadline，而是在每次读操作前动态更新：

// 每次读前重置 30 秒读超时
err := conn.SetReadDeadline(time.Now().Add(30 * time.Second))
if err != nil {
    return err
}
_, _, err = conn.ReadMessage() // 若 30 秒内无数据，这里返回 net.ErrDeadlineExceeded

客户端必须每 ≤25 秒发一次 ping 帧（或任意文本/二进制帧），否则服务端下次 ReadMessage 就会超时
不要依赖 SetPingHandler 自动回 pong——它不重置读 deadline，仅处理 ping 逻辑
务必在 for 循环里每次读前都调用 SetReadDeadline，不能只在循环外设一次
捕获 net.ErrDeadlineExceeded 后应立即 conn.Close()，并从管理 map 中删除该连接

避免用全局 ticker 触发所有连接的 `WriteControl` ping

有人想“统一心跳”，启一个全局 goroutine 每 25 秒遍历所有连接调 conn.WriteControl(websocket.PingMessage, nil, time.Now().Add(10*time.Second))。这看似省事，实则危险：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

若某连接网络极差，WriteControl 可能阻塞数秒甚至更久，拖慢整个 ticker 周期，导致其他连接的 ping 延迟累积
并发写不同连接时，若未加锁或使用 channel 控制，可能触发 websocket: write closed panic
无法区分是“客户端真掉线”还是“只是这次 ping 慢了”，容易误踢活跃用户

更稳妥的做法是：只由客户端保活，服务端专注读超时；若必须服务端发起 ping（如兼容弱网络客户端），应为每个连接启动独立 goroutine + time.AfterFunc，且写操作加 conn.WriteMutex.Lock()（gorilla/websocket 内置写锁）。

清理残留 goroutine 和连接状态的最后防线

即使有读超时，仍可能漏掉某些 case：比如连接刚升级完就断网，ReadMessage 还没执行第一次，deadline 就没机会设置；或者 panic 导致 defer 关闭失效。

建议加一层兜底：

给每个连接关联一个 sync.WaitGroup 或 context.WithCancel，在 defer 中显式关闭底层 net.Conn 并通知管理器
用 runtime.SetFinalizer 注册连接对象的终结函数（慎用：不保证及时执行，仅作最后保险）
定期（如每分钟）扫描连接 map，对 lastActivity 时间 > 60 秒且当前无读写 goroutine 的连接，强制 conn.Close()

真正难处理的不是超时逻辑本身，而是连接对象、goroutine、业务状态（如用户房间、订阅列表）三者生命周期不同步。只要有一处没解耦干净，就会出现“连接已关但房间计数没减”这类隐性泄漏。