BufferedAmount 是 WebSocket 的只读属性，表示待发送字节数；持续增长主因是 send() 过频、网络慢、连接断开仍发送或发送大二进制数据；应结合 readyState 校验与 bufferedamountlow 事件实现安全发送控制。
BufferedAmount 是 HTML5 WebSocket API 中的一个只读属性，用于反映当前尚未被操作系统实际发送出去、仍保留在浏览器发送缓冲区中的字节数。它不是网络延迟的指标，也不代表服务器是否已接收，而是直接体现客户端本地待发数据的内存占用情况。
为什么 BufferedAmount 值会持续增长？
常见原因包括：
- 调用
send()频率过高，而底层 TCP 传输速度跟不上（如弱网、高延迟、服务端处理慢） - 未监听
bufferedamountlow事件，在缓冲区积压后未暂停发送 - WebSocket 连接已断开但代码仍在尝试发送（此时
bufferedAmount可能保持高位甚至不更新） - 发送的是大块二进制数据（如 Blob 或 ArrayBuffer），单次
send()就占数 MB 内存
如何用 BufferedAmount 实现安全发送控制？
核心思路是“发前检查 + 发后监听”，避免无节制堆积：
- 发送前判断：
if (ws.bufferedAmount （例如限制在 64KB 内） - 绑定
bufferedamountlow事件，在缓冲回落时恢复发送队列：ws.addEventListener('bufferedamountlow', () => { resumeSendQueue(); }); - 结合
readyState校验，仅在ws.readyState === WebSocket.OPEN时才允许发送
BufferedAmount 的局限性与注意事项
它不能替代业务层的确认机制：
立即学习“前端免费学习笔记（深入）”；
- 值为 0 仅表示浏览器已把数据交给 OS 协议栈，不代表服务器收到或处理成功
- 不同浏览器对缓冲区管理策略略有差异，Chrome 和 Firefox 的更新时机可能不同步
- 页面进入后台（如切换标签页）时，部分浏览器会暂停 WebSocket 发送，
bufferedAmount可能滞涨 - 无法区分文本帧和二进制帧的内部开销，实际内存占用略高于该值（含帧头等协议开销）
实用监控示例：实时打印与告警
可在开发或灰度环境中加入轻量监控：
setInterval(() => {
const amount = ws.bufferedAmount;
if (amount > 1024 * 1024) { // 超过 1MB
console.warn(`[WS] BufferedAmount too high: ${amount} bytes`);
}
console.debug(`[WS] buffered: ${amount} B`);
}, 2000);
生产环境建议改为采样上报，避免频繁日志影响性能。
