一、JS 是单线程，为什么当初这么设计？

前端的本职工作

JavaScript 诞生之初就只做一件事：给网页加点交互——表单校验、点击弹窗、小动画。这些任务的特点是：

• 任务轻、频率高
• 必须和 DOM 紧密配合
• 使用者期望即时响应

如果 JS 是多线程的，两个线程同时改同一个

单线程的代价

// 这段代码会彻底卡死页面 for { console.log;怎么说呢，}

执行数十亿次循环期间。浏览器完全无法响应任何使用者操作——点击无效、滚动卡死、动画掉帧。因为主线程被这段同步代码霸占了。

主线程时间线的观点是，┌──────────────────────────────────────────────────────┐
│ │
│ ↓ 使用者点击按钮 │
│ ↓ 使用者滚动页面 │
│ ↓ ... │
│ ↓ 循环结束 │
│ → 处理排队的事件 │
│ → 使用者感觉"卡了" │
└──────────────────────────────────────────────────────┘

二、Event Loop 能拯救吗？

异步 ≠ 多线程

console.log;setTimeout => {
console.log;// 异步，放到宏任务队列
});console.log，// 输出顺序： a → c → b

Event Loop 的机制是不阻塞——把耗时操作挂起来先去干别的事。但关键认知是这方面，

主线程唯一的执行栈：
┌──────────────────────────────────────────────┐
│ 同步代码 → 微任务队列 → 宏任务队列 │
│ 所有队列里的任务最终都回到同一条主线程上执行 │
│ 该卡还是卡——只是“晚点卡” │
└──────────────────────────────────────────────┘

什么场景 Event Loop 搞不定？

当一个任务是计算密集型的——LLM 推理、游戏物理引擎、大量加密解密——即使把它拆成多个异步块，每个块仍然占用主线程那条单行道。页面就会间歇性卡顿，

需求变了的观点是，- 不只是"点击按钮弹个窗"
- 而是"跑一个本地 LLM 模型做推理"
- "实时渲染一个 3D 游戏场景"
- "对 1GB 数据做加密处理"
→ Event Loop 异步调度不够用了
→ 需要真正的并行计算 → Web Worker 来了

三、Web Worker：浏览器的多线程方案

JS 单线程并没有改变——但浏览器是多线程的

┌──────────────────────────────────┐
│ 浏览器 │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ JS 主线 │ │ Worker线 │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ DOM 操作 ✓│ │ DOM 操作 ✗│ │
│ │ UI 渲染 ✓│ │纯计算 ✓ │ │
│ └──────────┘ └──────────┘ │
│ | | |
│ └── postMessage ──► |
│ 消息通信 |
└──────────────────────────────────┘

浏览器本身是 C++ 写的多进程多线程软件。Web Worker 是浏览器提供的一个新的 JS运行时环境**——独立的 V8 实例、独立内存堆、独立事件循环。和主线程物理隔离**，互不干扰。

Worker 的硬限制

• ❌ 不能访问 DOM**——Worker里没有 ,没有
• ❌ 不能直接操作页面**——UI 更新只能通过消息通知主线来完成。
• ✅ 有自己的 API 子集** ——self。postMessage,onmessage,fetch,Math…

这恰好符合 React 的哲学** ——React 本来就帮我们操作 DOM，Worker 专注纯计算即可。

四、完整 Demo 拆解

说到主线程。App.jsx

import { useRef,useState,useEffect } from 'react';function App {
console.log;// 为组件渲染挂载让路 —— 优先渲染 UI，Worker 等等再开
const workerRef = useRef;// 持久持有 Worker 实例
const = useState;// 响应式：计算结果
const = useState;// 响应式：加载状态
useEffect => {
// 👉① 创建 Worker
workerRef.current = new Worker(
new URL
);不过，// 👉② 接收 Worker 消息
workerRef.current.onmessage = => {
console.log;const { result } = e.data;setResult，// 更新 UI
setLoading;// 隐藏 loading
};老实说，// 👉③ 清理资源 —— 防止内存泄漏 & “僵尸”Worker
return => {
workerRef.current?.terminate，话说回来，// 强制终止子线程
workerRef.current = null;}，},);const startHeavyCalc = => {
setLoading;// 👉④ 给 Worker 发指令
workerRef.current.postMessage });}，return (


useRef + WebWorker 耗时运算

开启 web worker 执行十亿次循环，结束后通知主线

{loading?"正在后台计算，" : "启动繁重计算任务"}

{result && 

计算结果这方面，{result}
}

);}
export default App;按理说，

Worker Thread：worker.js

