根本原因是应用层缓冲区溢出或接收方处理不过来，需用队列缓冲、背压机制与发送确认协同解决；send()成功仅表示数据写入TCP缓冲区，不保证对方接收或处理。
WebSocket发送太快导致丢包，根本原因不是TCP层丢包，而是应用层缓冲区溢出或接收方处理不过来。解决它不靠“限速”，而靠队列缓冲 + 背压机制 + 发送确认三者协同。
为什么send()调用成功不代表消息已送达
浏览器或websockets库的send()方法返回成功，只表示数据已写入底层TCP socket发送缓冲区，并不保证对方已接收、解析、处理。尤其在高并发推送场景下，服务端或客户端的接收队列可能瞬间积压，触发自动丢弃（如max_queue超限）或阻塞崩溃。
- Python
websockets库中，send()是异步非阻塞的，若未配write_limit和背压，会持续往内核缓冲区灌数据 - ESP-IDF 的
esp_websocket_client_send()返回ESP_OK仅表示入队成功，若底层发送失败（如网络卡顿），错误码会被吞掉，必须显式检查返回值 - 前端使用原生
WebSocket时，readyState !== OPEN下调用send()会直接抛异常，但很多代码没做兜底，消息就静默丢失
max_queue 和 write_limit 怎么设才不踩内存陷阱
这两个参数控制的是“缓冲上限”，不是“性能开关”。设得太小，容易频繁触发背压暂停；设得太大，OOM风险陡增——尤其当单条消息含大量二进制帧时。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
max_queue=100：适用于文本类聊天消息，每条平均几百字节，总内存可控 -
max_queue=10：适合大文件分片传输场景，配合FIN帧控制，避免整条消息卡在队列里阻塞后续 -
write_limit=32768（32KB）：是较安全的默认值，超过此大小的待发消息会被切帧，但需确保接收端支持分片重组 - 绝对不要设
max_queue=float('inf')或write_limit=0，这等于放弃流量控制
如何让发送真正“等一等”而不是盲目重试
盲目循环send() + setTimeout重试，只会加剧缓冲区压力。真正在意可靠性，就得把发送逻辑和队列状态绑定。
- Python
websockets中，用await websocket.send(...)配合write_limit，底层会自动等待缓冲区有空间才写入 - 前端可用
websocket.bufferedAmount做粗粒度判断：if (ws.bufferedAmount > 65536) { await new Promise(r => setTimeout(r, 10)); } - ESP-IDF 必须检查
esp_websocket_client_send()返回值：if (err == ESP_ERR_HTTP_CLIENT_NOT_CONNECTED || err == ESP_ERR_INVALID_STATE)，此时应入本地队列而非重试 - ReconnectingWebSocket 库的
maxEnqueuedMessages: 50是硬限制，超了会throw，必须捕获并降级处理（如存localStorage）
背压暂停时，recv_flow_control 锁住的是什么
它锁的不是连接，而是“接收路径上的帧组装器”。当接收队列达到max_queue_high，acquire()被调用，后续recv()将阻塞，直到消费线程把队列降到max_queue_low以下再release()。这个设计的关键在于：暂停只影响新帧进入，不影响已入队消息的处理。
- 不要在持有
recv_flow_control锁期间做耗时操作（如DB写入），否则整个接收流卡死 -
max_queue_high=200和max_queue_low=50是推荐组合，留出150条缓冲空间供消费线程“喘息” - 如果你用的是自研接收逻辑，别自己实现类似锁，优先复用
websockets.Assembler或SimpleQueue这类经过压测的结构
最容易被忽略的一点：背压和队列只管“收得下”，不管“处理对”。哪怕所有消息都进了队列、也发出去了，若业务逻辑里没做消息ID去重或ACK确认，网络抖动后重连，照样重复或丢失。流量控制是地基，不是屋顶。
