websocket无直接带宽api，需通过send()和message事件估算应用层字节数：文本用textencoder.encode().length，二进制用bytelength或size；注意帧头与掩码开销，避免误用设备指标或网络面板。
WebSocket 本身不提供直接测量带宽消耗的 API，JavaScript 运行在浏览器沙箱中，无法访问底层 TCP 连接的字节统计（如已发送/接收字节数）。但你可以通过间接、可落地的方式估算带宽使用情况，重点聚焦在应用层可控的数据量上。
监控发送端数据量（客户端主动上报）
每次调用 socket.send() 时，你完全掌握要发送的内容。对文本消息可取 data.length（UTF-16 字符数），对二进制数据（Blob、ArrayBuffer、TypedArray）可直接用 .byteLength：
- 文本消息：
const bytes = new TextEncoder().encode(data).length（更准确，考虑 UTF-8 编码） - 二进制数据：
const bytes = data.byteLength - 建议封装发送函数，在发送前累加字节数，并按周期（如每5秒）上报到监控后台
估算接收端流量（基于 message 事件）
监听 message 事件后，同样可对收到的数据做字节估算：
- 若
event.data是字符串：用new TextEncoder().encode(event.data).length - 若
event.data是Blob：调用blob.size - 若
event.data是ArrayBuffer：直接读arrayBuffer.byteLength - 注意：不要依赖
event.data.toString().length，它返回字符数而非字节数，对中文等多字节字符会严重低估
结合 WebSocket 帧结构理解实际开销
真实网络带宽比应用层数据略高，因为每个 WebSocket 帧包含协议头（2–14 字节）和可能的掩码（客户端发给服务端必有 4 字节掩码）。但对大多数业务场景，应用层数据量已足够反映带宽趋势：
- 小消息（如 JSON 心跳
{"t":"ping"}≈ 12 字符）→ 实际帧约 20–30 字节 - 大消息（如 100KB 图片 ArrayBuffer）→ 协议头占比极小，可忽略
- 真正影响带宽的是你发送了什么、多频繁，而不是协议本身
避免常见误区
有些做法看似“监控带宽”，实则无效或不可靠：
- ❌ 试图用
performance.memory或navigator.connection.downlink代替实际流量统计——它们反映的是设备能力或内存，不是本次连接消耗 - ❌ 依赖浏览器开发者工具的“网络”面板——它只用于调试，不能用于线上持续监控，且数据不可编程获取
- ❌ 把 WebSocket 连接数或消息频率等同于带宽——100 条 10 字节消息 ≠ 1 条 1000 字节消息的带宽压力
- ✅ 正确思路：从源头（send / message）抓字节数，聚合、采样、上报，再结合业务维度（用户ID、页面、功能模块）分析
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
