Web Worker 是为解决 JavaScript 单线程阻塞问题而生的后台线程机制，通过将 CPU 密集型任务（如大数组排序、图像处理）移至独立线程执行，避免主线程卡顿；使用时需主线程创建实例并用 postMessage/onmessage 通信，Worker 文件须同源且无法访问 DOM；关键限制包括无 DOM 操作权、无 localStorage 访问、不可跨域加载、须运行于 HTTP(S) 环境。
Web Worker 的思维导图不需要堆砌概念，重点是理清“为什么用、怎么用、注意什么”三层逻辑。核心就围绕主线程与 Worker 线程的分离关系展开，下面给出可直接落地的结构建议。
为什么需要 Web Worker
单线程 JS 遇到密集计算（比如大数组排序、图像处理、加密解密）会阻塞渲染和交互，导致页面卡死、输入无响应。Worker 就是为解决这个瓶颈而生——它把耗时任务挪到后台线程执行，主线程继续响应用户操作和更新 UI。
- 本质不是“让 JS 变多线程”，而是提供一种受控的线程隔离机制
- 不解决异步 I/O（那是 Promise/async-await 的事），专治 CPU 密集型任务
- 浏览器限制每个 Worker 是独立 JavaScript 上下文，无法共享内存
怎么创建和通信
Worker 的使用流程非常固定：主线程建实例 → 发消息 → Worker 接收 → 计算 → 回传结果 → 主线程处理。所有交互都靠 postMessage 和 onmessage，没有例外。
- 主线程中：
const worker = new Worker('worker.js')，路径必须是同源脚本文件（不能是内联字符串或跨域 URL） - Worker 文件里不能访问
window、document、parent，全局对象是self - 数据传递默认是结构化克隆（深拷贝），大数据量时可用
Transferable（如ArrayBuffer）转移所有权，避免复制开销 - 错误监听用
worker.onerror（主线程）或self.onerror（Worker 内）
常见类型与适用场景
Web Worker 不只有一种。画思维导图时建议横向对比三类，突出差异点：
- Web Worker：最常用，一对一绑定，适合单页面内独立计算任务（如前端 Excel 公式计算）
-
Shared Worker：多个页面/iframe 可共用一个实例，需通过
port通信，适合跨 tab 数据同步（如实时协作状态） - Service Worker：生命周期由浏览器管理，专注拦截网络请求、缓存控制、离线能力，不适用于通用计算
关键限制与避坑点
这些限制决定了 Worker 能做什么、不能做什么，是导图里必须标红的部分：
- 无法操作 DOM、无法访问 localStorage/sessionStorage（但可用 IndexedDB）
- 不能使用
alert、confirm等 UI API；console.log输出在 DevTools 的 “Console” 标签页，但归属 Worker 上下文 - Worker 文件不能跨域加载，也不能用
file://协议运行（需 HTTP(S) 服务） - 频繁创建销毁 Worker 开销大，建议复用实例或用 Worker Pool 模式管理
