WebSocket流控核心是匹配发送节奏与接收能力，而非简单禁止发送；send()成功仅表示入TCP缓冲区，需结合bufferedAmount、write_limit、max_queue等参数协同实现背压控制。
WebSocket 发送消息的流控逻辑，核心不是“不让发”，而是“让发送节奏匹配接收能力”。缓冲区溢出不是网络丢包，而是应用层队列撑爆内存或触发强制断连——尤其在嵌入式设备（如ESP32）、高吞吐服务端（Netty/Tomcat）或浏览器长时间会话中极为常见。
发送端需感知缓冲状态，而非依赖 send() 返回值
调用 send() 成功只代表数据进入底层 TCP 发送缓冲区，不代表对方收到、解析或处理。高频调用下，数据会在内核缓冲区或 WebSocket 库内部队列中堆积。
- 前端可用
ws.bufferedAmount实时判断待发字节数：超过阈值（如 64KB）时主动暂停，避免浏览器强制关闭连接 - Python
websockets库中，await websocket.send()会自动等待 write_limit 空闲，但必须显式配置write_limit=32768（默认值可能过大或过小） - ESP-IDF 的
esp_websocket_client_send()返回ESP_OK仅表示入队成功；必须检查真实错误码（如ESP_ERR_HTTP_CLIENT_NOT_CONNECTED），失败时应暂存本地队列而非重试
合理设置 max_queue 和 write_limit 避免内存陷阱
这两个参数控制的是“缓冲安全边界”，不是性能开关。设错会导致频繁背压或 OOM。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
max_queue=100：适合文本类消息（如聊天），单条几百字节，总内存可控 -
max_queue=10：适合大文件分片场景，配合 FIN 帧使用，防止单条大数据阻塞整个队列 -
write_limit=32768（32KB）：较通用的安全值；超长消息会被自动切帧，但需确保接收端支持分片重组 - 禁用
max_queue=float('inf')或write_limit=0，等于放弃流控
接收端必须主动限长 + 分片适配
发送端再谨慎，若接收端不限制帧长度或不处理分片，照样崩溃。
- Netty/Spring WebFlux 中，
maxFramePayloadLength是第一道防线，默认常为 10MB；若需传大消息，须显式设为100 * 1024 * 1024并同步调整底层 Reactor Netty 配置 - Tomcat 需在
web.xml中分别配置textBufferSize和binaryBufferSize，否则 >8KB 文本或二进制消息直接失败 - Chrome 实测单帧 >113KB 易触发
net::ERR_CONNECTION_RESET，建议服务端对 >64KB 消息主动分帧（如 uWebSockets.js 的sendFirstFragment/sendLastFragment）
客户端连接生命周期必须与资源解绑
前端不关 socket、不清监听器、不销毁定时器，会导致内存持续增长，最终页面卡死——这不是后端问题，是前端资源泄漏。
- 组件卸载时（React
useEffect cleanup/ VueonUnmounted），必须调用socket.close()并清空onmessage、onclose等引用 - 心跳定时器需配对清理：
const heartbeat = setInterval(...)→onclose中执行clearInterval(heartbeat) - 避免全局数组长期持有 socket 实例；改用
WeakMap或按需创建/销毁 - 收到大消息（如 Base64 图片）后，及时
delete或置null不再使用的字段，防止闭包隐式保留整块内存
