WebSocket广播时客户端CPU飙升主因是前端处理逻辑未收敛：应避免高频JSON解析与DOM直写，改用二进制解析、requestAnimationFrame批量更新、合成层优化；按需解码、静默丢弃过期消息；用Web Worker分离计算任务；限制本地状态规模并及时释放内存。
WebSocket大规模广播时，客户端CPU飙升往往不是因为“收消息”本身，而是前端处理逻辑没做收敛——比如每秒收到上千条弹幕还逐条解析、渲染、重排布局。关键不在压测连接数，而在控制单次处理的计算量和内存扰动。
避免高频JSON解析与DOM直写
服务端推送的每条消息若都走 JSON.parse() + document.createElement + appendChild，浏览器会频繁触发样式计算、布局重排和垃圾回收。尤其在低端设备上，100条/秒的弹幕就可能让帧率跌破30fps。
- 对结构固定的小消息（如
{u:123,a:2,t:1712345678}），改用Uint8Array或DataView手动解析二进制帧，跳过JSON解析开销 - 弹幕、点赞等高频UI更新，不直接操作DOM，改用
requestAnimationFrame聚合批量更新，或用DocumentFragment一次性插入 - 启用
will-change: transform提升弹幕容器为独立合成层，避免每次位移触发全页面重绘
按需解码，静默丢弃过期消息
网络抖动或弱网下，消息堆积是常态。客户端若照单全收，CPU会在解码、过滤、排序上空转——而用户根本看不到3秒前的弹幕。
- 服务端在消息中嵌入单调递增的
seq或毫秒级ts，客户端维护本地最新接收序号 - 收到消息先比对时间戳：若
now - ts > 5000，直接return不进队列 - 对同类型连续消息（如连击反馈），启用客户端合并逻辑：100ms窗口内只保留最后一条，其余丢弃
分离渲染与逻辑线程
主线程既要响应用户操作，又要处理广播消息，容易互相阻塞。把耗时计算移出主线程，能稳住交互流畅度。
立即学习“前端免费学习笔记（深入）”；
- 用
Web Worker处理消息解密、格式转换、排行榜排序等纯计算任务，主线程只负责最终结果渲染 - Worker间通过
Transferable（如ArrayBuffer）零拷贝传递数据，避免结构化克隆开销 - 对需Canvas绘制的场景（如实时位置轨迹），启用
OffscreenCanvas，让Worker直接绘图并提交到主线程Canvas上下文
限制本地状态规模，及时释放内存
客户端缓存历史消息、用户状态、未读计数等数据，若无清理机制，会持续增长，引发GC风暴，表现为CPU周期性尖峰。
- 对聊天记录等滚动列表，只保最近200条，超出部分从DOM和内存中
remove()+delete - 用
WeakMap存储与DOM节点绑定的临时状态，节点被移除后自动回收 - 监听
visibilitychange事件：页面切到后台时暂停消息处理、清空待渲染队列，恢复前台再续传
