今日主要

• JS 单线程下Event Loop 解决“等待”但解决不了“计算本身太重”。
• Web Worker 开辟独立线程。不能操作 DOM，但能计算、请求、读写存储。
• useRef 持久存放 Worker 实例，组件重渲染不会重置线程对象。
• useEffect 挂载后初始化。让渲染先行，Worker 不挡首屏。
• postMessage 发、onmessage 收。两边格式相同，方向不同，
• 解构 const { num } = e.data 从消息对象中提取需要的字段。
• 卸载时 terminate 杀线程，再置 null 清引用。

知识关系

useRef 创建盒子 → useEffect 挂载后 new Worker 装进去 → postMessage/onmessage 双向通信 → 卸载时 terminate + 置 null 清理。这条链路就是 useRef + Worker 的标准用法。

单线程之困

知识点

JS 单线程一次只能做一件事。其实，网络请求这类“等待型”任务。Event Loop 异步机制可以应对 —— 扔到一边等，主线程继续响应使用者。但纯计算型任务不同：一个 for 循环跑几亿次线程就被占满，页面冻结。使用者痛点：页面卡死、点击无响应、滚动卡顿，直接导致业务流失。

代码示例

// 主线程直接跑大量循环 → 页面卡死
console.time;for {
// 假设的密集计算
}
console.timeEnd;// 整个过程使用者点不了任何东西

运行过程

使用者触发计算 → 主线程进入 for 循环
→ JS 引擎被独占，渲染引擎被堵塞
→ 页面冻结。点击、滚动全无响应
→ 循环结束才能恢复

拆解要点

• console.time 到 console.timeEnd 之间的所有代码都在主线程执行。
• 这段期间浏览器没法处理使用者交互事件，渲染也没法进行。
• 异步只能把任务放到后面执行，但不能让任务本身变快或变小。

设计初衷

浏览器选单线程是为了避免多线程同时改 DOM 产生冲突。但代价是重计算会卡页面，Web Worker 正是为了解决这个缺陷——不碰 DOM 的活，全扔到另一条线程。 说起来，

容易混淆点

1. Event Loop 异步能解决 for 循环卡页面的问题吗？为什么，
2. 浏览器为什么不让 Worker 操作 DOM？

参考答案这方面，

1. 不能。老实说，异步只是把任务挪到后面执行。但 for 循环本身还是要在主线程跑完，跑的时候依然独占线程，页面照样卡。
2. Avoid 多线程同时修改同一个 DOM 节点产生冲突。数据一致性优先于功能便利。

Web Worker 是浏览器提供的独立线程，有自己的内存空间。它不能操作 DOM，但能做的事远不止数学计算——fetch 请求、IndexedDB 读写、Blob 处理、定时器都能用。

// worker.js — 独立线程中执行的脚本
self.onmessage = => {
const { num } = e.data;let sum = 0，for {
sum += num * i;}
self.postMessage;}，说起来，

Worker 线程被 new Worker 创建 →
立即执行顶层代码 →
注册 self.onmessage 监听 →
等待主线​程发消息 →
收到消息后开始计算 →
计算完成 →
self.postMessage 把结果发回主线​程

• self 在 Worker里相当于主线​程的 window 指向 Worker 自身的全局作用域。话说回来，
• self.onmessage 注册消息监听。主线​程每次 postMessage 都会触发这个回调。
• Worker里的计算不占主线​程，两条线并行执行。

设计原因

Worker只有纯 JS 环境，刻意去掉了 DOM API。原因和单线​程设计的初衷一致：避免多线​程操作页面产生竞态条件。

1. Worker 能调用 document.querySelector 吗？为什么，话说回来，
2. Worker 能发 fetch 请求吗？

参考答案的观点是，

1. 不能。Worker里没有 document 对象。也没有 DOM 树，这是刻意的安全限制。
2. 能。fetch "

useRef 持 Worker