前端需节流而非简单缓冲：用requestidlecallback批量更新、时间窗口节流或丢弃旧日志，复杂处理移至web worker，并配合服务端序列号保障有序消费。
每秒超过 30 条 WebSocket 消息，前端不加节制地渲染，基本就卡死了。这不是浏览器不行，是你没控制好消费节奏。
onmessage 里别直接 setState 或 innerHTML
这是最常见也最致命的写法：ws.onmessage 回调一来就立刻更新状态或 DOM，等于把 100 次重绘塞进 1 秒——浏览器根本来不及 layout + paint。
- React/Vue 用户：改用
useRef或mutable ref暂存原始数据，避免每次触发响应式追踪 - 原生 JS 用户：把消息先 push 到数组，再用
requestAnimationFrame批量处理，一次刷新周期只 commit 一次视图 - 绝对不要在
onmessage里做 JSON.parse 以外的同步耗时操作（比如 moment 格式化、深克隆、正则匹配） - 加
try/catch包裹解析逻辑，单条坏数据不能让整个监听器崩掉
用 requestIdleCallback 做低优先级批量更新
requestIdleCallback 比 setTimeout(..., 0) 更靠谱，它真等浏览器空闲才执行，不会抢走动画帧或用户交互时机。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 适合日志类、监控面板类场景：把多条消息攒成数组，空闲时统一格式化、去重、截断后更新 UI
- 注意兼容性：
requestIdleCallback在 Safari 旧版本和部分安卓 WebView 中不支持，需 fallback 到setTimeout(..., 1) - 别传太大的数据块进去，否则空闲时间被占满，反而拖慢响应——建议单次处理不超过 50 条
Web Worker 处理解析与过滤逻辑
字符串分割、字段提取、条件过滤、序列号校验……这些活不该在主线程干。WebSocket 收到的是 raw string，不是 ready-to-render object。
- Worker 内只做纯计算：JSON.parse → 提取
seq和type→ 按业务规则丢弃/合并/转换 → postMessage 给主线程一个轻量对象 - 主线程只负责“画画”：收到 Worker 发来的 { type: 'update', data: [...] } 后，再决定怎么 setState 或 appendChild
- Worker 无法访问 DOM，所以别在里面写
document.querySelector——那是越界错误 - Worker 实例建议复用，不要每次 onmessage 都 new 一个，初始化成本高
服务端序列号 + 前端去重缓冲是防乱序的关键
网络抖动、重连、多 tab 共享连接，都可能导致消息乱序或重复。光靠前端缓冲，不带序号校验，缓出来的是错数据。
- 要求后端每条消息带严格递增的
seq字段（整数或时间戳+唯一 ID 组合） - 前端维护一个
lastProcessedSeq，收到新消息先比对，seq ≤ lastProcessedSeq就直接 skip - 缓冲区建议用 Map 而非数组：key 为
seq，value 为消息体，便于 O(1) 查重和按序遍历 - 页面切后台或连接中断时，清空接收缓冲区——旧 session 的 seq 不具备连续性，继续缓会出错
真正难的不是堆多少缓冲，而是判断哪条该留、哪条该丢、哪条该等。高频消息优化的本质，是用可控的延迟换确定的流畅。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
