worker中获取offscreencanvas需主线程调用transfercontroltooffscreen()后通过postmessage传递并指定transfer list；高频波形图卡顿主因是transfertoimagebitmap()频繁调用或drawimage同步回读；filltext在worker中静默失效，应预渲染文字或交由主线程绘制；60fps稳定方案是worker复用同一offscreencanvas，主线程requestanimationframe轮询drawimage共享引用。
不能直接在 Worker 里 new OffscreenCanvas()，必须由主线程移交；高频波形图卡顿主因是 transferToImageBitmap() 频繁调用或 drawImage 同步回读。
Worker 中怎么拿到可用的 OffscreenCanvas 实例
Worker 无法自己创建 OffscreenCanvas，new OffscreenCanvas(640, 480) 会立即抛出 TypeError: Illegal constructor。唯一合法路径是主线程移交：
- 主线程先有
<canvas id="display"></canvas>元素 - 调用
canvas.transferControlToOffscreen()得到实例（此后该 canvas 不再响应getContext） - 通过
worker.postMessage({ canvas }, [canvas])传递，[canvas]是必须的 transfer list
漏掉 transfer list 或提前调用 getContext 再移交，都会导致 Worker 收到的是序列化副本——offscreenCanvas.getContext('2d') 返回 null，且无任何报错。
drawImage 传图像时为什么波形图突然卡死
高频波形图常需每帧 drawImage 一帧音频数据对应的 ImageBitmap。但若传入的是主线程的 HTMLImageElement 或 HTMLVideoElement，浏览器会强制同步回读像素，实际把 Worker 渲染卡在主线程等待上。
- 正确做法：主线程用
createImageBitmap(img)预转一次，得到可跨线程零拷贝的ImageBitmap - 再通过
postMessage(bitmap, [bitmap])传入 Worker - Worker 中
ctx.drawImage(imageBitmap, 0, 0)才真正异步、无回读
没走 ImageBitmap 这层，OffscreenCanvas 就只是个“假多线程”陷阱。
2D 上下文里 fillText 静默失败，怎么画时间轴标签
Worker 中 OffscreenCanvas.getContext('2d') 支持 fillRect、strokeLine、putImageData，但 fillText 会静默跳过——不报错、不渲染、也不阻塞，极易误判为逻辑错误。
- 方案一：主线程预先用普通 canvas 绘制带文字的模板图，转成
ImageBitmap后传入 Worker 复用 - 方案二：Worker 只计算文字位置和尺寸（
ctx.measureText仍可用），把坐标+文本内容发回主线程，由主线程 canvas 绘制 - 避免在 Worker 里尝试加载字体或调用
ctx.font = '12px sans-serif'，它无效
如何让波形图帧率稳定在 60fps 而不爆内存
高频波形图常见误区是每帧都调用 offscreenCanvas.transferToImageBitmap() 然后 postMessage 回主线程——这个操作本身耗时 2–5ms，连续调用直接压垮 Worker 帧率，且生成大量待 GC 的 ImageBitmap。
- 真正高效的方式：Worker 持续渲染到同一个
OffscreenCanvas实例，主线程用requestAnimationFrame轮询visibleCtx.drawImage(offscreenCanvas, 0, 0) - 此时
offscreenCanvas是共享引用，无需传输、无拷贝、无 GC 压力 - 仅当需要截图、导出或做离屏合成时，才调用
transferToImageBitmap()，且建议限频（如每 3 帧一次）
共享引用模式下，主线程 canvas 会自动同步 OffscreenCanvas 的最新绘制结果——这是最易被忽略、也最关键的性能支点。
