websocket文本帧（opcode=0x1）仅承载合法utf-8字符串，二进制帧（opcode=0x2）传输任意原始字节流；二者语义不同，不可直接转换，需按协议规范与应用意图选择并保持类型一致。
WebSocket 的二进制帧和文本帧本质不同，不能直接“转换”，而是需按协议规范和应用层语义进行有意识的映射与处理。关键不在于字节层面的互转，而在于数据意图、编码方式与接收端预期是否匹配。
文本帧：UTF-8 字符串为唯一合法载荷
文本帧（opcode = 0x1）要求 payload 必须是合法的 UTF-8 字节序列。发送时，库（如 Java 的 createTextFrame("hello")）会自动做 UTF-8 编码；接收时，必须验证 UTF-8 合法性，否则应关闭连接或丢弃帧。
- 浏览器中通过
websocket.onmessage收到的是DOMString，已解码完成 - 若强行把二进制数据（如图片字节）塞入文本帧，会导致非法 UTF-8，引发解析失败或乱码
- Base64 编码后再放文本帧是常见折中方案，但体积增加约 33%，且需两端约定编解码逻辑
二进制帧：原始字节流，零编码开销
二进制帧（opcode = 0x2）的 payload 是任意字节序列，不作任何编码/解码假设。它不关心内容含义，只负责可靠传输。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 发送前需将数据构造成
ArrayBuffer、Uint8Array或Blob，再调用send() - 接收端需提前设置
websocket.binaryType = 'arraybuffer'，否则默认以Blob形式交付 - 常见用法：Protobuf 序列化结果、JPEG 文件块、音频 PCM 数据——直接写入 ArrayBuffer 即可发送
分片场景下的类型一致性规则
当消息过大需分片时，首帧决定整条消息类型，后续连续帧（opcode = 0x0）必须延续相同语义：
- 首帧是文本帧 → 所有分片都视为 UTF-8 片段，最终拼接后仍需整体 UTF-8 验证
- 首帧是二进制帧 → 所有分片都是原始字节，拼接后直接还原为完整 ArrayBuffer
- 禁止跨类型混用：不能用文本帧开头 + 二进制帧续传，协议层会报错
调试与误用的典型表现
实际开发中，类型错配往往表现为静默失败或不可读数据：
- 用
send("\u0000\u0001")发送含控制字符的字符串 → 文本帧可能被截断或触发安全策略 - 未设
binaryType就接收图片 → 得到 Blob，需额外用FileReader转 ArrayBuffer，增加延迟 - 服务端把 JSON 字符串误发为二进制帧 → 浏览器收到 ArrayBuffer，需手动
new TextDecoder().decode(buf)才能转成字符串
