websocket消息积压是系统吞吐失衡的慢性信号，需拆分读写协程、隔离连接队列、设置分层超时并用非阻塞写入实现可感知背压。

WebSocket消息积压不是突发故障，而是系统吞吐失衡的慢性信号。它往往在连接看似正常时悄然发生——ReadMessage没报错，但业务逻辑已卡住几十秒，缓冲区里堆着上百条未消费消息。

拆开读写协程，别让业务逻辑堵死接收入口

根本问题在于把ReadMessage和数据库写入、HTTP调用等耗时操作塞进同一个goroutine。一旦db.Exec耗时200ms，后续所有消息就卡在TCP接收缓冲区，连接维持着“活着”的假象。

• 启动独立读协程：只做ReadMessage → 校验 → 发送至c.recv（chan []byte）
• 另起处理协程：从c.recv取消息 → 反序列化 → 执行业务 → 失败走重试或死信
• c.recv缓冲长度设为64：小于32易丢心跳包，大于128会掩盖真实瓶颈，混发大二进制帧时内存可能翻倍

发送必须串行，并发write必然panic

gorilla/websocket底层对TCP write做了并发检测，多goroutine同时调WriteMessage会直接panic：“concurrent write to websocket connection”。这不是异常，是设计上的fail-fast保护。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 每个连接配专属msgs chan Message（带缓冲，如64）
• 仅一个writer goroutine阻塞读取该chan，顺序调用conn.WriteMessage
• Message结构建议含Done chan error，用于同步反馈发送结果
• 入队前完成JSON序列化等耗时操作，避免阻塞生产者

背压要可感知，不能靠增大buffer硬扛

channel容量不是救命稻草。设成10000只是把积压从内存转移到队列里，监控失效、OOM风险更高。关键是要让发送端知道“慢了”。

• 写入c.send时永远用select+default非阻塞保护，满则主动断连或降级
• Node.js中用getBufferedAmount()轮询（每100ms），连续3次≥80%阈值才限流
• uWebSockets.js推荐maxBackpressure: 1MB + closeOnBackpressureLimit: false组合
• Chrome下getBufferedAmount()对二进制帧统计不准，优先用文本帧做判断依据

队列要按连接隔离，别共用全局缓冲

所有消息都往一个channel里塞，等于把不同客户端的延迟互相绑架。A用户网络差拖慢B用户的实时行情推送，这是典型的设计缺陷。

• 用Map[sessionID]*Client维护连接粒度的recv/send队列
• 每个Client结构含独立closeCh、msgs chan、错误监听逻辑
• 定时检查len(c.recv)，超过阈值触发告警而非静默堆积
• 超时分层设置：socket write timeout（5s）、队列等待timeout（30s）、业务重试deadline（2min）