onmessage是WebSocket接收服务器推送数据的核心入口，需正确绑定事件、解析消息内容并处理数据格式与异常；其基本用法为监听MessageEvent对象的event.data，依类型（字符串/Blob/ArrayBuffer）解析；应校验空值、区分type字段分发业务、校验敏感字段；需用try...catch防崩溃，避免重复绑定导致重复处理，配合onopen/onerror/onclose实现健壮通信链路。
WebSocket 的 onmessage 是接收服务器推送数据的核心入口，关键在于正确绑定事件、解析消息内容，并处理好数据格式和异常场景。
onmessage 基本用法：监听并提取业务数据
WebSocket 实例创建后，通过赋值 onmessage 回调函数来接收服务端发送的每条消息。消息体默认是 MessageEvent 对象，真实数据在 event.data 中：
- 如果服务端发的是字符串（如 JSON），
event.data就是字符串，需手动JSON.parse() - 如果发的是
Blob或ArrayBuffer，需根据event.data.type或上下文做相应解析 - 建议在回调开头加
if (!event.data) return;防空数据引发错误
处理常见业务数据格式
实际项目中，服务器常按统一协议推送结构化数据，比如带 type 字段区分消息类型：
- 收到
{"type":"order_update","data":{...}}，可按type分发到对应业务逻辑 - 若数据含时间戳或版本号（如
seq），建议校验顺序或去重，避免重复渲染 - 对敏感字段（如用户余额、状态）做类型和范围校验，防止非法数据触发 UI 异常
健壮性要点：避免 onmessage 失效或丢失数据
onmessage 是一次性绑定，但容易因重连、作用域丢失或未捕获异常而中断：
立即学习“Java免费学习笔记（深入）”；
- 不要在函数内重复 new WebSocket 后不清理旧实例，否则旧的
onmessage仍可能触发，造成重复处理 - 在
onmessage内部用try...catch包裹 JSON 解析和业务逻辑，防止某条脏数据导致整个监听器崩溃 - 连接恢复后，服务端一般不会补推断连期间的数据，如有必要，应主动发同步请求（如
send({action:'sync',from:timestamp})）
配合其他事件形成完整链路
onmessage 不是孤立使用的，需与 onopen、onerror、onclose 协同：
-
onopen中可发送认证信息或订阅指令，让服务端知道客户端要接收哪些业务流 -
onerror不代表连接失败，只是底层报错，通常只需记录日志；真正判断断连看onclose -
onclose触发后应清空定时器、取消 pending 请求，并触发自动重连逻辑（如指数退避）
