onmessage里直接更新state会卡顿，因高频消息频繁触发框架响应式更新与dom渲染，应使用throttle节流（30–60ms）、requestanimationframe、缓冲插值或store聚合更新来优化。
onmessage里直接更新state为什么卡
因为 onmessage 是事件回调，每条消息都触发一次，高频时（比如 50Hz 传感器数据）会密集调用 setState 或 store.commit，造成 React/Vue 的响应式系统反复触发 diff 和渲染，主线程被压满，UI 就“看起来慢”甚至卡死。
这不是 WebSocket 慢，是 UI 更新逻辑没做节制。真实瓶颈在 DOM 渲染和框架响应层，不是网络或连接本身。
- 别在
onmessage回调里直接写this.count++或store.dispatch('update', data) - 避免在回调中执行耗时操作：JSON 解析、深拷贝、复杂计算、同步 DOM 插入
- Vue 2 中频繁
vm.$set、React 中无 key 的数组 map，都会放大重绘开销
高频状态流该用 throttle 而不是 debounce
比如协作光标、播放进度、滚动位置、实时电平 —— 这类数据强调「连续性」和「节奏感」，你不需要最终值，而是要稳定采样频率。用 debounce 会丢掉中间所有状态，只剩最后一条；throttle 才能保节奏。
- 推荐节流周期：30–60ms（≈16–33fps），匹配主流屏幕刷新率
- 用
requestAnimationFrame包裹节流逻辑，比定时器更顺滑：rafThrottle(handleUIUpdate) - 注意节流函数必须是同一个引用，否则每次新建会重置内部计时器
消息带时间戳就别节流，改用缓冲队列 + 插值
当消息含 timestamp 字段（如 WebRTC 音频电平、游戏帧同步包），说明服务端按固定时钟发包。这时节流/防抖会破坏时间语义，应保留原始消息流，靠客户端插值还原连续体验。
- 维护一个时间窗口缓冲区（如最近 200ms 的消息），按
timestamp排序 - 在
requestAnimationFrame中取最新有效消息 + 上一条，线性插值计算当前帧值 - 丢弃超时旧消息（例如
now - msg.timestamp > 500），防止延迟累积
Pinia/Vuex 里聚合更新比组件内分散更新更稳
多个组件监听同一类消息（比如 CHART_DATA_UPDATE），如果各自解析、各自更新，容易出现竞态、重复渲染、状态不一致。统一收口到 store 模块里做聚合处理，能控节奏、去重、加校验。
- 在 store 的 action 里做消息分类：
if (payload.type === 'CHART_POINT') { state.points.push(payload.data) } - 用
nextTick或setTimeout(..., 0)延迟批量提交，合并多次小更新 - 对高频点位数据，可限制 buffer 长度（如只存最近 1000 条），避免内存暴涨
真正卡住的往往不是 WebSocket 本身，而是你把「接收」和「呈现」混在了一起。消息进来就得立刻画，就像快递员进门就催你当场拆包裹——其实你可以先堆在玄关，等手头活儿告一段落，再按优先级一批批拆。