// Web Worker 独立子线程 —— 不可以做 DOM API。
有自己的 API 子集
self.onmessage = => {
const { num } = e.data;console.log，let sum = 0;怎么说呢，for { // 十亿次循环！sum += num * i;}
// 完成后把结果发回主线
self.postMessage;}，不过，

完整数据流时间线

使用者点击按钮
▼ startHeavyCalc
├─ setLoading → UI 显示 “正在计算…”
├─ workerRef.current.postMessage
|  ▼
|  Worker 收到 onmessage
|  执行 十亿次循环
|  self.postMessage
|  ▼
▼ 主线 onmessage 被触发
├─ setResult → UI 更新显示结果
├─ setLoading → 按钮恢复可点

主要体验**：十亿次循环在跑的时候，页面按钮、滚动、输入框一切正常——因为计算发生在另一个 V8 实例**里主线事件循环毫无阻塞。

五、逐行解读关键设计

为什么用 useRef 而不是 useState 存 Worker？

const workerRef = useRef;



 
#useRef# 
#useState# 



存值方式 
`workerRef.current = …` 
`setWorker` 

No ❌ 
If you store a Worker in state it will cause a re‑render each time – unnecessary.

`ref` 跨渲染保持不变 
`state` 会在每次渲染后重新创建或丢失引用 

`Worker` 属于“后台工具”，不需要驱动 UI 
`result` / `loading` 才需要 `useState` 驱动 UI 




为什么在 useEffect 中 new Worker？​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​



再看*痛点*。若把 `new Worker` 写在函数体里会导致首次渲染被阻塞，从而出现「白屏」或「加载慢」的问题。

说到*正确做法*，



从时间线来看。① render 阶段：App 执行 → 返回 JSX → 虚拟 DOM
② commit 阶段：DOM 挂载到页面 → 使用者看到界面
③ effect 阶段：useEffect 回调执行 → new Worker → workerRef.current 指向实例 


#对比# 渲染阶段 vs 副作用阶段：



#错误# 把 new Worker 放在组件体里 ➜ 首次渲染被阻塞 ➜ 白屏/卡顿。
\

#正确# 放在 useEffect=>{},) ➜ 首屏快速呈现 ➜ 后台开启子进程。老实说，
\

#常用方法# 保持副作用仅在 mount 时运行。并在 unmount 时清理。
\
<\/ul>



"postMessage": 跨域结构化克隆传输机制




🔎 小技巧 ：如果要传递大对象，请提前抽取关键字段或使用 Transferable 来避免深拷贝带来的性能损耗。js


// 主 -> Worker

workerRef.current.postMessage;

// Worker -> 主

self.postMessage;

底层实现使用 结构化克隆算法，将数据 完整拷贝 到另一条独立内存空间。

css

主内存 | 工作者内存 

{ num:123 } ----> { num:123 }




⚠️ 大对象会产生额外拷贝成本，请尽量精简消息体；
\

⚠️ 函数/DOM 节点不可序列化；
\
<\/ul>



#实战提示# 若需要共享大数据，可考虑使用 SharedArrayBuffer 或 OffscreenCanvas。


#注意清理# - 谁创建谁销毁 👇‍


说到清理函数，谁创建谁销毁

js

return => {
workerRef.current?.terminate，//立即终止工作者，不管它正处于何种状态
workerRef.current = null;//帮助 GC 回收引用
};

``


terminateCANCEL 工作者当前所有活动并释放其独占内存；即使正在进行十亿次循环也会被强制中止。不过，

\

=null`：语义上标记 “已死亡”。协助 V8 垃圾回收，话说回来，\
<\/ul>


❗️如果忘记清理：


→ 工作者仍旧运行 ⇒ CPU 持续占用 ✅；• 内存泄漏，• 完成后 postMessage 找不到监听者 ⇒ 报错 🚨。这种情况极易导致生产环境出现「偶尔卡顿」且难以定位的问题。按理说，在 React 中遵循 Setup ↔ Cleanup 对称性 是必不可少的常用方法。




六️⃣ Web Worker 合适场景 💡



适配场景 ✅ 推荐使用 Workers ✅
💡 别滥用!如非必要请保留单端逻辑.
| 场景 | 示例 |
|---|---|
| 大规模数值运算 | 金融模型模拟 / 科学仿真 |
| 图像/音视频处理 | 离线压缩 / 滤镜特效 |
| 大文件解析 | CSV/JSON 大文件读取 |
| AI 推理/机器学习 | 本地模型推断 |
| 加密/解密 | 文件加密上传 |
### 🌟 常见误区
- 误以为 Workers 能直接操作 DOM ❌
- 认为 Workers 能共享状态而免去 copy 成本 ❓
- 把所有异步代码都搬进 Workers。会导致通信开销更大 ⚖️
### 📚 小结
- 将 CPU 密集型 与 UI 渲染 完全拆分，让 React 保持流畅。话说回来，- 用 useRef 保存实例。用 useEffect 生命周期管理，用 postMessage 做桥梁。- 必须记得 terminate + null 清理，否则易泄漏。---\end of article---