Web Worker是浏览器提供的独立JavaScript执行环境，运行在与主线程隔离的操作系统线程中，拥有self全局对象但无DOM访问能力，通过postMessage通信。
Web Worker 是什么，和主线程有什么关系？
Web Worker 是浏览器提供的一个独立 JavaScript 执行环境，它在与主线程完全隔离的线程中运行，有自己的全局对象（self）、作用域和事件循环，但没有 window、document 或 DOM API。它不能直接操作页面，只能通过 postMessage() 和主线程通信。
关键点在于：主线程是单线程的，所有 JS 代码、渲染、用户交互都挤在同一个线程里；而 Web Worker 启动的是一个真正意义上的新操作系统线程（由浏览器底层调度），因此它的 JS 执行不会抢占主线程时间片——这是它能解决阻塞问题的根本原因。
怎么创建并使用一个基础 Web Worker？
必须把 Worker 逻辑写在单独的 JS 文件中（比如 worker.js），不能用内联字符串或 Blob URL（部分旧浏览器不支持后者，且可读性差）。
/* worker.js */
self.onmessage = function(e) {
const data = e.data;
// 模拟耗时计算
let result = 0;
for (let i = 0; i < data * 1e7; i++) {
result += i;
}
self.postMessage({ result });
};
主线程中这样调用：
立即学习“Java免费学习笔记（深入）”；
const worker = new Worker('worker.js');
worker.onmessage = function(e) {
console.log('计算结果：', e.data.result);
};
worker.postMessage(10); // 发送参数
注意：Worker 构造函数只接受 URL，不支持模块语法（ESM）直接传入；若要用 importScripts() 加载依赖，路径也必须是同源静态资源。
为什么用 postMessage 而不是共享内存？
主线程和 Worker 之间默认不共享内存，postMessage() 默认采用结构化克隆算法（structured clone）序列化/反序列化数据，这意味着传递大对象（如巨型数组、嵌套对象）会有明显开销，甚至失败（比如含函数、undefined、Symbol 的对象无法克隆）。
如果你需要零拷贝传输，可以使用 Transferable 对象（如 ArrayBuffer）：
// 主线程
const buffer = new ArrayBuffer(1024);
const worker = new Worker('worker.js');
worker.postMessage(buffer, [buffer]); // 第二个参数表示移交所有权
// worker.js
self.onmessage = function(e) {
const buffer = e.data; // 直接拿到 ArrayBuffer 引用，原主线程已失效
const view = new Uint8Array(buffer);
// …处理…
};
移交后，原主线程的 buffer 会变成 ArrayBuffer.transfered 状态，不可再访问——这点极易被忽略，导致“数据突然变空”类错误。
常见阻塞场景下 Worker 的实际价值在哪？
它适合处理明确、长时间运行、纯计算型任务，比如：
- 图像像素处理（Canvas 数据分析）
- 大型 JSON 解析或格式转换
- 加密/解密、哈希计算（如 bcrypt、SHA-256）
- 离线数据聚合（前端日志压缩、本地数据库查询模拟）
但它不适合以下情况：
- 频繁小数据通信（每次
postMessage都有调度开销） - 需要 DOM 操作的任务（仍得发回主线程执行）
- 依赖第三方库且该库未做 Worker 兼容（比如很多 UI 组件、jQuery 插件）
另外，Worker 不是免费的——每个 Worker 实例占用独立内存和 CPU 时间片，Chrome 中最多约 20 个活跃 Worker（取决于设备和策略），滥用反而引发内存泄漏或线程饥饿。
