canvas无绑定机制，所有渲染必须手动触发，性能瓶颈在于绘制效率而非响应式同步；应避免频繁全量重绘，善用脏矩形、offscreencanvas、drawimage合批及资源预加载优化。
Canvas 本身不支持“绑定”——所谓“绑定性能”问题，本质是开发者误把 Canvas 当成 Vue/React 那类响应式 UI 框架的视图层来用。 它没有 data → view 的自动同步机制，也就不存在“绑定开销”或“改善绑定效果”的说法。所有渲染都得手动触发，性能瓶颈只出在你画得是否高效、是否重复绘制、是否绕过浏览器合成器上。
Canvas 渲染完全手动，没有 setData 或 reactivity
Canvas 是命令式绘图 API，getContext('2d') 返回的上下文对象不会监听任何 JS 对象变化。你改了 player.x，Canvas 不会自动重绘；必须显式调用 clearRect() + fillRect() 或其他绘图方法。
常见错误现象：
- 在 Vue
watch或 ReactuseEffect里频繁调用draw()，却没做节流或脏矩形判断，导致每帧重绘全画布 - 把 Canvas 当成
<div> 用，给每个小元素套一层“状态对象”，再遍历更新——这比 DOM 还慢 <p>实操建议：</p> <ul> <li>只在真正需要重绘时调用 <code>requestAnimationFrame，不要用setInterval或事件直触draw() - 用
canvas.width = canvas.width清屏比clearRect(0,0,w,h)更快（但会重置所有上下文状态） - 避免在绘制循环中反复读取
getComputedStyle、offsetWidth等触发回流的属性
高频重绘场景下，用 offscreenCanvas 或 web worker 分离计算
当逻辑复杂（如粒子系统、物理模拟），JS 计算拖慢帧率时，“绑定”不是问题，CPU 计算是瓶颈。此时 Canvas 自身仍只是绘图终点，但可借助现代 API 把耗时部分移出主线程。
使用场景：
- 游戏主循环中每帧需处理上千对象位置/碰撞
- 图表库需实时聚合、插值、生成路径点
实操建议：
- Chrome/Firefox 支持
OffscreenCanvas：用transferControlToOffscreen()将 canvas 移入 worker，在 worker 里调用getContext('2d')绘制，再commit()回主线程 - 若需兼容 Safari，改用普通
Worker做纯数据计算（如返回 {x,y,r} 数组），主线程仅负责把结果批量画到 canvas 上 - 避免在 worker 中频繁 transfer 大量图像数据；优先 transfer
ArrayBuffer或 typed array
用 drawImage 合批图元，别用多个 fillRect 模拟精灵
很多人以为“Canvas 快是因为原生”，其实慢操作一样存在：每调用一次 fillRect、arc 或 stroke，都是一次独立绘图指令提交，浏览器需做状态校验、抗锯齿计算、alpha 混合等。大量小图形逐个画，性能远不如一张贴图切片后批量 drawImage。
参数差异：
-
fillRect(x,y,w,h)：适合动态尺寸、无纹理的 UI 元素（如进度条背景） -
drawImage(img,sx,sy,sw,sh,dx,dy,dw,dh)：适合固定外观的图元（角色、图标、按钮），尤其配合 sprite sheet 使用
性能影响：
- 100 个
fillRect调用 ≈ 3–5ms；100 次drawImage（同源图）≈ 0.8–1.2ms（Chrome，含纹理上传优化） - 若
img是HTMLImageElement，首次绘制会有解码延迟；预加载并转为ImageBitmap可消除该延迟
最容易被忽略的一点：Canvas 的“高性能”永远依赖你主动管理绘制节奏和资源粒度。它不帮你做 diff、不缓存旧帧、不自动跳过未变化区域——这些都得你写代码决定。哪怕只画一个随鼠标移动的圆，也得自己判断是否真需要重绘，而不是每次 mousemove 都清屏重画。
