Canvas 渲染与响应式数据绑定天然不兼容，因其为命令式 API、无 DOM 节点、不参与框架响应式链路；需通过 shouldRender 标志+requestAnimationFrame 节制重绘，结合离屏缓存和 Web Worker 优化性能。
Canvas 渲染和响应式数据绑定天然不兼容
Canvas 是纯命令式绘图 API，没有 DOM 节点、不参与 Vue/React 的响应式更新链路，直接修改 ref 或 state 不会触发 Canvas 重绘。常见错误是：在 watch 里调用 ctx.clearRect() + draw()，但漏掉防抖、节流或绘制条件判断，导致高频重绘卡顿甚至丢帧。
典型现象：console.log 看到数据频繁变化，Canvas 却闪烁、延迟、CPU 暴涨；或用 requestAnimationFrame 包裹绘制后仍卡顿——本质是绑定层（如 Vue 的 computed）反复触发，而 Canvas 绘制没做节制。
- Vue 用户别在
watch里无条件调用render()，加immediate: false和deep: false（除非真要监听嵌套对象） - React 用户避免在
useEffect依赖数组中放未 memo 化的对象/数组，否则每次渲染都触发 Canvas 重绘 - 所有框架下，
ctx.drawImage()或路径绘制前，先用if判断是否真有变化（比如坐标差 > 1px、颜色值不同）
用 requestAnimationFrame 控制 Canvas 绘制节奏
Canvas 绘制必须与屏幕刷新率对齐，硬绑在数据变更上等于把 60fps 强行拉到 100+fps（尤其鼠标移动时），反而触发浏览器强制同步布局（Layout Thrashing）。正确做法是让数据变更「通知」绘制，而不是「驱动」绘制。
示例逻辑（Vue 3 setup）：
立即学习“前端免费学习笔记（深入）”；
const shouldRender = ref(false);
watch(data, () => { shouldRender.value = true; }, { flush: 'post' });
onMounted(() => {
const renderLoop = () => {
if (shouldRender.value) {
ctx.clearRect(0, 0, canvas.width, canvas.height);
draw(ctx, data.value); // 实际绘图函数
shouldRender.value = false;
}
requestAnimationFrame(renderLoop);
};
requestAnimationFrame(renderLoop);
});
- 用
ref标记「需重绘」比直接调用draw()更轻量 -
flush: 'post'确保 watch 在 DOM 更新后执行，避免竞态 - 不要在
renderLoop里读取未缓存的响应式对象（如data.x），应提前解构或用toRefs
离屏 Canvas 缓存静态内容，减少重复计算
当 Canvas 中部分元素不变（如背景网格、UI 边框），每次都重绘整个画布是性能黑洞。用离屏 <canvas> 提前画好静态层，主 Canvas 只负责动态内容，drawImage() 复制即可。
关键点：
- 创建离屏 Canvas：
const offscreen = document.createElement('canvas')，尺寸设为最终显示大小 - 只在静态数据变更时重绘离屏 Canvas（比如用户切换主题色），不是每帧都刷
- 主 Canvas 绘制时，先
ctx.drawImage(offscreen, 0, 0)，再叠加动态元素 - 注意：离屏 Canvas 的
ctx不支持filter或shadow等部分 CSS 效果，需在主 Canvas 上补
Web Worker 处理复杂计算，但不能直接操作 Canvas
Canvas 的 ctx 对象无法跨线程传递，Worker 只能处理纯数据（如粒子位置、路径点集、图像像素矩阵），再通过 postMessage 把结果传回主线程绘制。
适用场景：
- 大量点坐标实时物理模拟（>1000 个粒子）
- 图像滤镜（
getImageData→ Worker 计算 →putImageData） - 分形、地图瓦片生成等 CPU 密集型预计算
避坑重点：Transferable 对象（如 ArrayBuffer）可零拷贝传递，但 ImageData 需手动提取 .data 字段；Worker 中不能访问 document 或 canvas，所有绘图逻辑必须留在主线程。
真正难的不是“怎么用 Web Worker”，而是判断哪些计算值得搬出去——多数 UI 动画（拖拽、缩放、简单路径）根本不需要，加了反而因通信开销更慢。
