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() <h3>maxBackpressure 设太小或太大都危险：100KB 是多数场景的安全起点</h3><p><code>maxBackpressure</code> 不是“最大允许缓冲”，而是 uWebSockets.js 内部用于触发 <code>drain</code> 的参考水位。它不直接限制内存，但影响 <code>drain</code> 触发频率和系统响应灵敏度。</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2287" title="WebSocket 8.18.2"><img
														src="https://img.php.cn/upload/manual/001/221/864/6a1560869301b447.png" alt="WebSocket 8.18.2" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/gongju/2287" title="WebSocket 8.18.2" class="overflowclass">WebSocket 8.18.2</a>
													<p class="overflowclass">WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。</p>
												</div>
												<a rel="nofollow" href="/xiazai/gongju/2287" title="WebSocket 8.18.2" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>

• 设为 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 → 恢复发送 → 循环。漏掉任一环，整个链条就断在内存里了。