net/http 默认不关闭空闲 WebSocket 连接，因其仅管理 HTTP 生命周期，升级后连接脱离控制；需在每次 ReadMessage 前调用 SetReadDeadline 配合客户端心跳，并捕获 net.ErrDeadlineExceeded 后主动关闭连接。
为什么 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，而是在每次读操作前动态更新：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// 每次读前重置 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))。这看似省事，实则危险：
- 若某连接网络极差，
WriteControl可能阻塞数秒甚至更久，拖慢整个 ticker 周期，导致其他连接的 ping 延迟累积 - 并发写不同连接时，若未加锁或使用 channel 控制，可能触发
websocket: write closedpanic - 无法区分是“客户端真掉线”还是“只是这次 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、业务状态（如用户房间、订阅列表）三者生命周期不同步。只要有一处没解耦干净，就会出现“连接已关但房间计数没减”这类隐性泄漏。
