生产环境 WebSocket 必须实现重连、消息校验与 DOM 更新节流：采用指数退避重连（1s→2s→4s→8s，上限30s），仅页面可见时重试，实时更新连接状态；消息缓存+requestAnimationFrame 批量更新 DOM，图表优先调用 .update()；严格校验 JSON 结构与字段类型，按 type 分发处理，丢弃时间偏差＞2秒的数据。
直接用 new WebSocket() 接入就行，但生产环境里不处理重连、消息校验和 DOM 更新节流，仪表盘很快会卡顿或断连后黑屏。
WebSocket 连接必须带重连和状态反馈
浏览器原生 WebSocket 对象不会自动重连，onclose 触发后连接就彻底断了。用户切标签页、网络抖动、服务端滚动升级都会导致断开，没重连逻辑的仪表盘会直接“失联”。
- 用指数退避策略：首次 1s 后重试，失败则 2s → 4s → 8s，上限建议设为 30s，避免密集重连打崩服务端
- 每次重连前检查
document.visibilityState === 'visible'，页面不可见时不重试，省资源 - 在 UI 上显示连接状态，比如用
<span id="ws-status">● connecting</span>，根据onopen/onerror/onclose动态更新文字和颜色 - 记录最近一次成功
onmessage的时间戳，连续 5 秒无新数据就主动发{"type":"ping"}检测是否假连
收到消息后别直接更新 DOM
onmessage 可能每秒触发几十次（比如股票盘口或机柜温度），如果每次都在回调里操作 innerText 或调用 Chart.update()，渲染线程会被频繁打断，页面掉帧甚至卡死。
- 把所有待更新的数据先缓存进一个对象，例如
pendingUpdates = { cpu: 42.3, memory: 68.1 } - 用
requestAnimationFrame批量合并更新，控制实际 DOM 操作频率 ≤ 30fps - 对图表类组件（如 Chart.js），优先调用
.update()而非.destroy()+new Chart()，避免重绘开销 - 数值型指标（如百分比、计数器）直接改
element.textContent，别用innerHTML，防 XSS 也更快
消息解析必须加防护，不能信服务端传来的任何字段
服务端推送的 JSON 如果缺字段、类型错、结构变，前端硬解会导致 Cannot read property 'xxx' of undefined，整个仪表盘渲染中断。
立即学习“前端免费学习笔记（深入）”；
- 用
JSON.parse(event.data)前，先判断typeof event.data === 'string'，再try/catch SyntaxError - 取值一律用空值合并操作符，例如
data.cpu ?? 0、data.timestamp ?? Date.now() - 按
type字段分发处理，不写if (data.cpu !== undefined)这种弱判断；服务端推{"type":"metric_update", "data":{...}}，前端只响应这个type - 对时间敏感场景（如趋势图横轴），用
data.timestamp和Date.now()算偏移，超过 2 秒偏差就丢弃该条，防服务端时钟漂移污染图表
真正难的不是连上 WebSocket，而是让连接在弱网、后台标签、服务重启等真实场景下持续有效，同时不让高频消息把 UI 线程拖垮。这两个点漏掉任何一个，仪表盘上线后就会反复出问题。
