高频websocket发送需用bufferedamount节流（如>65536字节暂停）、对鼠标/滚动等事件节流降频、区分消息优先级、服务端协同限流，并监听onclose/onerror实现背压闭环监控。
高频发送消息时，前端容易因 ws.send() 调用过快导致缓冲区堆积、内存上涨甚至连接被服务端强制关闭。这不是网络丢包问题，而是应用层背压失控——浏览器不暴露真实 TCP 缓冲状态，也无 drain 事件可监听，必须靠主动策略控制节奏。
用 bufferedAmount 做粗粒度节流
原生 WebSocket 的 bufferedAmount 属性虽不反映内核队列，但能反映 JS 层已调用 send() 却尚未发出的数据量，是唯一可用的实时参考指标：
- 设一个安全阈值，比如 64 KB（65536 字节），每次发消息前检查：
if (ws.bufferedAmount > 65536) { /* 暂停 */ } - 暂停后不要 busy-wait，改用
setTimeout或requestIdleCallback延迟重试，避免阻塞主线程 - 注意：该值为 0 不代表链路空闲，只说明 JS 层暂未继续推数据；它缓慢上涨时，往往已是背压早期信号
合并与降频高频事件源
鼠标移动、滚动、输入等事件天然高频，逐帧调用 send() 是典型踩坑点：
- 对非关键操作（如光标位置、滚动偏移）使用 throttle（节流），例如限制为每 100ms 最多发 1 条
- 对状态类消息（如“用户在线”“心跳”）大幅降频，或仅在状态变更时发送，而非周期轮询
- 允许客户端本地缓存最近一次有效值，后续相同内容直接跳过发送
区分消息优先级并协同服务端
不是所有消息都该平等对待。前端需配合服务端做分级处理：
- 关键指令（如“提交表单”“确认操作”）走独立通道或加
priority: "high"字段，服务端识别后跳过限流逻辑 - 非关键消息（如日志上报、UI 状态快照）在前端缓冲区超限时可主动丢弃，不重试
- 若服务端返回
close code 1008（policy violation），说明它因背压主动断连，此时前端应立即降低发送速率，并启用退避重连
监听异常并反馈闭环
流量控制不是单向压制，而需形成可观测闭环：
- 监听
onclose和onerror，记录event.code和event.reason，用于识别是否由背压触发 - 在开发环境开启
console.timeLog追踪连续send()调用间隔和bufferedAmount变化趋势 - 上线后可将缓冲峰值、丢弃消息数等指标上报监控系统，作为后续阈值调优依据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
