直接渲染每条websocket消息会卡死浏览器，因为100条/秒远超60fps刷新节奏，持续触发重排重绘；应使用缓冲数组+requestanimationframe批量处理，解耦接收与渲染，并控制单次更新量。
为什么直接渲染每条WebSocket消息会卡死浏览器
因为每次 onmessage 触发后调用 setState 或直接操作 DOM，都会强制触发一次 Vue/React 的响应式更新或浏览器重排重绘。100 条/秒 ≈ 每 10ms 就来一条，远超浏览器 60fps（16.7ms/帧）的刷新节奏，主线程被持续抢占，UI 瞬间冻结。
用数组做缓冲池 + requestAnimationFrame 批量消费
核心是把“接收”和“渲染”解耦：消息只进不出，UI 只在浏览器空闲时统一取一批处理。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
-
joblistsCache是纯数据缓存，不绑定响应式（避免无意义依赖追踪） - 用
requestAnimationFrame替代setInterval：它天然对齐屏幕刷新，不会抢帧，且页面后台时自动暂停 - 每次只取最新
N条（比如 50），用splice(-N)截取，丢弃旧数据——不是为了省内存，而是控住 UI 渲染量 - 清空缓存前先
unshift(...)或push(...)合并，再一次性赋值给响应式数组（如this.joblists = [...]），避免多次触发更新
mounted() {
this.ws.onmessage = (e) => {
const data = JSON.parse(e.data);
this.joblistsCache.push(data); // 不触发响应
};
<p>const renderFrame = () => {
if (this.joblistsCache.length > 0) {
const batch = this.joblistsCache.splice(-50); // 取最后50条
this.joblists.unshift(...batch); // 一次性更新
if (this.joblists.length > 200) {
this.joblists.splice(0, this.joblists.length - 200); // 保最新200
}
}
requestAnimationFrame(renderFrame);
};
requestAnimationFrame(renderFrame);
}</p>
缓冲池大小和截取策略怎么选
不是越大越好，也不是越小越稳——关键看业务容忍度和 UI 节奏。
- 若展示的是实时行情或日志流，用户只关心最新几秒，
bufferSize = 100+keepLatest = 50更合理 - 若需回溯分析（如工单状态变更链），就得保留完整序列，此时缓冲池要配合分页或虚拟滚动，不能硬塞进 table
- 避免用
shift()或unshift()频繁操作大数组：V8 对长数组头部插入是 O(n) 复杂度，改用push()+ 倒序取slice(-N) - 如果后端推送的是聚合快照（比如每 500ms 推一次全量），那根本不需要缓冲池，直接替换即可
容易被忽略的内存泄漏点
缓冲池本身会吃内存，但更危险的是没断开的引用链。
- WebSocket 实例未在
beforeUnmount/componentWillUnmount中调用ws.close()，缓存数组持续增长，GC 无法回收 - 在
onmessage回调里用了闭包引用组件实例（比如this.xxx），即使组件卸载，回调仍存活，导致整个实例驻留 - 用
setTimeout或setInterval做定时消费时，没存 timer ID 或没清除，定时器持续触发并访问已销毁组件 - Vue 3 的
ref或reactive包裹了大数组，响应式系统会深度监听每个元素，加剧性能负担——缓冲池建议用普通数组，仅最终渲染时才转成响应式
