OffscreenCanvas 能缓解高频渲染卡顿，因其支持在 Web Worker 中执行绘制，将像素计算移出主线程，避免挤占事件响应与布局时间；必须在 Worker 中初始化并迁移绘图逻辑，配合 transferToImageBitmap 和 postMessage（带转移语义）实现零拷贝传输；需控制尺寸与 DPR 防闪退，并通过静态层预绘制+动态层分离降低每帧重绘量。
OffscreenCanvas 为什么能缓解高频渲染卡顿
因为主线程不再承担全部绘制压力。传统 CanvasRenderingContext2D 的所有操作（清空、路径生成、填充、合成）都在主线程同步执行，一旦每秒调用几十次 drawImage 或频繁修改状态，就会挤占事件响应、布局计算和脚本执行的时间。而 OffscreenCanvas 支持在 Web Worker 中创建上下文，把耗时的像素计算移出主线程——这是真正解耦的关键，不是“画得快一点”，而是“不抢主线程”。
必须在 Worker 中初始化 OffscreenCanvas 才有效
直接在主线程 new OffscreenCanvas 并不能释放主线程压力，它只是个无显示目标的画布对象；只有配合 Worker 才能实现线程隔离。常见错误是只改了创建方式，却没把绘图逻辑搬进 Worker：
- 主线程只保留
canvas元素和requestAnimationFrame调度，负责接收 Worker 发来的ImageBitmap或transferToImageBitmap()结果 - Worker 内部用
self.onmessage接收参数（如旋转角度、数据点数组），用offscreen.getContext('2d')绘制，最后调用offscreen.transferToImageBitmap() - 必须用
postMessage(..., [bitmap])带转移语义发送，否则复制位图会触发内存拷贝，抵消性能收益
离屏画布尺寸和 DPR 控制不当会直接闪退
iOS Safari 和部分 Android WebView 对单张纹理尺寸有硬限制（通常 ≤ 4096px），而高 DPR 设备（如 iPhone 15 Pro 的 3x）会让逻辑尺寸 × DPR 轻易突破阈值。不加控制地按 window.devicePixelRatio 放大 OffscreenCanvas，会导致 createImageBitmap 失败或进程被系统 kill。
安全做法是：
- 预先计算目标尺寸：
const safeWidth = Math.min(4096, Math.floor(canvas.clientWidth * devicePixelRatio)) - 降级 DPR：当计算结果超限时，主动设为
Math.floor(4096 / canvas.clientWidth)，哪怕牺牲一点清晰度 - 避免用
document.documentElement.clientWidth算全屏尺寸——滚动条、缩放等会让它失真，优先用 canvas 元素自身getBoundingClientRect()
静态内容预绘制 + 动态层分离才是关键模式
高频渲染卡顿往往不是“画得太慢”，而是“重复画了不该画的”。比如一个带网格背景的实时折线图，每帧都重绘整个 canvas，其实网格完全不变。
正确拆分方式：
- 用一个
OffscreenCanvas预绘制所有静态层（网格、坐标轴、文字标签），只执行一次 - 另起一个
OffscreenCanvas（可更小尺寸）专用于动态层（折线、散点、动画粒子），每帧重绘 - 主线程
ctx.drawImage(staticOffscreen, 0, 0)+ctx.drawImage(dynamicOffscreen, 0, 0)合成，避免clearRect清除整屏
这种分层不是为了炫技，而是让每次重绘的像素量可控——动态层可能只有 200×150，但整屏是 1200×800，差了一个数量级。
