websocket 消息需显式解析：先设 binarytype="text" 确保 event.data 为字符串，再用 try...catch 安全 json.parse()，校验字段存在性及业务状态码，避免 xss、双重转义和未就绪发送。
WebSocket 接收到的消息本质是字符串（或 Blob / ArrayBuffer），不是自动解析的 JS 对象。要正确处理 JSON 格式消息，关键在于“显式反序列化”和“防御性校验”，不能依赖浏览器自动转换。
确认数据类型并统一设为 text
浏览器中 WebSocket 默认 binaryType 是 "blob"，即使后端发的是 JSON 字符串，event.data 也可能是 Blob 对象——直接 console.log(event.data) 就会显示 [object Object]。解决方法很简单：
- 在连接建立后、接收消息前，设置
socket.binaryType = "text" - 这样
event.data就是字符串类型，可直接传给JSON.parse() - 不推荐依赖
typeof event.data === 'string'判断，应以binaryType设置为准
用 try...catch 安全解析 JSON
服务端偶尔可能发空字符串、纯文本错误提示、或格式错误的 JSON，直接 JSON.parse() 会抛错并中断整个 onmessage 流程。必须包裹异常处理：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 始终用
try { const obj = JSON.parse(event.data); ... } catch (e) { console.error('解析失败', e, event.data); } - 不要在 catch 中静默吞掉错误，至少记录原始数据，便于排查服务端问题
- 解析成功后，建议检查关键字段是否存在，例如
obj.type !== undefined，避免后续访问obj.type.xxx报错
解析后按约定结构使用数据
实际项目中，前后端通常约定统一响应格式（如含 code、msg、data 的结构）。拿到解析后的对象后，应先判断业务状态再取值：
- 若
obj.code === 200，才安全读取obj.data中的业务字段 - 若
obj.code === 401，触发登录态刷新或跳转 - 避免把
obj.data当作必存在字段直接展开，防止Cannot read property 'xxx' of undefined
避免常见误操作
这些做法看似省事，实则埋下隐患：
- ❌ 直接
socket.send({ type: 'msg', text: 'hi' })——send()不接受对象，会报错 - ❌ 收到后写
document.getElementById('msg').innerHTML = event.data—— 可能引发 XSS，且显示原始 JSON 文本 - ❌ 后端已发 JSON 字符串，前端又
JSON.stringify(event.data)—— 得到双重转义字符串，如"{\"type\":\"login\"}" - ❌ 忽略
readyState检查就调用send()，连接未就绪时消息丢失无提示
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
