前端卡顿主因是主线程高频DOM更新或JSON解析，应通过节流和消息合并缓解：onmessage仅缓存数据，用requestAnimationFrame批量渲染，并设缓冲区上限防内存溢出。
直接结论：前端卡顿不是WebSocket本身的问题，而是你让主线程每秒处理100+次DOM更新或JSON解析。节流和消息合并是成本最低、见效最快的两个手段。
onmessage里别直接setState或渲染
这是最常踩的坑——每条消息都触发一次setState、innerHTML = ...或Vue.set，浏览器来不及完成重排重绘就收到下一条。React/Vue/Svelte都会因此堆积大量pending更新，最终卡死。
- 真实错误现象：
RangeError: Maximum call stack size exceeded（递归更新）、Layout thrashing警告、FPS掉到5以下 - 正确做法：把
onmessage变成纯数据收集入口，只做buffer.push(data)，不碰DOM、不调状态更新函数 - Vue用户注意：
ref或reactive对象被高频赋值时，响应式系统开销会指数级上升；改用普通数组缓存更轻量
用requestAnimationFrame做天然节流
比setTimeout或Lodash的throttle更准，它绑定浏览器刷新节奏，确保每次只在下一帧执行一次批量更新。
- 示例逻辑：
let buffer = []; let isProcessing = false; ws.onmessage = (e) => { buffer.push(JSON.parse(e.data)); if (!isProcessing) { isProcessing = true; requestAnimationFrame(processBatch); } }; function processBatch() { const batch = buffer.splice(0, 50); // 每次最多处理50条 renderToUI(batch); // 这里才真正更新DOM isProcessing = false; } - 为什么不用
setInterval(16)？它不感知页面是否可见、是否被节流，而requestAnimationFrame在标签页后台时自动暂停，更省资源 - 注意：如果
renderToUI本身耗时超过16ms，需拆成微任务分片，否则仍会丢帧
服务端合并消息比前端节流更治本
前端节流只是“扛住”，服务端合并才是“减负”。尤其当多条消息语义相关（如同一用户的连续状态变更），合并后传输量和解析开销都下降明显。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
- 典型场景：
{"type":"pos","x":100,"y":200}+{"type":"pos","x":101,"y":202}→ 合并为{"type":"pos-batch","data":[{"x":100,"y":200},{"x":101,"y":202}]} - 关键参数：
maxBatchSize（建议≤20）、maxDelayMs（建议≤50ms），避免小消息等太久 - 兼容性提醒：客户端必须识别
type === "pos-batch"并遍历data数组，不能假设每条onmessage只含一个业务实体 - 别让前端承担合并逻辑——服务端合并后，前端连
JSON.parse次数都少了，CPU占用直降30%+
缓冲区不设上限等于埋雷
很多人加了节流却忘了清缓冲区，网络抖动或服务端误推送时，buffer会无限膨胀，几分钟后内存飙到500MB+，页面直接崩溃。
- 必须设置硬限制：
if (buffer.length > 1000) buffer.shift()（FIFO）或buffer = buffer.slice(-1000)（保留最新） - Vue/React中用
ref或useState存buffer？危险。它们的setter是异步的，且触发依赖追踪，高频率调用反而加重负担。用普通let buffer = []最稳 - 监控手段：在
processBatch前后打点，记录buffer.length峰值，上线后通过performance.mark埋点观察趋势
节流和合并看似简单，但真正落地时，90%的问题出在缓冲区失控和渲染逻辑侵入onmessage。先砍掉这两处，卡顿基本消失；再考虑Web Worker或虚拟滚动这类进阶方案。
