Web Worker 是浏览器提供的独立 JS 线程，不共享主线程内存、不可访问 DOM，仅通过 postMessage 通信；适用于 CPU 密集型任务如大数据处理、图像计算、加密等，而非简单异步操作。
Web Worker 是什么：主线程的“外包员工”
Web Worker 是浏览器提供的一个独立执行 JavaScript 的线程，它**不共享主线程的内存，也不访问 DOM、window、document 等全局对象**。它就像把一段耗时逻辑“外包”出去，让主线程继续响应点击、滚动、渲染，避免卡顿。
它的本质是：一个运行在后台的、与主线程并行的 JS 执行环境，通信只能靠 postMessage() 和 onmessage——没有共享变量，只有消息传递。
什么时候该用 Web Worker：别为简单计算开线程
不是所有异步操作都适合 Worker。它启动有开销（初始化、序列化、跨线程通信），小任务反而更慢。适用场景明确：
- 大量数组/对象遍历、排序、过滤（比如处理上万条日志数据）
- 图像像素级处理（
ImageData计算、滤镜、缩放） - 加密解密、哈希计算（如
bcrypt、SHA-256） - 复杂物理模拟或路径规划（游戏、GIS 应用）
- 解析大型 JSON 或 CSV（尤其需校验/转换字段时）
反例：setTimeout、fetch 请求本身、简单字符串拼接——这些本就异步或开销极小，Worker 不仅无益，还会增加通信负担。
立即学习“Java免费学习笔记（深入）”；
怎么写一个基础 Worker：注意路径和作用域隔离
Worker 脚本必须是独立文件（不能是内联字符串），且路径受同源策略限制。常见错误是 404 或 SecurityError，往往因为路径写错或服务未启用 CORS（对本地 file:// 协议尤其敏感）。
主线程中创建：
const worker = new Worker('./path/to/processor.js');
worker.postMessage({ data: hugeArray, action: 'sort' });
worker.onmessage = (e) => {
console.log('结果已返回:', e.data);
};worker 脚本（processor.js）里：
self.onmessage = function(e) {
const { data, action } = e.data;
let result;
if (action === 'sort') {
result = data.sort((a, b) => b - a); // 注意：sort 会原地修改
}
self.postMessage(result); // 只能传可序列化值（或 Transferable 对象）
};关键点：
-
self是 Worker 全局对象，不是window -
postMessage()传参会自动结构化克隆（deep clone），大数组可能卡顿；如需零拷贝，用Transferable（如postMessage(data, [data.buffer])） - 不能用
console.log直接输出到主页面控制台，但现代浏览器支持console（输出在 “Workers” 标签页下）
性能提升的关键不在“开线程”，而在“减少通信+合理拆分”
很多人以为只要扔进 Worker 就快了，实际瓶颈常在通信频率和数据体积。例如每帧都传 canvas 像素数据过去处理，比直接在主线程画还慢。
优化方向很实在：
- 批量处理：把 100 次小计算合并成 1 次大消息，而不是循环 100 次
postMessage - 用
Transferable：对ArrayBuffer、TypedArray、ImageBitmap等，传引用而非拷贝（postMessage(data, [data.buffer])） - 复用 Worker：用
Worker构造函数创建新实例成本高，长任务建议new Worker(...)后长期持有，通过消息调度不同任务 - 避免频繁
onmessage回调：Worker 内部可用while(true) { self.onmessage = ... }配合event.waitUntil（不推荐），更稳妥是用单次监听 + 递归调用或MessageChannel实现多路通信
真正卡顿的页面，问题往往出在没拆分任务粒度、通信设计粗糙，或者误把 I/O 密集型操作（如读文件）塞进 Worker——它只解决 CPU 密集型阻塞，不加速网络或磁盘。
