uWebSockets.js背压控制需协同配置maxBackpressure（推荐1MB）与closeOnBackpressureLimit（推荐false），并结合drain事件或轮询getBufferedAmount()主动降频，避免内存溢出和连接中断。
高并发下WebSocket消息积压不是“要不要处理”的问题，而是“不处理立刻出事”——内存持续上涨、连接被强制断开、GC频繁触发，甚至整个Node.js进程卡死。核心解法就一条：让发送端感知并服从接收端的实际吞吐能力。
uWebSockets.js里maxBackpressure和closeOnBackpressureLimit怎么配才不翻车
这两个参数必须一起看，单独调其中一个大概率失效。
-
maxBackpressure不是越大越好：设成50 * 1024 * 1024（50MB）看似容错强，但单连接吃掉50MB内存，在1000个连接时就是50GB——服务器先扛不住 -
closeOnBackpressureLimit设为true是保命开关，但不能只依赖它：等真触发时，用户已经断连，体验已毁 - 推荐组合：
maxBackpressure: 1024 * 1024（1MB） +closeOnBackpressureLimit: false，再配合主动检测逻辑
getBufferedAmount()返回值突变快，为什么监听它还经常漏判
因为它是异步快照值，不是实时流信号。调用瞬间返回的是内核缓冲区+应用层待写队列的总和，但这个值在两次调用之间可能跳变几十KB。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 别在
send()后立刻查：ws.send(msg); console.log(ws.getBufferedAmount())——这时很可能还没进缓冲区，返回0，误判安全 - 正确时机：在
ws.on('drain', ...)回调里查，或每100ms轮询一次，且连续3次≥80%阈值才触发降频 - 注意：Chrome里
getBufferedAmount()对二进制帧统计不准，文本帧才可靠；Firefox则基本准确
用节流（throttle）防积压，为什么Cycle.js里Time.throttle(100)有时没用
因为节流控制的是“处理速率”，不是“发送速率”。如果下游WebSocket.write()本身被阻塞，上游节流只是把消息堆在RxJS内部队列里，照样OOM。
- 必须配合
bufferWhen或windowWhen做分段缓冲，避免无限累积 - 示例：不要只写
source$.compose(Time.throttle(100))，要加保护：source$.pipe(bufferWhen(() => interval(100)), mergeMap(batch => from(batch).pipe(delay(1)))) - 更稳的做法：把节流逻辑下沉到uWebSockets.js的
ws.send()封装层，检测getBufferedAmount()后再决定是否真正发
最易被忽略的一点：背压不是单点配置能解决的——它横跨浏览器WebSocket API、服务端网络库（如uWebSockets.js）、业务消息队列、甚至前端RxJS操作符链。任何一个环节缺位，积压就会在那个环节爆发。调试时别只盯着服务端日志，抓包看ws.getBufferedAmount()变化曲线，比看代码更快定位瓶颈位置。
