websocket是大屏数据实时刷新的事实标准，需配置nginx超时、处理页面可见性、优化dom更新、规范数据格式与心跳机制以保障弱网等真实场景下的稳定可靠。
WebSocket 是大屏数据实时刷新最直接有效的方案，不是“可选”，而是当前技术条件下事实上的标准解法。轮询在高频率更新下必然导致延迟堆积和服务器负载失控，而 WebSocket 一次握手后保持长连接，服务端有数据就推、前端收到就更，毫秒级响应是常态。
WebSocket 连接失败或反复断开的常见原因
实际部署中，onerror 和 onclose 触发频繁，往往不是代码写错了，而是环境链路出了问题：
- Nginx 默认
proxy_read_timeout是 60 秒，WebSocket 空闲超时就会被静默断开；必须显式设为3600或更高，并配proxy_set_header Connection 'upgrade'和proxy_set_header Upgrade $http_upgrade - 浏览器标签页进入后台（如切换 tab 或最小化），Chrome/Firefox 会限制定时器和 WebSocket 心跳，导致服务端误判离线；需监听
document.visibilityState，页面隐藏时暂停发送心跳，显示时检查连接状态 - 移动端 WebView（尤其安卓旧版）对
wss://的 TLS 握手支持不稳定，建议服务端启用 TLS 1.2+ 且禁用不安全 cipher，前端 fallback 到ws://（仅限内网调试） - 未设置
WebSocket.CLOSE_NORMAL（代码 1000）主动关闭，而是让连接自然超时，服务端无法区分“用户离开”和“网络中断”，影响订阅清理逻辑
如何避免 DOM 频繁重绘拖慢大屏渲染
收到 onmessage 后直接调用 innerHTML 或触发全量 Vue/React 更新，是大屏卡顿的头号元凶。关键不是“要不要更新”，而是“只更新什么”：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 数字类指标（如
<div>CPU 使用率：<span id="cpu-value">0</span>%</div>）只操作document.getElementById('cpu-value').textContent = newData.cpu，绝不碰外层结构 - ECharts 图表更新必须用
chart.setOption({series: [{data: newData.series}]}, true)，第二个参数true启用增量渲染，否则每次重绘整个 canvas - 列表类数据（如告警流）按
id做 diff：缓存上一轮id数组，新数据来时只insertBefore新项、removeChild过期项，不重建 DOM 节点 - 所有 DOM 更新统一包裹
requestAnimationFrame，防止连续多条消息触发多次 layout
服务端推送的数据格式与客户端解析陷阱
看似简单的 JSON 消息，实际落地时最容易因协议不一致导致前端白屏或错乱：
- 服务端必须带时间戳字段，如
{"ts":1748350925123,"topic":"device_online","data":{"count":248}}；前端收到后先校验Date.now() - data.ts > 5000，超时则丢弃，避免网络抖动造成数据“倒流” - 不要用
JSON.stringify()直接塞二进制或 Buffer（如图片 base64），体积膨胀 33%，应改用ArrayBuffer+BinaryType = "arraybuffer"，前端用new Uint8Array(event.data)解析 - topic 订阅必须大小写敏感且严格匹配，
"cpu_usage"和"CPU_Usage"是两个 topic；前端取消订阅时，要确保发送的unsubscribe消息里 topic 字符串与当初subscribe完全一致 - 服务端推送空数据（如
{}或null）必须明确约定语义，否则前端JSON.parse()会抛错；建议统一用{"type":"heartbeat"}做心跳，业务数据必含type和data
真正难的从来不是连上 WebSocket，而是让连接在弱网、切页、服务重启、跨域代理等真实场景下持续可靠；数据来了不卡顿、不乱序、不重复，才是大屏能上线的关键门槛。
