是否该用OffscreenCanvas取决于内容是否长期不变且绘制开销明显高于drawImage；适用静态UI、重复图元等，不适用于每帧变化的内容。
离屏渲染不是加个 OffscreenCanvas 就能自动变快的，关键在“缓存是否真被复用”和“更新是否真被跳过”。盲目创建离屏画布反而增加内存压力，甚至拖慢首帧。
怎么判断该不该用 OffscreenCanvas
核心看两点：内容是否长期不变、绘制开销是否明显高于 drawImage 调用。比如一个带阴影+渐变+文字的按钮模板，每帧都重绘要调用 12+ 次 2D API；而预画到离屏 Canvas 后，每帧只需 1 次 drawImage，这就是典型适用场景。
- 适合：静态 UI 层（HUD、地图边框）、重复图元（上百个相同图标）、缩放/旋转频繁但内容固定的贴图（如齿轮、瓦片底图）
- 不适合：每帧都变的粒子系统、实时摄像头流、文字内容随用户输入高频刷新的编辑器
- 警惕伪静态：比如“背景”实际随时间有微弱渐变或噪点动画——这种仍需每帧重绘离屏 Canvas，收益归零
OffscreenCanvas 创建与尺寸设置的坑
OffscreenCanvas 实例必须显式设置宽高像素值，不能靠 CSS 缩放，也不能留空。否则 getContext('2d') 返回 null 或绘制区域异常。
- 高 DPI 设备下必须同步缩放：若主 Canvas 用
window.devicePixelRatio做了 2x 渲染，离屏 Canvas 的width/height也得设为canvas.clientWidth * devicePixelRatio - 用
document.createElement('canvas')创建更兼容，new OffscreenCanvas()在 Safari 16.6 之前不支持，且无法在主线程直接获取transferControlToOffscreen()句柄 - 避免用
canvas.toDataURL()频繁调试——它会强制光栅化并拷贝像素，反而触发性能抖动
离屏内容更新时机决定优化成败
很多卡顿其实来自“每次重绘都重建离屏 Canvas”，等于把优化逻辑全绕过了。真正有效的做法是：只在内容实际变更时才重绘离屏画布。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 监听配置变化：比如主题色切换后，才重绘带渐变的按钮离屏图
- 资源加载完成触发：精灵图加载完毕，立刻批量绘制到离屏 Canvas，而非每帧检查
img.complete - 手动标记脏区：对分层管理的离屏 Canvas（如“UI-背景层”“UI-图标层”），只更新某一层时，不必清空整个离屏画布，用
clearRect精确擦除对应区域再重绘 - 别在
requestAnimationFrame回调里做离屏更新——除非你确认这一帧确实需要变
多层离屏 + drawImage 合成的实操要点
把整屏塞进一个离屏 Canvas 是常见错误。合理拆分为 3–5 个逻辑层（如 background、static-ui、dynamic-ui、effects），每层独立生命周期，才能发挥最大收益。
- 静态层（background、grid）：首次绘制后永不更新，用
ImageBitmap进一步固化，避免后续drawImage解码开销 - 低频层（角色头像框、技能图标底图）：仅在玩家换装、技能升级时更新，平时复用
- 动态层（血条数值、鼠标悬停高亮）：不进离屏，直接在主 Canvas 绘制，配合局部
clearRect控制脏区 - 合成时注意顺序：先
drawImage静态层，再叠加动态层，最后画特效——顺序错会导致混合异常或遮挡失效
最易被忽略的是缓存粒度和更新边界。画布越大、层越多，越要明确“谁负责哪块像素”；一旦某层更新逻辑失控，整个离屏策略就退化成内存黑洞。
