Canvas性能瓶颈源于不当调用：频繁状态切换（如fillStyle）、重复API调用（fillRect）触发GPU低效路径；优化需视口裁剪、空间索引、离屏预渲染、像素级操作及分层绘制。
Canvas 本身不“绑定性能”，但它的使用方式会直接决定性能表现——不是 Canvas 限制了你，是你调用 ctx 的方式触发了浏览器底层的低效路径。
为什么 canvas.getContext("2d") 默认很慢？
默认创建的 2D 上下文会启用 GPU 加速，但这个加速只在「整块纹理上传」时高效；一旦你频繁改 ctx.fillStyle、ctx.strokeStyle、ctx.font 或反复调用 fillRect()，就会导致大量 GPU 状态切换，每次切换都可能带来微秒级延迟，在循环里叠加就卡顿明显。
- 每调用一次
fillRect(x, y, w, h)，浏览器都要准备一次绘制命令并提交给 GPU - 如果画 1000 个不同颜色的小方块，就是 1000 次状态切换 + 1000 次提交
-
willReadFrequently: true不是“开启高性能”，而是“告诉浏览器：我要读/写像素，别走 GPU 路线”
预渲染到离屏 canvas 真的有用吗？
有用，但只对「静态或半静态内容」有效。比如地图图块、UI 图标、文字贴图——这些内容画一次就能复用多次。
- 离屏 canvas 必须尺寸精准：太大浪费内存和复制时间，太小会缩放失真
- 用
ctx.drawImage(offscreenCanvas, x, y)复制比逐个fillRect快 5–10 倍（实测 1000+ 元素场景） - 注意：离屏 canvas 不能响应事件，点击判定仍需你自己做坐标映射
直接操作像素数据（Uint32Array）适合什么场景？
适合规则网格、灰度/索引色、无抗锯齿需求的大面积填充，比如地形图、像素艺术、实时滤镜。
立即学习“前端免费学习笔记（深入）”；
- 必须搭配
getContext("2d", {willReadFrequently: true})，否则getImageData极慢 -
new Uint32Array(imgData.data.buffer)让你按 32 位整数写像素，比逐字节操作快一个数量级 - 不能用
shadowColor、globalAlpha等合成效果——这些在像素层已失效 - 写完必须调用
putImageData(imgData, 0, 0)，漏掉这句就白干
requestAnimationFrame 里 clearRect 和 beginPath 哪个更重要？
clearRect 是清像素，beginPath 是清路径栈——两者解决的问题完全不同，漏掉任一个都会出 bug。
- 漏
clearRect→ 旧帧残留（视觉拖影） - 漏
beginPath→ 新路径自动连上旧路径终点，画出意外折线或闭合多边形 - 动画循环中建议顺序：
clearRect→save()→ 绘图 →restore()→beginPath()（路径类操作前）
真正卡住 Canvas 的，往往不是“画得不够快”，而是“画得太多余”：重复设置相同样式、在循环里创建临时对象、用 measureText 实时算宽高、或者把整个世界都塞进一个 canvas 里滚动。拆分图层、固化静态内容、用像素数组代替路径——这些不是高级技巧，而是绕过默认低效路径的必要绕行。
