WebSocket流量控制必须做，否则会因缓冲区暴涨导致内存泄漏、连接假死和服务雪崩；uWebSockets.js需监听drain事件实现背压，ws库无此机制。
WebSocket流量控制不是“要不要做”的问题，而是“不做就崩”的事实——尤其当客户端处理慢、网络抖动或突发消息涌来时，ws.getBufferedAmount() 会悄无声息地涨到几MB，内存泄漏、连接假死、服务雪崩全跟着来。
ws.getBufferedAmount() 返回值暴涨但没反应？检查 drain 事件是否被忽略
这是最常踩的坑：只调用 ws.send()，却没监听 drain 事件。uWebSockets.js 不会自动暂停发送，它只在缓冲区腾出空间后发一次 drain，你必须自己接住并恢复发送逻辑。
-
drain是单次触发，不是持续回调；发完一批就得等下一次drain才能继续 - 如果
open阶段一口气发了 100 条消息，而客户端每秒只能消费 5 条，getBufferedAmount()会快速突破阈值，但若没drain处理，后续所有send()都会堆积在内存里 - 别在
drain里无条件循环发送——得配合当前缓冲量判断，否则可能刚清空又打满
正确写法示例：
open: (ws) => {
sendBatch(ws);
},
drain: (ws) => {
// 每次 drain 只补发到阈值内，避免过冲
while (ws.getBufferedAmount() < 8192 && hasMoreMessages()) {
ws.send(nextMessage());
}
}maxBackpressure 设太小或太大都危险：100KB 是多数场景的安全起点
maxBackpressure 不是“最大允许缓冲”，而是 uWebSockets.js 内部用于触发 drain 的参考水位。它不直接限制内存，但影响 drain 触发频率和系统响应灵敏度。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 设为
0：drain几乎不触发，等于放弃背压控制 - 设为
1024（1KB）：对高吞吐场景太激进，drain频繁触发，CPU 花费在事件调度上 - 设为
100 * 1024 * 1024（100MB）：单个慢连接就能吃掉百兆内存，服务器扛不住 - 推荐从
8192（8KB）起步，在压测中观察getBufferedAmount()峰值，再上调至峰值的 1.5 倍左右
closeOnBackpressureLimit = true 容易误杀正常连接
这个开关看似省事，实则粗暴。一旦某个客户端因临时网络卡顿导致缓冲堆积，closeOnBackpressureLimit 就会直接断开它——而此时对方可能只是延迟 2 秒，并非永久失联。
- 开启后，连接断开不抛错，也不走
close回调，排查时容易漏掉根源 - 更适合用在明确不可信的终端（如未认证的公网爬虫连接），而非真实用户
- 生产环境建议关掉，改用超时 + 缓冲量双判据：连续 5 秒
getBufferedAmount() > 64 * 1024且无新数据接收，再主动ws.close()
drain 事件无法捕获？确认你用的是 uWebSockets.js，不是 ws 或 Socket.IO
drain 是 uWebSockets.js 特有机制，Node.js 原生 ws 库没有该事件，Socket.IO 更是完全屏蔽底层缓冲细节。如果你在代码里写了 ws.on('drain', ...) 却没执行，大概率是库选错了。
- 检查
package.json：必须是"uWebSockets.js"，不是"ws"或"socket.io" - 确认实例化方式：
const app = uWS.App()启动，不是new WebSocket.Server() -
ws.getBufferedAmount()在ws库里也存在，但它是只读属性，不会随发送自动更新——uWebSockets.js 才真正联动 TCP 栈做背压传导
背压不是开关，是状态流：从 getBufferedAmount() 上升 → 触发限速 → 等待 drain → 恢复发送 → 循环。漏掉任一环，整个链条就断在内存里了。
