canvas性能优化核心在于重构渲染流水线：按样式分组批量绘制、用空间索引加速可见性判定、动静内容分层+离屏缓存、计算任务移至web worker。
Canvas性能瓶颈往往不是出在“画得不够快”，而是出在“画得太碎”——万级图形逐个调用fill()、反复切换颜色和路径、每帧遍历全部对象判断是否可见，这些操作把CPU拖进低效循环。真正有效的优化，得从渲染流水线本身切入，而不是零散地“减少draw调用”。
批量合并绘制，压减上下文开销
Canvas 2D上下文每次设置fillStyle、调用beginPath()或fill()都有固定开销。5000个圆点若各自设色+绘图，等于执行5000次状态切换。
- 按样式（颜色、透明度、线宽）对图形分组，每组只设一次
ctx.fillStyle、一次ctx.globalAlpha - 同组内复用路径：
ctx.beginPath()→ 循环ctx.arc()→ctx.fill()，避免循环中反复调用beginPath() - 避免在绘制循环里读写
ctx属性，改用预计算后的统一赋值
空间索引加速可见性判定
即使加了脏矩形，每帧仍需遍历全部对象判断是否在视口内——这是典型的O(N) CPU热点。
- 引入网格哈希（Grid Hash）或四叉树，将坐标映射到二维桶中
- 渲染前只查与当前视口相交的几个桶，候选对象通常不足总数的5%
- 动态对象移动时主动更新其桶位置，不重建整棵树
分层 + 离屏缓存，隔离动静内容
背景、UI、地图格子等长期不变的内容，每帧重绘纯属浪费。
- 用多个
<canvas></canvas>元素分层：background-canvas、game-canvas、ui-canvas - 静态层先绘制到
OffscreenCanvas，主线程用drawImage()一次性合成 - 若某层内容完全静止，可转为
ImageBitmap，跳过像素拷贝
计算任务移出主线程
粒子轨迹、坐标投影、缩放后位置映射等纯数学运算，不该卡住渲染和交互。
- 用Web Worker处理顶点计算、路径变形等任务
- 主线程通过
OffscreenCanvas.transferControlToOffscreen()传句柄给Worker - Worker完成绘制后，主线程直接合成，避开
getImageData/putImageData的内存复制
不复杂但容易忽略
