bufferedAmount 返回未发出的累积字节数，非消息条数或实时队列长度；仅 send() 后更新，依赖底层协议栈确认后递减，用于背压控制与溢出防护。
WebSocket 的 bufferedAmount 属性是唯一原生支持的发送缓冲区监控机制，它返回当前已调用 send() 但尚未被底层网络协议栈真正发出的字节数（含二进制数据和文本编码后的 UTF-8 字节长度）。它不是实时“队列长度”，而是未确认传输的**累积字节数**，对判断发送压力、避免内存溢出或实现背压控制非常关键。
理解 bufferedAmount 的真实含义与限制
该属性反映的是浏览器内部发送缓冲区中待处理的原始字节总量，不是消息条数，也不区分帧类型（text/binary）；它仅在调用 send() 后立即更新，且不会自动清零——只有当浏览器完成将数据交给操作系统 TCP 栈（或 WebSocket 协议层封装后提交给网络）后，该值才逐步下降。注意：
– 它不包含尚未进入缓冲区的待发送数据（比如你还没调用 send）
– 它不反映服务端是否已接收或处理，只管“发没发出去”
– 在高频率 send 场景下，可能短时间内飙升，尤其发送大 Blob 或 base64 图片时
基础监控：轮询 + 阈值告警
最简单有效的方式是定时检查并对比阈值：
- 使用
setInterval每 100–500ms 读取一次ws.bufferedAmount - 设定合理上限（如 1MB = 1048576），一旦超过即暂停新消息发送或触发降级逻辑
- 示例：if (ws.bufferedAmount > 1024 * 1024) { pauseSending = true; console.warn("Send buffer overloaded"); }
结合事件优化：利用 onopen 和 onclose 做状态重置
bufferedAmount 在连接关闭后归零，但重连时需重新初始化监控逻辑：
-
onopen中启动/恢复轮询，清除旧计时器 -
onclose或onerror中停止轮询，并记录最终积压量用于故障分析 - 避免在连接未就绪（
readyState !== 1）时读取，此时值恒为 0 且无意义
进阶实践：配合发送节流与 backpressure 反馈
纯前端监控不足以应对长连接弱网场景，建议叠加轻量级协作机制：
立即学习“前端免费学习笔记（深入）”；
- 在每条重要消息发送前检查：
if (ws.bufferedAmount ，否则入本地队列等待 - 监听
beforeunload或页面隐藏时，主动调用ws.close()防止残留积压 - 服务端可定期推送
{"type":"ping","buffer_hint":12345}类似提示，辅助前端动态调整发送策略
不复杂但容易忽略：bufferedAmount 是只读数值，无法手动清空；它的价值不在“精确队列管理”，而在提供一个低成本、低侵入的拥塞信号。合理使用，能显著提升 WebSocket 应用在弱网、高并发下的稳定性与用户体验。
