核心是“服务端推数据+前端高效重绘”，即通过websocket代理解决跨域鉴权问题，再依托canvas分层绘制、脏矩形更新和requestanimationframe驱动实现局部、稳定、低延迟渲染。
WebSocket代理加Canvas动态看板，核心是“服务端推数据 + 前端高效重绘”。不走轮询，不刷整页，数据一来立刻更新局部图表或状态块。
WebSocket代理：把后端推送转成前端可连的通道
很多生产环境不允许前端直连业务WebSocket服务（跨域、鉴权、Nginx不支持ws升级等），这时需要一层代理。常见做法是用Nginx反向代理WebSocket：
- 确保Nginx配置含
proxy_http_version 1.1和Upgrade $http_upgrade头，否则连接会降级为HTTP - 代理路径建议统一，比如
/ws/realtime→ 转发到http://backend:8080/ws - 若用Node.js做中间代理（如
ws+http-proxy-middleware），需手动透传Connection和Upgrade头，并处理心跳保活
Canvas渲染：按需清空+增量绘制，避免全屏重绘卡顿
Canvas不是DOM，不能靠框架diff，必须自己控制绘制节奏。关键在“分层”和“脏矩形”：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 把看板拆成多个
<canvas></canvas>：趋势图一个、设备状态网格一个、告警列表一个——互不干扰，更新某模块只重绘对应canvas - 对高频更新区域（如实时折线），用
ctx.clearRect()只清空上一帧画布区域，再重绘新点；避免ctx.clearRect(0,0,canvas.width,canvas.height)全清 - 文字类内容（如数值标签）优先用
ctx.fillText()而非创建DOM元素，减少渲染管线切换开销
数据映射与节流：防止Canvas被撑爆或抖动
后端推送频率可能远高于Canvas刷新能力（如每100ms推一次，但屏幕仅60FPS），必须做客户端适配：
- 用
requestAnimationFrame驱动绘制循环，而不是收到消息就立刻draw——保证稳定60fps - 对时间序列数据，前端缓存最近N条点（如200个），超出时丢弃最老点；用
ArrayBuffer或TypedArray存坐标，提升计算效率 - 数值突变（如传感器跳变）加简单滤波：只接受与上一值偏差
连接健壮性：断线自动恢复 + 状态同步
看板不能因网络抖动白屏或错乱：
- WebSocket关闭时启动指数退避重连（1s→2s→4s…上限30s），同时显示“重连中…”提示
- 首次连接成功后，主动发
{type:"sync", timestamp:Date.now()}请求快照数据，避免只收增量导致初始状态缺失 - Canvas绘制前检查
canvas.width > 0，防止容器未渲染完成就绘图导致空白——可用ResizeObserver监听尺寸变化再触发重绘
