websocket收到event.data是blob还是arraybuffer取决于服务端发送内容及前端是否设置socket.binarytype；浏览器默认为blob，但protobuf解码需uint8array或arraybuffer，故连接建立后应立即设socket.binarytype = 'arraybuffer'。
WebSocket收到event.data是Blob还是ArrayBuffer？
取决于服务端发的是什么，也取决于你有没有提前设socket.binaryType。浏览器默认把二进制帧当作Blob对象传给onmessage，但Blob不能直接喂给Protobuf解码器——它得先转成Uint8Array或ArrayBuffer。
所以连接一建立就得立刻执行：
socket.binaryType = 'arraybuffer';
这样后续所有event.data就是ArrayBuffer，省去Blob.arrayBuffer()这一步。如果漏了这行，你会在控制台看到TypeError: Cannot read property 'length' of undefined之类报错，因为Message.decode()不认Blob。
- 服务端发的是
BinaryWebSocketFrame（如Netty）或bytes字段（如FastAPI），且前端没设binaryType→event.data是Blob - 设了
socket.binaryType = 'arraybuffer'→event.data是ArrayBuffer，可直接用new Uint8Array(event.data) - 用
protobuf-ts时，decode()只接受Uint8Array；用protobufjs老版本，部分API接受ArrayBuffer但更推荐统一转Uint8Array
Message.decode()报错“invalid wire type”或“truncated”怎么处理？
这两个错误基本都指向一个事实：你传进去的字节数组长度不对，或者开头几个字节被截断/污染了。
Protobuf wire format对数据完整性极其敏感，哪怕少1个字节、多1个BOM头，都会解码失败。移动端弱网下尤其常见。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 先校验长度：
if (event.data.byteLength —— 最小合法Protobuf包至少含1字节tag+1字节value（比如单个<code>sint32字段） - 确认服务端没加额外包头（如自定义4字节长度前缀）；如果加了，必须手动切掉：
const payload = new Uint8Array(event.data, 4) - 检查是否误把字符串当二进制发：后端用
JSON.stringify()再atob()转Base64，前端又用Uint8Array.from(atob(...), c => c.charCodeAt(0))——这种链式编码极易出错，应直接走原生二进制 - 开发期开启
protobuf-ts的strict模式，它会在字段缺失或类型错位时抛明确错误，而不是静默失败
用protobuf-ts还是protobufjs？选型关键差异
不是功能差多少，而是体积、TS支持和默认行为是否贴合现代前端工程。
protobuf-ts编译产物约15KB（gzip后），零运行时反射，生成代码带完整TS类型；protobufjs全量包超70KB，需手动loadProtoFile或预编译，且默认启用动态解析，容易在tree-shaking时残留无用代码。
- Vue3/Vite/SvelteKit项目优先选
protobuf-ts：npx protoc --ts_out=. --plugin=protoc-gen-ts ./msg.proto，然后import { PlayerPosition } from "./proto/msg.js" - 若必须用
protobufjs（比如要兼容IE11），务必用pbjs -t static-module生成JS模块，别用load()动态加载，否则.proto文件会暴露在源码中 - 两者对
packed=true、sint32等优化特性的支持一致，但protobuf-ts默认禁用int64（强制转string），避免JS精度丢失，这点很关键
高频小包场景下，为什么repeated int32 x = 1 [packed=true]比普通repeated省一半流量？
Protobuf wire type 2（length-delimited）用于普通repeated，每个元素都带独立tag+length+value；而packed=true改用wire type 2 + 单次length前缀，把多个数值连续写入，省掉重复tag和length开销。
比如发送[1, 2, 3, 4, 5]五个int32：
- 未
packed：每个数占5字节（1字节tag + 4字节值）→ 共25字节 - 启用
packed：1字节tag + 1字节length（表示20字节内容） + 20字节纯数值 → 共22字节，且随数量增长优势放大 - 移动端每秒10次位置同步，一年下来能省几百MB流量，这不是理论值，是实测值
真正容易被忽略的是：这个优化必须前后端协议定义完全一致——只要有一端没加[packed=true]，解码就会失败或丢数据。上线前务必用真实二进制dump比对两端输出。
