WebSocket传Protobuf的核心是协议设计、传输配置和错误防御：必须设binaryType='arraybuffer'，服务端发原始二进制帧，禁用permessage-deflate，优化.proto定义（如sint32、packed、类型ID），并校验长度、分片处理及防截断。
WebSocket 传 Protobuf 的核心不是“怎么压”，而是“怎么让二进制更干净、更可控”。关键不在加压缩，而在协议设计、传输配置和错误防御三件事上。
必须设 binaryType = 'arraybuffer'
浏览器默认把 WebSocket 二进制帧当 Blob 传给 onmessage，但 protobuf-js 或 protobuf-ts 的 decode() 只接受 Uint8Array 或 ArrayBuffer。漏设这行，立刻报 TypeError: Cannot read property 'length' of undefined。
- 连接建立后第一件事：
socket.binaryType = 'arraybuffer' - 别在中间层转 Base64：服务端必须发原始二进制帧（如 Netty 的
BinaryWebSocketFrame，FastAPI 中用bytes字段） - 如果后端加了 4 字节长度前缀，前端要手动切掉：
const payload = new Uint8Array(event.data, 4)
避开 permessage-deflate 这个坑
实测：3.8 KB 的 Protobuf 消息经 permessage-deflate 后只剩 3.6 KB，但 CPU 解压耗时涨 15%～20%，移动端发热明显。高频小包反而更慢——因为压缩/解压开销远超节省的带宽。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 真正该优化的是 Protobuf 本身：用
sint32（ZigZag 编码）代替int32，负数 -1 只占 1 字节 - 禁用
int64/uint64：JS 精度丢失，必须转字符串，体积翻倍 - 高频 repeated 字段显式加
[packed=true]，避免每个元素带独立 tag - 消息头部加 1 字节类型 ID（如
0x05表示心跳），省去反射查类型的开销
防错：Protobuf 对字节零容忍
invalid wire type 和 truncated 都是字节数组损坏或不完整导致的。Protobuf wire format 不容错——少 1 字节、多 1 个 BOM 头都会崩。
立即学习“Java免费学习笔记（深入）”；
- 先校验长度：
if (event.data.byteLength （最简 <code>sint32字段也需至少 2 字节） - 确认服务端没混入 HTTP 头、JSON 包裹层或调试日志前缀
- 弱网下分片未收全就调用
decode()？加守门逻辑：if (buffer.length !== expectedLength) { 暂存待补全 } - iOS WKWebView 有时静默截断 ArrayBuffer，加
setTimeout(() => {}, 0)延迟 decode 可缓解
大消息必须分片，不是压缩
单帧超过 50 KB 的 Protobuf 消息，即使开了 permessage-deflate，也容易触发 TCP 分片重传，弱网下丢包率陡增、延迟放大。
- 头像、日志块等大字段根本别进 Protobuf，换成 CDN URL 或分片上传 ID
- 超 50 KB 的消息，服务端按固定块大小（如 16 KB）分片，加序号和总片数字段
- 客户端按序缓存、拼接完成后再 decode，避免碎片 decode 报错
