直接用json.stringify()在主线程序列化大json是架构级错误，必须用web worker剥离序列化、改用二进制帧+享元编码、服务端只推delta并三层过滤，配合worker耗时监控与devtools验证。
直接用 JSON.stringify() 处理大 JSON 后走 WebSocket 发送，是前端卡顿、内存爆掉、长任务触发的头号原因——这不是“要不要压缩”的问题，而是“必须把序列化从主线程踢出去”的问题。
WebSocket发送前别在主线程调用JSON.stringify()
10MB 的状态对象在主线程里 stringify 一次，轻松阻塞渲染线程 100ms+，滚动掉帧、动画卡顿、用户操作无响应全由此起。这不是性能差，是架构级错误。
- 必须用
Web Worker承担序列化：主页面只postMessage()原始对象，Worker 内完成JSON.stringify()或更优方案（如structuredClone()+TextEncoder.encode()） - 含循环引用、
Date、Map、Set的数据，务必先structuredClone()深拷贝再传给 Worker，否则主线程可能意外被冻结 - 禁用同步读取链路：比如
localStorage.getItem()+JSON.parse()组合，改用IndexedDB存预序列化后的ArrayBuffer，按需流式加载
放弃文本帧，切到二进制帧 + 享元编码
高频消息字段高度重复（如 "type": "click"、"event": "chat"），反复 stringify 纯属浪费 CPU 和带宽。
- 提前把固定字段转为共享
Uint8Array片段，拼接时直接copy，不走字符串拼接 - 改用二进制帧（
Opcode=0x2），消息头用Uint16Array编码（类型+长度），payload 紧凑排列，体积比 JSON 小 50% 以上 - 结构稳定但字段多时，上
protobufjs或msgpack-lite，JS 库支持直出Uint8Array，零字符串开销
服务端不推全量，前端只收 delta
前端再快，也扛不住服务端每秒往一万个客户端广播 200KB 的全量 JSON——真正瓶颈常在广播路径本身，不是你写的 JS。
- 服务端维护状态快照（Redis Hash / Caffeine），新用户拉一次全量；后续只推送
{"rank": 3, "score_delta": +120}这类 delta，体积常压到原 JSON 的 3% 以内 - 启用消息合并（burst merge）：100ms 时间窗内同类型事件（如 37 条“点赞”）打包成一个数组下发，客户端统一解析，减少帧数和序列化调用次数
- 广播前按房间 ID、在线状态、权限等级三层过滤，跳过僵尸连接和无权接收者，避免无效序列化
最易被忽略的是监控兜底：Worker 里必须加耗时监控（performance.now()），超过 20ms 自动告警并降级为简化格式；Chrome DevTools 的 Network → WebSocket → Frames 标签要常开，确认是否真在发二进制帧、是否真被压缩——没观测，就等于没优化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
