Web Workers 不能直接操作 DOM，因其运行在独立线程，无 window、document 等主线程对象；应仅执行纯计算任务，通过 postMessage 与主线程通信并由主线程更新 DOM。
Web Workers 不能直接操作 DOM
这是最常踩的坑：写完 Worker 发现 document.getElementById 报错，或者页面没更新。因为 Worker 运行在独立线程，没有 window、document、localStorage 等主线程专属对象。
正确做法是只让 Worker 做纯计算——比如解析大 JSON、加密、图像像素处理、复杂排序。结果通过 postMessage 传回主线程，再由主线程更新 DOM。
- Worker 文件里禁止出现
document、alert、fetch（除非用self.fetch，但兼容性差） - 主线程用
worker.postMessage(data)发送数据，用worker.onmessage接收 - 传递的数据会被结构化克隆，函数、DOM 节点、
undefined会丢失或报错
如何创建并通信：一个最小可运行例子
不是所有浏览器都支持 SharedArrayBuffer，但基础 Worker 兼容性很好（Chrome 4+、Firefox 3.5+、Safari 4+）。重点是路径和通信时机。
假设主线程 HTML 在根目录，Worker 脚本叫 calc.js：
const worker = new Worker('calc.js');
worker.postMessage({ numbers: [1, 2, 3, 4, 5] });
worker.onmessage = (e) => {
console.log('结果:', e.data.sum); // 输出 15
};
calc.js 内容：
self.onmessage = function(e) {
const sum = e.data.numbers.reduce((a, b) => a + b, 0);
self.postMessage({ sum }); // 必须用 self.postMessage
};
- 路径必须相对 HTML 当前位置，不是 JS 文件位置
- 主线程和 Worker 都要用
postMessage+onmessage，不能混用addEventListener（除非显式绑定self） - 传对象时别传大数组原引用——虽然结构化克隆会复制，但大数据量仍影响性能
什么时候该用 Worker？看任务是否「可拆」且「不依赖 UI」
Worker 不是银弹。如果任务本身耗时不到 16ms（一帧），或者频繁要读取 scrollY、getBoundingClientRect，就别硬塞进去——通信开销反而更大。
- 适合：大文件分块解析、Canvas 图像滤镜、WebAssembly 模块调用、长列表虚拟滚动前的数据预处理
- 不适合：只是把
for (let i = 0; i 包一层就扔进 Worker；或需要每 10ms 同步一次鼠标位置 - 注意 Safari 对
importScripts的限制：不能加载跨域脚本，且不支持模块语法（type="module"Worker 在 Safari 16.4+ 才可用）
调试 Worker 很麻烦，但有固定套路
Chrome 和 Firefox 支持在 DevTools 的 “Application → Service Workers” 或 “Sources → Workers” 里看到运行中的 Worker，但断点经常不触发。根本原因是 Worker 是独立上下文，控制台输出默认不显示在主面板。
- 在 Worker 里加
console.log，然后去 DevTools 的 “Console” 切换顶部下拉菜单，选中对应 Worker 名称 - 不要用
debugger—— 它只在主线程生效；改用self.postMessage({ debug: 'here' })配合主线程监听 - Worker 报错不会中断主线程，但错误信息藏得深：Chrome 在 “Console” 里搜
Uncaught (in worker)，Firefox 在 “Debugger” 标签页左上角点 “Workers” 切换
多线程真正的复杂点不在启动，而在状态同步和生命周期管理——比如页面还没关，Worker 却已终止；或用户快速点击多次，导致多个 Worker 并发执行同一任务。这些得靠手动 abort 控制或用 Worker.terminate() 配合标志位，不是开个 new Worker 就万事大吉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
