OffscreenCanvas不能在普通Worker中直接构造，必须由主线程canvas通过transferControlToOffscreen()创建并传入；WebGL上下文在Worker中支持因浏览器而异，Firefox仅支持webgl2且需开启标志，Safari不支持；drawImage若传入主线程图像元素会触发同步回读，应改用ImageBitmap；Worker中无requestAnimationFrame，需用setInterval或主线程驱动节拍。
OffscreenCanvas 不能直接在普通 Worker 里用
浏览器对 OffscreenCanvas 的支持有隐性前提：它必须在支持 transferControlToOffscreen() 的上下文中创建，比如主线程的 <canvas> 元素。普通 Worker 没有 DOM，无法调用这个方法，所以你直接 new OffscreenCanvas(100, 100) 会报 TypeError: Illegal constructor。
正确路径只有一条：从主线程 canvas 转移控制权过去。
- 主线程先创建
<canvas id="myCanvas">，再调用canvas.transferControlToOffscreen()得到一个OffscreenCanvas实例 - 用
postMessage(..., [offscreenCanvas])把它传给Worker（注意必须加在 transfer list 里） - Worker 收到后才能安全调用
getContext('2d')或getContext('webgl')
WebGL 上下文在 Worker 中初始化失败的常见原因
即使成功传入 OffscreenCanvas，getContext('webgl') 仍可能返回 null —— 这不是代码写错了，而是环境限制。
- Chrome 和 Edge 支持 Worker 中的 WebGL，但 Firefox 目前（v125）仍不支持
webgl，只支持webgl2（且需开启dom.workers.offscreen-canvas.enabled标志） - Safari 完全不支持 OffscreenCanvas + WebGL 组合
- 即使支持，也要确保传入的是真正的
OffscreenCanvas对象，而不是序列化后的副本（否则getContext会静默失败）
验证方式很简单：在 Worker 里打印 offscreenCanvas.getContext('webgl') !== null，别依赖异常捕获。
drawImage 到 OffscreenCanvas 会触发主线程同步回读
很多人想把图像处理逻辑搬进 Worker，比如用 OffscreenCanvas 接收一张图片，然后 ctx.drawImage(img, ...) 再做滤镜。但这里有个陷阱：drawImage 如果传入的是主线程的 HTMLImageElement 或 HTMLVideoElement，浏览器会强制同步回读像素数据，实际卡住主线程。
- 解决方案是提前把图像转成
ImageBitmap，再用postMessage(..., [imageBitmap])传入 Worker -
ImageBitmap可以跨线程零拷贝传递，且OffscreenCanvas的drawImage支持它 - 别忘了主线程用
createImageBitmap(img)转换，这步本身异步，但只执行一次
漏掉 ImageBitmap 这层，OffscreenCanvas 就只是个“看起来在后台”的假并行。
requestAnimationFrame 在 Worker 里不可用
子线程没有 requestAnimationFrame，这是硬性限制。想驱动动画循环，只能靠 setInterval 或 setTimeout，但它们不和屏幕刷新率对齐，容易掉帧或撕裂。
- 推荐用
performance.now()手动计算 delta 时间，配合固定时间步长（如 16ms）模拟帧节奏 - 更稳的做法是主线程用
requestAnimationFrame控制节拍，只把耗时渲染逻辑（如粒子更新、着色器计算）扔给 Worker，算完再把结果传回来 - 避免在 Worker 里频繁
postMessage帧数据——每帧传一次Uint8ClampedArray比传 canvas 内容快得多，但要注意内存复用，别每次 new 新数组
真正难的从来不是“能不能画”，而是“怎么让画出来的帧准时送到屏幕上”。OffscreenCanvas 解决了绘制隔离，但调度和同步还得自己兜底。
