WebSocket消息应采用统一JSON结构，包含type、data和可选id字段；发送前需try-catch校验并stringify，接收后须严格parse及字段验证；前后端须共享协议规范，错误时返回标准error消息。
WebSocket 本身不规定消息格式，JSON 只是常用的数据序列化方式。关键在于双方约定统一的结构，确保发送方序列化正确、接收方能安全解析并识别业务意图。
定义基础 JSON 消息结构
推荐采用包含 type（操作类型）、data（有效载荷）和可选 id（用于请求响应匹配）的通用格式：
- type：字符串，如 "login"、"chat"、"pong"，用于路由或业务分发
- data：任意合法 JSON 值（对象、数组、字符串等），承载具体业务数据
- id（可选）：字符串或数字，客户端发请求时带上，服务端响应时原样返回，便于前端关联异步结果
示例：
{"type":"login","id":"req_123","data":{"username":"alice","token":"xyz"}}发送前始终使用 JSON.stringify 并捕获错误
JavaScript 对象可能含函数、undefined、循环引用等非法 JSON 值，直接 stringify 会报错或静默丢失字段：
立即学习“Java免费学习笔记（深入）”；
- 用
try...catch包裹JSON.stringify()，避免因序列化失败导致连接中断 - 对
data字段做预校验（如检查是否为纯对象/数组），或使用安全序列化工具（如safe-json-stringify） - 不要直接 send 原始对象：
ws.send({type: 'msg', data: ...})❌；必须 stringify：ws.send(JSON.stringify(msg))✅
接收时严格解析并验证结构
服务端和客户端都需防御性处理非预期消息：
- 用
JSON.parse()解析，外层 try/catch 捕获语法错误（如截断、乱码） - 检查解析后对象是否为 object、是否存在
type字段、type是否为字符串 - 根据
type分支处理，忽略未知 type 或返回标准化错误消息 - 对
data字段按业务规则进一步校验（如 login 请求中 username 是否为非空字符串）
保持双向协议一致性
前后端需共享同一份消息规范文档（哪怕只是注释或类型定义）：
- 用 TypeScript 定义消息类型，生成 .d.ts 供前端和 Node.js 后端共用
- 服务端收到消息后，若校验失败，应主动发回带 error type 的响应，如：
{"type":"error","id":"req_123","data":{"code":"INVALID_DATA","message":"missing username"}} - 心跳、重连、鉴权等场景也走同一 JSON 结构，避免混用裸字符串或二进制
