Canvas渲染嵌入浏览器图形管线，不参与DOM流程但依赖光栅化、合成与GPU调度；其2D渲染分四阶段执行，性能瓶颈多在CPU端，需通过批量合并、空间裁剪、分层缓存和线程卸载优化。
Canvas图形渲染不是“画完就完”，而是嵌入在浏览器整套图形管线中的一环。它不走DOM流程，但依赖底层光栅化、合成与GPU调度——理解这条流水线，才能真正掌控性能。
Canvas不参与DOM渲染链
Canvas元素本身是DOM节点，但一旦获取2D上下文，所有绘图操作就脱离了CSS盒模型和布局计算。浏览器不会为每个fillRect重新计算样式、触发重排（reflow）或重绘（repaint）。它直接把指令交给Skia等图形库，在CPU或GPU缓冲区生成像素数据，再提交纹理给合成器。这意味着：DOM变动不影响Canvas内容，Canvas内容也不会影响DOM树结构。
2D渲染的四阶段执行路径
每次调用ctx.fillRect()等API，实际触发以下隐式流程：
- JavaScript层记录绘图命令，并更新当前渲染状态（如
fillStyle、剪辑区域） - 底层图形库（如Chromium的Skia）将矢量指令转为光栅化任务；若启用硬件加速，该步骤常在GPU进程完成
- 绘制结果写入帧缓冲或纹理对象，等待合成线程调度
- 合成器将Canvas纹理与其他图层（如HTML元素、视频）按z-index和透明度混合，最终提交给GPU显示
性能瓶颈多发生在CPU端而非GPU
Canvas 2D的常见卡顿，往往不是显卡不够快，而是CPU被拖慢：
- 每帧数千次
beginPath()和fill()调用，引发大量状态切换与内存拷贝 - 未做空间索引的全量遍历判断（比如每帧检查10万点是否在视口内）
- 反复读写
ctx.globalAlpha或ctx.shadowColor等属性，触发内部状态重建 - 主线程同时处理逻辑计算+绘图+事件响应，缺乏分流
优化必须匹配流水线环节
高效Canvas不靠“写得更巧”，而靠“分得更准”：
- 批量合并：按颜色、线型分组绘制，减少
fillStyle设置次数 - 空间裁剪：用网格哈希或四叉树，让每帧只处理视口内0.5%的对象
- 分层缓存：静态背景→离屏Canvas→
drawImage贴图；动态元素单独层更新 - 线程卸载：坐标投影、粒子轨迹等纯计算，移至Web Worker + OffscreenCanvas
