web worker 是解决模型推理阻塞页面的最有效方案。它通过隔离计算线程避免主线程卡顿，支持多核并行、内存隔离，并需配合 arraybuffer 零拷贝、模型复用、wasm 后端及量化等优化。
直接把模型推理放进 Web Worker 是最有效、最通用的解法。主线程只管渲染和交互，所有计算交给后台线程，页面不再卡顿。
为什么必须用 Web Worker？
JavaScript 是单线程的。一次推理常需几百毫秒甚至数秒，若在主线程执行，按钮点不动、滚动冻结、动画暂停——用户立刻感知“页面死了”。Web Worker 提供完全独立的执行环境：不共享 DOM、window 或 document，但能做纯数值计算，恰好匹配模型前向传播的需求。
- UI 不再阻塞：用户操作全程响应
- 可利用多核 CPU：启动多个 Worker 并行处理不同样本
- 内存隔离：Worker 崩溃不会拖垮整个页面
如何正确创建与通信？
主线程负责加载模型、采集输入（如摄像头帧、canvas 数据）、发送任务；Worker 负责执行 predict 并返回结果。关键在数据传递效率：
- 用 transferable objects（如 ArrayBuffer）传图像像素或张量，避免拷贝开销：主线程调用
worker.postMessage(data, [buffer])，Worker 中用self.onmessage = e => { ... }接收 - 务必在 TensorFlow.js 等框架中调用
.dispose()释放 Tensor 内存，防止内存泄漏 - 模型加载尽量复用：不要每个 Worker 都重新 load —— 可由主线程加载后通过
postMessage(model, [modelHandle])传入（需框架支持），或首个 Worker 加载成功后广播给其余 Worker
常见性能陷阱与绕过方式
不是只要用了 Worker 就一定快，几个细节容易被忽略：
-
频繁小任务调度：每帧都新建 Worker 或发消息，开销反超计算本身 → 改为 Worker 内部维持状态，接收连续帧流；或用
requestIdleCallback批量提交 - GPU 上下文限制：WebGL / WebGPU 上下文无法跨线程共享 → 若必须用 WebGL 加速，需在 Worker 内单独初始化；但部分浏览器支持有限，更推荐优先使用 WASM 后端（如 ONNX Runtime Web 或 Transformers.js 的 WASM 模式）
- 结构化克隆开销：大张量靠默认 postMessage 会序列化，耗时明显 → 必须配合 ArrayBuffer + transfer list 实现零拷贝
搭配其他优化效果更明显
Worker 是主干道，再叠加以下手段，延迟可进一步压缩：
- 输入降采样：224×224 缩到 128×128，计算量减少约 75%，多数场景精度损失可控
- 模型量化：导出为 TensorFlow Lite 或 ONNX INT8 格式，体积减小、推理加速
- 懒加载 + IndexedDB 缓存：模型文件首次加载后存入缓存，二次启动免下载
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
