web worker 不降低总cpu消耗，仅转移计算；需注意路径解析、blob url优化、transfer list传大数据、及时终止、分块处理长任务及importscripts同步阻塞问题。
Web Worker 本身不降低总 CPU 消耗，只把计算从主线程挪走；用得不好反而更卡——创建开销、通信延迟、内存泄漏都会抵消多线程优势。关键不是“用了没”，而是“怎么分、怎么传、怎么收”。
Worker 创建路径选错，首屏直接多一次网络请求
new Worker('worker.js') 中的路径是相对主页面 URL 解析的，不是相对于当前 JS 文件。比如在 /app/dashboard.html 里执行这行代码，浏览器实际请求的是 /app/worker.js，哪怕你的 worker.js 放在 /js/ 下也会 404。
- 一律用绝对路径：
new Worker('/workers/encryptor.js') - 逻辑简单（≤5 KB）且稳定时，改用 Blob URL，彻底绕过网络：
const blob = new Blob([workerCode], { type: 'application/javascript' }); new Worker(URL.createObjectURL(blob)) - 高频 Worker 脚本加
<link rel="preload" href="/workers/analyser.js" as="script">，预加载进 HTTP 缓存
postMessage 传大数据，序列化卡死主线程
结构化克隆对大型对象（如 10MB JSON、图像像素数组）做深拷贝，主线程会卡顿几十毫秒——你刚以为“交给 Worker 就安全了”，其实卡点转移到了发消息那一瞬间。
- 传
ArrayBuffer或TypedArray时，必须加 transfer list：worker.postMessage(buffer, [buffer])，否则仍是拷贝 - 超过 1MB 的数据，主动分块：每次传 64KB，用序号标记批次，Worker 端拼接
- 避免传
Object嵌套过深或含函数、原型链的对象；先JSON.stringify再传字符串更可控
Worker 不 terminate，内存和 CPU 悄悄吃满
Worker 实例不会自动销毁。一个未终止的 Worker 即使空闲，也占着独立 V8 实例、事件循环和堆内存；页面开 10 个没关的 Worker，等于开了 10 个 mini 浏览器进程。
- 任务完成立刻
worker.terminate()，别等 GC - 如果 Worker 需复用，改用 Worker Pool + idle timeout（例如 5 秒无消息自动
self.close()） - 页面卸载前兜底清理：
window.addEventListener('beforeunload', () => workers.forEach(w => w.terminate())) - 注意：
self.close()只在 Worker 内部有效；主线程只能调worker.terminate()
加密或计算类任务不分块，Worker 线程自己卡住 UI
Worker 是单线程的。你在里面跑一个 200ms 的 for 循环，虽然不阻塞主线程，但会饿死同 Worker 内其他消息回调（比如进度通知），而且单核 CPU 满载会影响设备温控和后台标签页调度。
- 长循环中每 1000 次迭代插入
self.postMessage({ type: 'progress', value: i })，并紧跟if (i % 1000 === 0) self.postMessage({ type: 'yield' })让出控制权（实际靠事件循环隐式 yield） - 大文件加密按 chunk 处理：
crypto.subtle.encrypt(alg, key, chunk)分批调用，而非一次性传整个ArrayBuffer - 用
navigator.hardwareConcurrency控制并发 Worker 数量，4 核机器上启 2–3 个加密 Worker 足够，再多就是线程竞争
最常被忽略的一点：Worker 脚本里的 importScripts 是同步阻塞的，一旦某个依赖加载失败或超时，整个 Worker 启动就卡死，且错误不会冒泡到主线程 onerror —— 必须在 Worker 内部用 try/catch 包住，并主动 self.postMessage({ error: 'import failed' }) 通知主线程降级处理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
