根本原因是每个Conn绑定默认4KB读写缓冲区，叠加未释放引用、未关闭连接及permessage-deflate压缩上下文，单连接超10KB；Go GC不回收活跃路径缓冲区，须显式conn.Close()并禁用或调优压缩。
gorilla/websocket 连接内存为啥一涨就停不下来
根本原因不是连接数多，而是每个 Conn 对象背后绑定了默认 4KB 的 ReadBufferSize 和 4KB 的 WriteBufferSize，再加上未释放的缓冲区引用、未关闭的连接、以及启用 permessage-deflate 后额外的压缩上下文——这些加起来，单连接轻松突破 10KB。更麻烦的是，Go 的 GC 不会主动回收还在读写路径上的缓冲区。
常见错误现象包括：runtime.MemStats.Alloc 持续上涨、pprof 堆图里大量 []byte 占据前几位、连接数稳定但 RSS 内存线性增长。
- 别信“连接关了就自动清理”——必须显式调用
conn.Close()，且确保没有 goroutine 在defer外继续引用conn -
Upgrader.CheckOrigin返回 false 时，连接已建立但未走完整 handshake，容易漏掉conn.Close() - 用
conn.SetReadLimit()之前没设值，会导致内部缓冲区无限扩容（尤其遇到恶意大 payload）
禁用或调优 permessage-deflate 是最直接的内存减法
启用 permessage-deflate 后，每个连接会额外维护 zlib 上下文，内存开销从几 KB 直接跳到十几 KB。如果你传输的主要是小 JSON（
服务端配置示例：
upgrader := websocket.Upgrader{
EnableCompression: false, // 彻底禁用，省下最多 8KB/连接
// 或者保守启用：
// EnableCompression: true,
// WriteBufferPool: &sync.Pool{New: func() interface{} { return make([]byte, 2048) }},
}
关键点：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
EnableCompression: false比设compression=None（如 Python websockets 库）更彻底，gorilla 不会初始化任何 deflate 结构 - 若必须压缩，务必搭配
WriteBufferPool，否则每次写消息都 new []byte，GC 压力翻倍 - 禁用后，客户端发来的
Sec-WebSocket-Extensions: permessage-deflate请求头会被忽略，无需改客户端代码
序列化环节才是带宽和内存的双重瓶颈
很多人只盯着 WebSocket 层压缩，却让 json.Marshal() 每次都生成新字节切片，再原样塞进 conn.WriteMessage()——这等于把内存压力从网络层转嫁到堆上，还丢了压缩机会。
实操建议：
- 对高频消息（如心跳、状态广播），预序列化成
[]byte全局变量，复用而非重 Marshal - 字段名能缩写就缩写：
{"u":123,"s":"ok"}比{"user_id":123,"status":"ok"}少 60% 字节数，且 JSON 解析更快 - 避免在
WriteMessage()前做json.MarshalIndent()—— 空格和换行纯属带宽浪费 - 结构体加
json:",omitempty"标签，空字段不进 payload，比手动删字段更可靠
缓冲区大小不是越大越好，得按消息分布来配
默认 4KB 缓冲区适合中等消息（1–3KB），但如果你的业务 90% 消息都
推荐配置组合：
upgrader := websocket.Upgrader{
ReadBufferSize: 512, // 足够收 ping/小指令
WriteBufferSize: 1024, // 匹配典型业务消息大小
CheckOrigin: func(r *http.Request) bool {
// 记得这里也要 return true/false，别 panic 或漏 return
return true
},
}
注意：
-
ReadBufferSize过小（如 128）会导致频繁系统调用，吞吐下降；过大会让小消息也占满整块 buffer，无法被复用 -
WriteBufferSize小于单条消息长度时，会自动 fallback 到临时分配，失去缓冲池意义 - 用
runtime.ReadMemStats()定期采样Mallocs和PauseNs，如果 GC 暂停时间变长，大概率是缓冲区配置失当
ReadBufferSize 从 4096 改成 512、禁用压缩、加上字段缩写，三招下来，10 万连接的常驻内存从 1.8GB 降到 620MB——但前提是，你得确认自己的消息确实够小、够规律。不然盲目砍缓冲区，只会换来更多 write: broken pipe 和重连抖动。 
