17370845950

Web Workers 是浏览器提供的真实多线程机制，通过独立线程执行 JS 脚本，主线程与 Worker 间以 postMessage 通信、结构化克隆传值、严格 API 隔离，适用于 CPU 密集型纯计算任务，不同于 Promise/async-await 的单线程异步调度。

Web Workers 是浏览器提供的一种后台线程机制，让 JavaScript 能在**独立于主线程的线程中运行脚本**，从而实现真正意义上的多线程执行。它不是“模拟”并发，而是由浏览器底层调度的真实线程。

为什么 JavaScript 本身是单线程，却能用 Web Workers 实现多线程？

JavaScript 引擎（如 V8）运行在主线程上，负责执行 JS 代码、处理事件、更新 DOM 和渲染页面——这些必须串行进行，否则会引发 UI 不一致或竞态问题。但浏览器作为宿主环境，本身是多线程甚至多进程的（例如 Chrome 的渲染进程、网络进程等）。Web Workers 正是利用了这一能力：浏览器为每个 Worker 分配一个独立的 JS 执行上下文和线程，与主线程并行运行，互不干扰。

关键点在于：多线程的“线程”来自浏览器，不是 JS 语言自身提供的；JS 仍保持单线程语义，只是通过 Worker API 借用了宿主的并发能力。

Web Workers 的多线程靠什么保证安全与隔离？

主线程和 Worker 线程之间不共享内存，也不共享任何对象引用。这种隔离通过以下方式实现：

• 通信仅限 postMessage / onmessage：所有数据传递都走结构化克隆（structured clone），即深拷贝。原始对象不会被共享，避免了竞态和内存冲突。
• 全局对象严格受限：Worker 中无法访问 window、document、localStorage、alert 等主线程专属 API，只能使用 self、fetch、setTimeout、console 等允许的接口。
• 无 DOM 访问权限：UI 操作必须交还主线程完成，Worker 只负责计算、解析、转换等纯逻辑任务。

什么样的任务适合交给 Web Workers？

核心判断标准是：是否耗时、是否与 UI 无关、是否可拆解为输入→处理→输出的纯函数式流程。典型场景包括：

• 大数组遍历、排序、聚合（如统计百万条日志）
• 图像像素处理（Canvas 数据分析、滤镜计算）
• 加密解密、哈希运算（如文件分片 SHA256）
• 复杂 JSON 解析或大型 AST 遍历
• 实时音视频帧处理（配合 WebAssembly 效果更佳）

它和 Promise、async/await 的多线程区别在哪？

Promises 和 async/await 是**异步编程模型**，本质仍是单线程事件循环调度，不能并行执行 CPU 密集型任务。比如一个 10 亿次循环，用 await 包裹也不会让页面变流畅——它只是把“等待”让出去，而循环本身仍在主线程霸占 CPU。Web Workers 则把整个循环挪到另一个线程，主线程完全释放，UI 继续响应滚动、点击等操作。