Web Workers 实现的是并发而非并行，因不共享内存而依赖消息传递；需从独立JS文件加载，通过postMessage通信并结构化克隆数据，适用于计算密集型任务。
Web Workers 不能真正实现 JavaScript 的“多线程编程”，因为 JS 主线程和 Worker 线程之间不共享内存，也没有锁、原子操作或直接访问对方变量的能力——它们靠消息传递通信，本质是并发（concurrent）而非并行（parallel）。
如果你期望用 Worker 像 Python 的 threading 那样共享变量、随时读写 let count = 0，会立刻踩坑。
如何创建并启动一个 Web Worker
Worker 必须从独立的 JS 文件中加载，不能内联定义（除 Blob 方式外，但不推荐用于生产）。
常见错误：直接传函数或字符串给 new Worker() —— 浏览器会报 DOMException: Failed to construct 'Worker': Script at ... violates the following Content Security Policy directive 或直接拒绝执行。
立即学习“Java免费学习笔记（深入）”；
- 新建文件
worker.js，内容以self.onmessage = function(e) { ... }开头 - 主线程中用
const worker = new Worker('./worker.js');实例化 - 路径必须是同源的，且不能是
file://协议（需 HTTP/HTTPS 服务） - Vite/Webpack 等工具对
new Worker('./xxx.js')有特殊处理，注意是否启用了worker插件或配置了rollupOptions.output.manualChunks
主线程与 Worker 之间怎么传数据
postMessage() 是唯一通信方式，传的数据会被结构化克隆（structured clone），不是引用传递。这意味着：
-
function、undefined、Symbol、Promise、RegExp、Map/Set（部分浏览器支持，但不可靠）等无法传递 -
ArrayBuffer可以零拷贝转移（用postMessage(data, [arrayBuffer])），这是处理大数组/图像数据的关键优化点 - 频繁传大对象（如 10MB JSON）会明显卡主线程，因为克隆过程同步阻塞
/* worker.js */
self.onmessage = function(e) {
const result = e.data.array.map(x => x * 2);
self.postMessage({ result });
};Worker 中能用哪些 API
Worker 线程没有 window、document、localStorage，也不能操作 DOM。但它有：
-
self（等价于globalThis，不是window） -
fetch、setTimeout、WebAssembly、IndexedDB（需显式打开） -
importScripts('a.js', 'b.js')（同步加载脚本，会阻塞，慎用） - 现代写法推荐用
import：在 Worker 文件顶部写import { heavyCalc } from './utils.js';，但需确保 Worker 类型为type="module"，即new Worker('./worker.js', { type: 'module' })
什么时候该用 Worker，什么时候不该用
Worker 不是银弹。启动开销约 1–5ms，传输小数据反而比直接计算慢。
- 适合：纯计算密集型任务（如加密、图像滤镜、解析大型 JSON、物理模拟）
- 不适合：频繁交互（每 100ms 发一次消息）、依赖 DOM 节点、需要实时响应用户输入的任务
- 替代方案考虑：
requestIdleCallback（轻量分片）、setTimeout(..., 0)（防阻塞）、甚至直接优化算法（比如用for替代map().filter().reduce()） - 调试困难：Chrome DevTools 的 Sources 面板里要手动打开 “Workers” 标签页才能断点；Safari 更麻烦，常需
console.log驱动
Worker 的核心价值不是“多线程”，而是把确定会长时间运行的 CPU 工作从渲染线程里摘出去——只要你不指望它共享状态、不误以为它能操作页面、也不在毫秒级交互场景里滥用，它就很可靠。
