Web Worker 是解决浏览器模型推理卡顿最有效、最通用的手段，因其提供独立线程避免主线程阻塞、支持多核并行与内存隔离，配合 transferable objects 通信、模型复用、输入降采样、量化及 WASM 后端可进一步优化性能。

直接把模型推理扔进 Web Worker，是解决浏览器卡顿最有效、最通用的手段。主线程专注渲染和交互，计算全交给后台线程，体验立刻顺滑。

为什么必须用 Web Worker？

JavaScript 是单线程的，模型推理动辄几百毫秒甚至数秒，一旦在主线程执行，页面就会完全冻结：按钮点不动、滚动卡死、动画暂停。Web Worker 提供独立的 JavaScript 执行环境，不共享 DOM、window 或 document，但能做纯计算——这正是模型前向传播需要的全部。

• 避免 UI 阻塞：用户操作不受推理影响
• 利用多核 CPU：可同时启动多个 Worker 并行处理不同样本
• 内存隔离：Worker 崩溃不会拖垮整个页面

如何正确创建和通信？

主线程负责加载模型、采集输入（如摄像头帧、画布数据）、发送任务；Worker 负责加载模型（或复用已加载实例）、执行 predict、返回结果。关键在于数据传递方式：

• 使用 transferable objects（如 ArrayBuffer）传递图像像素、张量数据，避免拷贝开销
• 主线程用 worker.postMessage(data, [transferList]) 发送二进制数据
• Worker 中用 self.onmessage = async (e) => { ... } 接收并处理
• 务必调用 .dispose() 释放 Tensor 内存（尤其在 TensorFlow.js 中）

常见陷阱与应对

不是只要用了 Worker 就一定快，几个典型问题容易被忽略：

• 模型重复加载：每个 Worker 独立作用域，不能共享 model 实例 → 解决方案：主线程加载好后，用 postMessage(model, [modelHandle]) 传入（需框架支持），或让首个 Worker 加载后广播给其他 Worker
• 频繁小任务调度开销：每帧都新建/发消息会拖慢整体 → 解决方案：Worker 内部维持状态，接收连续帧数据流，或采用 requestIdleCallback 批量提交
• GPU 上下文限制：WebGL / WebGPU 上下文无法跨线程共享 → WebGL 加速必须在 Worker 内单独初始化，且部分浏览器对 Worker 中 WebGL 支持有限（推荐优先用 WASM 后端）

配合其他优化效果更佳

Worker 是性能提升的“主干道”，再叠加以下措施，推理延迟可进一步压缩：

• 输入降采样：将 224×224 输入缩至 128×128，计算量减少约 75%，多数场景精度损失可控
• 模型量化：导出为 TensorFlow Lite 或 ONNX INT8 格式，体积减小、推理加速
• 懒加载 + 缓存：模型文件按需加载，成功后缓存在 IndexedDB，二次启动免下载
• WASM 后端替代 JS：TensorFlow.js 或 ONNX Runtime 支持 WASM，比纯 JS 快 2–5 倍，且天然适配 Worker