WebSocket 推送增量数据，Canvas 增量绘制：需解析 delta、维护本地缓存、校验时间戳、防抖合并；分层 Canvas + 脏矩形更新；帧流直传用 ArrayBuffer + 正确 MIME + 及时释放 URL；rAF 不替代逻辑优化，须前置计算并处理状态漂移对账。
直接上结论：websocket 负责把变化的数据“推”过来，canvas 负责把变化的部分“画”出来——关键不在全量重绘，而在识别“哪里变了”和“怎么画得快”。
WebSocket 收到数据后别急着 render()
常见错误是 ws.onmessage 一触发就调用完整重绘函数，导致 CPU 暴涨、帧率骤降。真实大屏里，90% 的数据没变，你却在每秒重画全部。
- 必须做增量解析：服务端发来的数据应含
type: "delta"字段，且changes数组只列 ID 和新值（如{"id": "temp-01", "value": 36.2}） - 前端需维护一份本地缓存
const cache = new Map()，每次仅更新对应 key，不碰其他项 - 校验时间戳：丢弃
timestamp比本地缓存旧的数据，避免倒退渲染（尤其在 WebSocket 重连后乱序到达时） - 防抖合并：若 50ms 内收到多条 delta，用
setTimeout合并处理，避免高频触发绘制
Canvas 层级拆分与脏矩形更新
单 Canvas 全量清空再重画，是实时大屏卡顿的头号原因。必须分层 + 局部擦除。
- 至少分两层：
staticCanvas（背景、标题、坐标轴等静态内容，只初始化一次）和dynamicCanvas（数值块、进度条、折线图点阵） - 每个可更新元素需记录自身边界：
{ id: "cpu-usage", x: 120, y: 80, width: 200, height: 40 } - 更新时调用
ctx.clearRect(x, y, width, height)，再仅重绘该区域内容，而非ctx.clearRect(0, 0, canvas.width, canvas.height) - 注意：若元素有阴影、渐变或透明叠加，需扩大脏区范围（+4px 左右），否则边缘会残留残影
图片帧流直传 Canvas 的避坑要点
当大屏要显示摄像头/热力图/截图流时，别用 Base64，也别走 img.src = dataURL，那是内存和性能杀手。
- 服务端必须设
binary: true发送原始Buffer，客户端监听前先设ws.binaryType = 'arraybuffer' - 接收后立刻判断
event.data instanceof ArrayBuffer，不是Blob或字符串 - 构造 Blob 时 MIME 类型必须匹配实际数据：JPEG 用
'image/jpeg'，PNG 用'image/png'，错一个字符就会加载失败 -
URL.createObjectURL(blob)后，务必在img.onload里执行ctx.drawImage(img, ...)，并在绘制完成后立即调用URL.revokeObjectURL(url)—— 高频更新下漏掉这句，内存几秒飙到 1GB+ - 连续帧场景（如 25fps 视频流）：服务端应在每帧前加 4 字节长度头（
Uint32Array），客户端用Uint8Array手动切片，否则粘包会导致图像错位或崩溃
requestAnimationFrame 不是万能解药
很多人以为套一层 requestAnimationFrame 就能“自动优化”，其实它只控制调用时机，不解决逻辑开销。
- 真正耗时的操作（如路径重计算、文本测量、像素遍历）必须前置剥离：例如折线图的点集缩放，应在数据进入缓存时完成，而非每帧重复算
- 动画插值（如温度从 20℃→35℃）必须用线性插值公式算中间值，而不是靠
setTimeout模拟，否则帧率波动时跳变明显 - 若某次 delta 处理耗时 >16ms（即一帧时间），
requestAnimationFrame会丢帧，此时应降级：跳过插值，直接显示目标值，并记日志告警 - 移动端 Safari 对
requestAnimationFrame调度更保守，建议加兜底：检测performance.now()间隔，超 30ms 强制触发一次
最易被忽略的是“状态漂移”——WebSocket 断线重连后，服务端可能补发积压 delta，但前端缓存已滞后，此时若不做全量校验同步（比如定期 fetch 一次 snapshot），几个小时后数值就和真实系统对不上了。这不是性能问题，是数据一致性问题，得单独设计心跳对账机制。
