web worker 仅在主线程执行纯 cpu 密集型、不涉及 dom 和浏览器 api 的计算时能有效缓解卡顿；适用于大数组排序、图像处理、加密解密等场景，但无法改善 dom 操作、重排重绘、资源加载等导致的卡顿。

Web Worker 能缓解页面卡顿，但仅当卡顿源于主线程上的纯计算任务时才有效；它对 DOM 操作、频繁重排重绘、资源加载阻塞或第三方脚本无改善作用。

什么时候用 Web Worker 真的能解卡顿？

核心判断标准：主线程是否在做「不涉及 DOM、不依赖浏览器 API、纯 CPU 密集型」的运算？比如：

• 大数组排序（如 10 万条数据的快速排序）
• 图像像素处理（Canvas 数据遍历、滤镜计算）
• 加密解密（AES 加密大量文本）
• 解析复杂 JSON 或自定义二进制格式
• 路径规划、物理模拟、机器学习推理（轻量级 WASM 配合 Worker 更稳）

这些场景下，把逻辑移进 Web Worker 后，主线程能持续响应点击、滚动、动画——CSS transform 和 opacity 动画不会掉帧，requestIdleCallback 也能正常调度。

Web Worker 为什么不能解决所有卡顿？

因为它的运行环境被刻意隔离：

• 无法访问 window、document、localStorage、console（除非重定向）等主线程对象
• 不能直接操作 DOM —— 所有 UI 更新必须靠 postMessage 回传后由主线程执行
• 频繁通信（比如每毫秒传一次数组）反而引发序列化开销和事件队列压力，比不拆还慢
• 若卡顿来自 getBoundingClientRect() 触发强制同步布局，或 innerHTML 大量插入，Worker 完全不介入

典型误用：把一个带 querySelectorAll 和 element.style.color = 'red' 的函数塞进 Worker —— 运行就报 ReferenceError: document is not defined。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

创建和通信的几个硬性限制

不是写个 new Worker() 就万事大吉，这些细节决定成败：

• Worker 脚本必须是同源 URL（./worker.js 可以，data:text/javascript,... 在多数浏览器被禁）
• self.postMessage() 只能传可序列化的值；传 function、undefined、DOM element 会静默丢弃
• 想传大数组？用 transferable（如 postMessage(data, [data.buffer])），否则是深拷贝，内存翻倍
• 忘记调用 worker.terminate() 或没监听 message 就结束，会导致线程残留、内存泄漏

示例：主线程发送数组并移交控制权

const worker = new Worker('./calc.js');
const arr = new Float64Array(1e6).map((_, i) => Math.sin(i * 0.01));
worker.postMessage(arr, [arr.buffer]); // 移交 ArrayBuffer，避免拷贝

比 Web Worker 更容易被忽略的卡顿点

很多开发者花半天配好 Worker，结果页面还是卡——问题往往不在计算本身：

• 主线程里仍存在长循环（for (let i = 0; i ），哪怕没做计算，也会阻塞事件循环
• Worker 返回结果后，主线程用 innerHTML 一次性插入 5000 行 HTML，触发重排瀑布
• 用了 Comlink 封装 Worker，但方法调用是同步 await，实际仍是串行等待
• 多个 Worker 并发启动，CPU 被占满，主线程调度反被压制（尤其低端设备）

真正要盯住的，是 Chrome DevTools 的 Performance 面板里那条红色的「Long Task」——先确认它是不是 JS 计算，再决定要不要动 Worker。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！