关键在于两端二进制通道对齐、消息结构可识别、类型不丢失；需设socket.binarytype='arraybuffer'，用envelope封装type_id，前端预编译.proto为js模块，后端严格区分binary/text帧。
WebSocket 发送 Protobuf 数据不是“加个库就能跑”，关键在于两端二进制通道对齐、消息结构可识别、类型不丢失。直接上手容易卡在 onmessage 拿不到 ArrayBuffer 或解码报 invalid wire type。
设置 WebSocket binaryType 为 'arraybuffer' 是硬性前提
浏览器 WebSocket 默认以文本方式处理 message 事件，即使你发送的是 Uint8Array，若没显式指定接收格式，event.data 会是 Blob 或直接报错。
- 连接建立后必须立即设置：
socket.binaryType = 'arraybuffer' - 若用
protobuf.js，后续decode()要求输入Uint8Array，所以收到ArrayBuffer后需转一下：new Uint8Array(event.data) - 漏设
binaryType的典型现象：控制台无报错，但event.data类型是Blob，调arrayBuffer()会触发异步读取，破坏实时性
Protobuf 消息必须带唯一 type ID 或封装 envelope
Protobuf 本身不携带类型信息——ChatMessage.decode() 不知道该用哪个 class 去解。WebSocket 又是裸通道，没法像 gRPC 那样靠 HTTP header 传 content-type。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 常见做法是在每个二进制包前加 1–4 字节的
msg_type（如0x01表示登录，0x02表示聊天），服务端/前端按 ID 分发到对应decode()方法 - 更规范的做法是定义统一 envelope：
message Envelope { int32 type_id = 1; bytes payload = 2; }，先解 envelope，再根据type_id查表加载对应 schema - 跳过这步直接传原始
ChatMessage二进制，一旦后端混发多种消息，前端必然decode失败并抛出assert错误
前端用 protobuf.js 时，.proto 文件不能 runtime 解析
protobuf.js 支持两种模式：静态生成（推荐）和动态加载（load() + root.lookupType()）。但后者在浏览器里有严重限制：
- 动态
load()依赖fs或fetch加载 .proto 文本，无法处理import引用或嵌套package，极易报unresolved type - 生产环境应预编译：
npx pbjs -t static-module -w es6 -o chat_pb.js chat.proto，生成可直接import的 JS 模块 - 若用
protobuf-ts，则必须走protoc+ 插件生成，且注意其默认启用long: string，避免 JS 中int64精度丢失
FastAPI / Node.js 后端接收二进制帧要严格区分 text vs binary
FastAPI 的 websocket.receive_bytes() 和 websocket.receive_text() 是互斥的——发错类型会直接断连；Node.js 的 ws 库则默认把所有帧当 binary 处理，但需手动检查 isBinary 标志。
- FastAPI 示例中若客户端误发文本帧，
receive_bytes()抛WebSocketDisconnect，不是静默忽略 - Node.js
ws中，message事件的data参数类型取决于帧标志位，必须用if (typeof data === 'string')判断，否则Buffer.from(data)会乱码 - 建议后端统一要求 binary frame，并在连接握手阶段校验客户端 User-Agent 或自定义 header，拒绝非 binary-capable 客户端
最易被忽略的点：Protobuf 的 enum 默认从 0 开始，但很多团队习惯用 1 作为第一个有效值，前后端 enum 定义稍有不一致，解码后字段就变成 undefined 而非报错——这种 bug 很难定位，必须靠单元测试覆盖所有消息类型收发路径。
