WebSocket乱码主因是event.data类型误判：若为ArrayBuffer却当字符串处理，或未用Uint8Array视图调TextDecoder.decode()，导致解码失败；务必先判断类型、正确转视图、抓包验证服务端是否真发UTF-8字节。
WebSocket接收端解码前先确认数据类型
乱码往往不是因为没设UTF-8，而是event.data根本不是字符串——它可能是ArrayBuffer、Blob或string，类型不同，解码方式完全不同。浏览器不会自动帮你转成字符串，直接console.log(event.data)看到“乱码”，可能只是你把它当字符串打印了，而它其实是二进制。
- 务必先判断类型：
if (event.data instanceof ArrayBuffer)或typeof event.data === 'string' - 服务端若明确发的是文本，但
event.data仍是ArrayBuffer，说明服务端用了二进制帧（opcode=2）而非文本帧（opcode=1），这违反协议本意，需修正服务端逻辑 - 用
TextDecoder解ArrayBuffer比new TextDecoder().decode(new Uint8Array(buffer))更安全，避免手动构造Uint8Array时出错
TextDecoder.decode()必须传Uint8Array，不能传ArrayBuffer
TextDecoder.decode()只接受Uint8Array或TypedArray子类，传ArrayBuffer会静默失败或返回空字符串，看起来像“收不到数据”，实则是解码被跳过。
- 正确写法：
const uint8 = new Uint8Array(event.data); const text = decoder.decode(uint8); - 错误写法：
decoder.decode(event.data)（event.data是ArrayBuffer时） - 别省略
new Uint8Array()这步——即使ArrayBuffer内容是UTF-8字节，不转成视图就无法被TextDecoder识别 - 如果消息分片到达（
event.data是多个ArrayBuffer拼接），需启用stream: true并缓存状态，否则首片解码后剩余字节会被丢弃
服务端发的真是UTF-8字节吗？抓包验证最可靠
前端无论怎么设TextDecoder，如果服务端发的压根不是UTF-8字节流（比如发了GBK、带BOM的UTF-8、或混入控制字符），解码必然失败。别猜，用Wireshark或浏览器Network面板的“Frames”标签看原始十六进制。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 标准UTF-8中文“你好”应为
EF BB BF E4 BD A0 E5 A5 BD（含BOM）或E4 BD A0 E5 A5 BD（无BOM） - 若看到
C4 E3 C0 D2这类双字节序列，就是GBK编码，问题在服务端没转UTF-8 - 若首字节是
EF BB BF（UTF-8 BOM），某些老旧服务端会把它当普通字符吞掉，导致后续字节偏移——此时客户端应ltrim或手动跳过BOM - Node.js/Go/Python服务端若用
JSON.stringify()发消息，记得加ensure_ascii=False（Python）或JSON_UNESCAPED_UNICODE（PHP），否则中文变\u4f60\u597d，体积翻倍且弱解析器易崩溃
不要依赖WebSocket.send(string)的隐式编码
虽然ws.send("你好")浏览器会自动转UTF-8，但这层隐式转换藏了风险：字符串含代理对（如emoji）、BOM、或被中间代理篡改时，结果不可控。生产环境建议绕过字符串路径，全程掌控字节。
- 发送端统一用
TextEncoder.encode()生成Uint8Array再send()，杜绝JS字符串到字节的黑盒转换 - 服务端若需兼容旧客户端，可在接收后检查首3字节是否为
EF BB BF，是则slice(3)再解码 - 避免在字符串拼接中混入
\uFEFF（零宽非断空格）等不可见字符，它们会污染UTF-8流，用str.replace(/\uFEFF/g, '')预处理 - 如果协议要求消息带长度头或校验和，必须用字节数组拼接，此时
TextEncoder是唯一可靠选择
实际中最容易被忽略的是：**服务端发的数据类型和帧类型（text vs binary）是否与协议约定一致**。很多“乱码”本质是opcode错配导致浏览器把二进制当文本解析，或者把文本帧当成二进制处理。动手前先看Frames面板里的opcode字段，比调编码参数管用十倍。
