WebSocket消息需节流而非简单缓冲，应在onmessage中用requestIdleCallback批量更新、时间窗口节流或丢弃旧日志，并将复杂处理移至Web Worker，同时配合服务端序列号保障有序消费。
WebSocket 消息到达后直接触发 DOM 更新，容易造成高频重绘卡顿。关键不是“要不要缓冲”，而是“在哪个环节、用什么方式缓存更可控”。
消息接收端需主动节流，而非依赖队列中转
前端本身不内置消息队列，所谓“缓冲处理”，本质是客户端对 onmessage 的消费节奏做干预。后端推来的每条消息若都立刻 setState 或 innerHTML，UI 线程必然过载。
- 用 requestIdleCallback 延迟执行渲染：把多条消息暂存数组，空闲时批量更新视图
- 设置固定时间窗口（如 100ms）做 节流（throttle）：窗口内只取最后一条或合并为摘要
- 对日志类、监控类低优先级消息，可直接丢弃旧条目，只保留最新 N 条用于展示
避免在 onmessage 内做同步耗时操作
解析 JSON、格式化时间、计算状态等逻辑若写在 onmessage 回调里，会阻塞后续消息接收和 UI 响应。
- 复杂处理移入 Web Worker：尤其涉及大量字符串匹配或结构转换时
- 简单校验用 try/catch 包裹，防止某条非法数据导致整个监听中断
- 不直接操作 DOM，改用轻量状态对象（如 { type: 'update', data: ... }），交由统一渲染层调度
连接层要配合状态管理，防止消息堆积失序
网络抖动或页面切后台时，WebSocket 可能断连重连。若没控制好，重连后可能收到重复或乱序消息，缓冲就失去意义。
立即学习“前端免费学习笔记（深入）”；
- 启用服务端消息序列号（seq）或时间戳，前端按序消费，跳过已处理项
- 连接关闭期间暂存待发消息（如用户输入），但接收缓冲区建议清空，避免旧数据干扰新会话
- 用 readyState === WebSocket.OPEN 做发送守门员，非 OPEN 状态下暂存或丢弃非关键消息
不复杂但容易忽略：缓冲不是堆数据，而是控节奏。重点在收得稳、判得清、画得少。
