offscreencanvas 能解决主线程掉帧问题，关键在于将全部绘图逻辑（路径生成、坐标计算、drawimage等）移入 web worker 执行；主线程仅初始化、移交控制权并 commit imagebitmap；资源需预处理为 imagebitmap 传输，尺寸须限制在 4096px 内并适配 dpr，对象复用、增量更新与脏区域合成可进一步优化性能。
OffscreenCanvas 能解决主线程重度计算导致的掉帧问题，关键在于把图表渲染任务从主线程彻底剥离——不是“画得快一点”，而是让主线程完全不参与像素生成过程。
必须把整个绘图逻辑搬进 Worker
只在主线程创建 OffscreenCanvas 对象毫无意义。真正起效的前提是：所有路径生成、坐标计算、样式设置、drawImage、fill、stroke 等操作，全部在 Web Worker 中执行。
- 主线程只做三件事：初始化 canvas 元素、调用 transferControlToOffscreen() 移交控制权、接收并 commit ImageBitmap
- Worker 收到 OffscreenCanvas 后，用 getContext('2d') 获取上下文，之后所有绘图调用都在 Worker 线程内完成
- 避免任何跨线程同步行为：比如在 Worker 里 new Image()、访问 document、调用 getComputedStyle()，这些会立刻触发主线程回退，掉帧照旧
图表资源必须提前准备并零拷贝传输
图表渲染常依赖图像、字体、图标等资源，它们的加载和解码极易隐式拖回主线程。
- 图片资源（如图例图标、背景纹理）需在主线程用 createImageBitmap(blob) 预处理成 ImageBitmap，再通过 postMessage(bitmap, [bitmap]) 转移给 Worker
- 字体文本绘制若需精确度，建议预渲染为位图（如标签文字），避免 Worker 中调用 fillText 时触发字体加载同步
- 数据本身（如 10 万条折线点）可直接序列化传递，但注意不要每帧都传全量——用增量 diff 或压缩编码减少消息体积
控制尺寸与 DPR，防止闪退或崩溃
高频图表常需高分辨率输出，但离屏画布尺寸失控会直接触发 iOS 或 Android WebView 的纹理限制（通常 ≤4096px），导致 createImageBitmap 失败或进程被杀。
- 按 canvas 元素实际尺寸（getBoundingClientRect()）而非 window.innerWidth 计算，避开滚动条/缩放干扰
- 安全宽高 = Math.min(4096, Math.floor(elementWidth * devicePixelRatio))
- 当计算结果超限时，主动降级 DPR（例如设为 1.5 或 1），比崩溃更可控
- 避免每帧 new Path2D、重复创建渐变或 pattern——这些对象应在 Worker 初始化阶段一次性创建并复用
commit 前加轻量调度，避免挤占交互帧
虽然 commit() 本身很快，但如果 Worker 渲染尚未完成，主线程调用它会阻塞等待；更隐蔽的是，频繁 commit 可能打乱 rAF 调度节奏。
- 主线程使用 requestIdleCallback() 或检查 performance.now()，预留至少 3ms 空闲时间再 commit
- 对非关键帧（如过渡动画中间帧）可跳过 commit，只在视觉变化明显时提交
- 配合脏区域机制：若图表仅局部更新（如某条曲线实时刷新），Worker 可只重绘对应区域，再合成到完整帧中，降低整体负载
