应优先在单次超50ms、高频或纯计算任务中使用web worker；需通过performance面板验证主线程长任务，并对比结构化克隆与transferable零拷贝下的真实收益，避免小数据量反致性能下降。
评估 Web Worker 是否带来真实性能收益，不能只看“开了没”，而要量化两个关键变量：主线程被阻塞的时间是否显著减少，以及 Worker 自身开销是否被并行收益覆盖。
先确认任务是否真需要 Worker
不是所有慢操作都适合搬进 Worker。核心判断标准是：
- 单次耗时超过 50ms，且发生在用户交互中（如滚动、输入、动画期间）；
- 执行频率高，比如每秒超 10 次，即使单次只要 5ms，累积也容易拖垮帧率；
- 纯计算、无 DOM 依赖、可拆分——图像滤波、大数组排序、加密、表达式求值都符合；但简单校验、样式修改、链式递推就不适合。
测准主线程“卡”在哪里
用浏览器 Performance 面板或 Performance API 精确抓取瓶颈：
- 在目标函数前后加
performance.mark()和performance.measure()，看实际耗时； - 重点关注 Main 线程的长任务（Long Tasks），超过 50ms 的条目就是 Worker 化的优先候选；
- 对比开启 Worker 前后，FPS 曲线是否更平稳、Input Delay 是否降低、Layout/Recalculation 是否减少。
测 Worker 本身的净收益
Worker 性能不是“越快越好”，而是“比主线程快多少、稳多少”。实测时注意三组对比：
-
主线程原生执行（如直接调用
Array.sort()）； - Worker + 结构化克隆通信（传普通数组/对象，会深拷贝）；
- Worker + Transferable + TypedArray（零拷贝，推荐方式）。
例如处理 100 万整数排序：
- 主线程 sort()：约 480ms；
- Worker + 克隆传数据：约 620ms（通信反超计算）；
- Worker + ArrayBuffer 零拷贝：约 390ms；
- 4 Worker 分片 + 零拷贝 + 归并：约 180ms，主线程全程 60fps。
警惕隐性开销和误用陷阱
收益被抵消的常见原因：
- 数据太小：子数组长度
- 通信太碎：每帧传一个坐标点，不如打包成批次或用差分更新；
-
Worker 数超核数：超过
navigator.hardwareConcurrency（通常为 4–16），调度争抢反而拖慢； - 误传 DOM 或 window 对象：会直接报错，Worker 根本收不到消息。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
