离屏画布核心在于合理分层、精准更新与设备像素比匹配，适合缓存长期不变且重绘开销远高于drawimage的内容，如静态ui层、重复图元和固定贴图；创建时须显式设置width/height并适配dpr，避免css缩放与高频todataurl调用；分层建议3–5个逻辑层，配合脏矩形更新与内存监控兜底。
离屏画布不是“画两次”，而是把该缓存的画一次、该复用的贴无数次。真正起效的关键，在于分层是否合理、更新是否精准、尺寸是否匹配设备像素比。
哪些内容适合放进离屏画布
核心判断标准就两条：内容长期不变 + 每次重绘开销远高于 drawImage。比如一个带多重阴影、径向渐变和抗锯齿文字的按钮模板，每帧重绘要调 15 次 2D API；而预绘制到离屏 Canvas 后，主画布只需 1 次 drawImage，性能提升立竿见影。
- 静态 UI 层：HUD 控件、地图边框、固定标题栏
- 重复图元：上百个相同图标、统一风格的节点、网格背景线
- 缩放/旋转频繁但内容固定的贴图：齿轮图标、瓦片底图、矢量装饰元素
- 伪静态要警惕：表面静止但含微渐变、噪点动画或时间戳的文字，仍需每帧重绘，缓存无效
离屏画布怎么建才不踩坑
创建离屏 Canvas 最常见的错误是忽略显式尺寸和高 DPI 适配。Canvas 元素必须设置 width/height 像素值，不能靠 CSS 缩放，否则 getContext('2d') 返回 null 或渲染错位。
- 优先用 document.createElement('canvas') 创建，兼容性更好；new OffscreenCanvas() 在旧版 Safari 中不可用
- 若主画布已按 window.devicePixelRatio 缩放（如 2x），离屏 Canvas 的 width/height 也必须设为 clientWidth × devicePixelRatio
- 避免在调试中高频调用 toDataURL()——它强制光栅化+内存拷贝，反而引发卡顿
分层与更新策略决定实际收益
把整屏塞进一个离屏 Canvas 是典型低效做法。应按更新频率拆成 3–5 个逻辑层：background（几乎不动）、static-ui（主题切换才变）、dynamic-ui（用户操作局部刷新）、effects（粒子/拖影等每帧变）。
- 每层独立生命周期：背景层建一次用到底；图标层在资源加载完成时批量绘制；动态层只保留在主 Canvas 渲染
- 更新只发生在必要时刻：监听主题色变更、精灵图 onload、缩放比例跳变超过阈值（如 1.0→1.8）
- 用脏矩形机制替代全层清空：记录变动区域坐标，clearRect 精确擦除再重绘，避免无谓像素填充
性能兜底与资源管理
离屏渲染本质是用内存换时间，但失控的内存占用会反噬性能。需主动干预底层行为并监控资源水位。
- 创建上下文时传入优化选项：getContext('2d', { willReadFrequently: false })，禁用不必要的像素读取能力
- 对图标、线条类图形关闭平滑：ctx.imageSmoothingEnabled = false
- 估算内存：定期用 offscreen.toDataURL().length 判断单个离屏 Canvas 占用，总量超 20MB 触发 LRU 清理
- 长期不用的离屏 Canvas 主动释放引用，促 GC 回收
