Web Worker 是解决浏览器模型推理卡顿最有效通用的手段，因其隔离计算、避免主线程阻塞、支持多核并行且内存安全。
直接把模型推理扔进 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，二次启动免下载
