WebSocket传Protobuf需设binaryType='arraybuffer'，服务端发原始二进制帧，前端手动处理长度前缀；避免permessage-deflate，优化.proto定义（如sint32、packed、类型ID）比压缩更有效。
WebSocket发Protobuf数据，关键不在“能不能压”，而在“要不要压”——绝大多数场景下，permessage-deflate不仅不省流量，反而拖慢高频小包、增加移动端发热。真正该做的，是让Protobuf消息本身更小、传输更稳。
必须设 socket.binaryType = 'arraybuffer'
浏览器默认把二进制帧当 Blob 传给 onmessage，但 protobuf-ts 或 protobufjs 的 decode() 只认 Uint8Array 或 ArrayBuffer。漏设这行，控制台立刻报 TypeError: Cannot read property 'length' of undefined。
- 连接建立后第一件事：执行
socket.binaryType = 'arraybuffer' - 服务端必须发原始二进制帧（如 Netty 的
BinaryWebSocketFrame，FastAPI 中用bytes字段），不能发 Base64 字符串再让前端atob()转 - 如果后端已加 4 字节长度前缀，前端需手动切掉：
const payload = new Uint8Array(event.data, 4)
Message.decode() 报 “invalid wire type” 或 “truncated” 怎么办
这两个错误本质都是字节数组损坏或不完整。Protobuf wire format 对数据完整性零容忍，少 1 字节、多 1 个 BOM 头都会崩。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 先校验长度：
if (event.data.byteLength 直接丢弃（最简 <code>sint32字段也需至少 2 字节） - 确认服务端没混入 HTTP 头、JSON 包裹层或调试日志前缀
- 弱网下分片未收全就调用
decode()？加个长度守门：if (buffer.length !== expectedLength)暂存待补全 - 移动端尤其注意 WebView 缓存 bug：iOS WKWebView 有时静默截断 ArrayBuffer，加个
setTimeout(() => {}, 0)延迟 decode 可缓解
别急着开 permessage-deflate，先看 Protobuf 本身有没有浪费字节
实测 3.8 KB 的 Protobuf 消息经 permessage-deflate 后仅剩 3.6 KB，但 CPU 解压耗时涨 15%～20%，移动端发热明显。真正该压的不是 Protobuf 二进制，而是你协议设计里的冗余。
- 整型字段全改用
sint32（ZigZag 编码），负数 -1 只占 1 字节；禁用int64/uint64（JS 精度丢失必转字符串，体积翻倍） - 高频
repeated字段显式加[packed=true]，避免每个元素带独立 tag - 消息头部加 1 字节类型 ID（如
0x05表示HeartbeatReq），不依赖反射查类型，省解析开销 - 大字段（头像 Base64、日志块）根本别进 Protobuf，换 CDN URL 或分片上传 ID
超 50 KB 的 Protobuf 消息必须分片，不是压缩
单帧 >50 KB 即使开了 permessage-deflate，也容易触发 TCP 分片重传放大延迟——弱网下丢一个包就得重传整帧。客户端主动分片才是正解。
- 发送前检查：
if (buffer.byteLength > 50 * 1024) - 切为 ≤48 KB 的分片（留 2 KB 给序号+校验头），每片加 2 字节头部：
Uint16Array([seq, total]) - 服务端收到首片即返回 ACK 帧，避免客户端盲目重发
- 分片间用
setTimeout错开 5～10 ms 发送，防 burst 拥塞
最易被忽略的是：Protobuf 省流效果高度依赖协议定义质量，而不是传输层是否开了压缩。写 .proto 文件时多花两分钟选对类型、加好 packed、砍掉冗余字段，比后期硬套 permessage-deflate 省心又高效。
