结论是前端未正确序列化导致显示[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?x-oss-process=image/resize,p_40)
直接说结论:这不是 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 对象
关键在两步:确认数据类型 + 显式反序列化。常见写法:
- 先设
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。如果你后端写的是:
WebSocket 8.18.2 是该协议规范的一个重要迭代版本,主要优化了连接稳定性与数据传输效率。它通过全双工通信机制,允许客户端与服务器在单一长连接上实时交换数据,大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力,适用于即时通讯、在线游戏及金融行情推送等低延迟场景,为开发者提供更可靠的实时网络交互基础。
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] 省时间。










