结论是前端未正确序列化导致显示[object Object]：因event.data可能是Blob或ArrayBuffer，直接console.log会调用toString()；应设binaryType="text"后JSON.parse()，并加try/catch防解析失败。
![websocket接收到的消息是[object object]怎么解析 转换方法【笔记】](https://img.php.cn/upload/article/001/221/864/178003564860490.png)
直接说结论：这不是 WebSocket 本身的问题，而是前端用 console.log() 或字符串拼接时没做序列化，对象被自动调用了 toString() —— 所以看到 [object Object]，不是收错了，是“打印错了”。
为什么 event.data 打出来是 [object Object]
WebSocket 收到的原始数据类型取决于后端发什么、前端怎么读：
- 如果后端发的是 JSON 字符串（比如
{"type":"login","id":123}），但前端用event.data.toString()或直接console.log(event.data)，而event.data实际是Blob或ArrayBuffer，那就会触发默认toString()，输出[object Object] - Node.js 的
ws库默认把消息解析为Buffer；浏览器原生 WebSocket 则根据binaryType设置决定是"blob"还是"arraybuffer" - 如果你用的是
JSON.stringify()发送，就必须用对应方式接收并JSON.parse()，不能跳过这步
如何正确解析 WebSocket 收到的 JSON 对象
关键在两步：确认数据类型 + 显式反序列化。常见写法：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 先设
socket.binaryType = "text"（推荐），这样event.data就是string类型，可直接JSON.parse(event.data) - 如果不设，且
event.data是Blob，得用event.data.text().then(str => JSON.parse(str)) - 如果是
ArrayBuffer，需转成字符串：new TextDecoder().decode(event.data)，再JSON.parse() - 务必加
try/catch：后端偶尔发错格式（比如纯文本、空字符串、未闭合 JSON），JSON.parse()会直接抛错中断逻辑
容易踩的坑：后端发的是 Buffer，前端却当 string 用
尤其在 Node.js + ws 场景下，默认所有消息都是 Buffer。如果你后端写的是：
ws.send(JSON.stringify({ status: 'ok' }))
前端没处理好，直接 console.log(event.data)，就会看到 [object Object]（因为 Buffer.toString() 默认是 utf-8，但日志里不显示内容）。验证方法：
- 打个断点，看
event.data.constructor.name是Buffer（Node）还是String（浏览器设了binaryType） - Node 端调试时，用
console.log(event.data.toString())才能看到真实字符串 - 浏览器里别依赖
typeof event.data === 'string'，先检查socket.binaryType和实际event.data构造器
最稳的做法：后端统一发 JSON 字符串，前端统一设 binaryType = "text"，收到后只走 JSON.parse() —— 中间不掺任何隐式转换。多一次 try/catch 比查半天为什么是 [object Object] 省时间。
