Web Worker 是 JavaScript 在浏览器中实现后台计算的唯一标准方案，通过隔离线程与消息通信将 CPU 密集型任务移出主线程，不可访问 DOM、window、本地文件，不共享内存，须同源；典型流程为拆逻辑、建通信、接结果，并需错误兜底、资源回收、模块化支持和高效数据传递。
Web Worker 不是“多线程编程”的全貌，而是 JavaScript 在浏览器中实现后台计算的**唯一标准方案**。它不改变 JS 单线程本质，而是通过隔离线程 + 消息通信，把 CPU 密集型任务“搬出”主线程。系统学习的关键不是堆概念，而是建立“什么时候用、怎么拆、如何联、怎样收”的闭环认知。
明确使用边界：先知道它不能做什么
新手常踩的坑，是试图让 Worker 做它根本做不到的事。务必牢记以下限制：
- 不能访问 DOM（document、element、querySelector 都报错）
- 没有 window 对象（alert、prompt、open 等全部不可用）
- 无法读取本地文件（file:// 协议下 new Worker() 直接失败）
- 不能直接共享变量或函数（主线程和 Worker 内存完全隔离）
- 脚本必须同源（CDN 上的 worker.js 若跨域，需转成 Blob URL 或内联字符串）
掌握最小可行流程：三步写通一个真实例子
跳过“Hello World”，直接从一个典型卡顿场景切入：前端对 10 万条数字做快速排序并返回前 100 个最大值。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
第一步：拆逻辑——把排序逻辑单独写进
sort-worker.js，只保留纯计算，不碰任何 DOM -
第二步：建通信——主线程用
worker.postMessage({data: [...], limit: 100})发送；Worker 用self.onmessage接收，处理完再self.postMessage(result)回传 -
第三步：接结果——主线程监听
worker.onmessage，拿到结果后只做 DOM 更新（比如插入到<pre>标签），绝不把计算逻辑塞回来
进阶必备能力：不只是“能跑”，还要“可控、可测、可维护”
项目级使用需要补上四块关键拼图：
-
错误兜底：监听
worker.onerror，捕获语法错误或运行时异常，避免 Worker 静默失败 -
资源回收：任务结束后调用
worker.terminate()，防止长期驻留消耗内存（尤其在 SPA 页面跳转时） -
模块化支持：用
new Worker('worker.js', {type: 'module'})加载 ES Module，方便复用工具函数或第三方轻量库 -
数据高效传递：大数组、TypedArray 等支持
transferable（如postMessage(arr, [arr.buffer])），避免拷贝开销
实战中自然延伸：遇到问题再学对应解法
不需要一开始就啃透 SharedWorker 或 Worker Pool。按真实需求逐步扩展：
- 发现多个按钮都触发同类计算 → 抽离成通用 Worker 类，封装
run(task)方法 - 单个 Worker 处理不过来 → 尝试用 2–4 个 Worker 组成简易池子，轮询分发任务
- 需要加载 npm 包（如 mathjs）→ 引入
workerize-loader（Webpack）或@vue/web-worker（Vite）自动打包 - 调试困难 → 在 Worker 中加
console.log，Chrome DevTools 的 “Application → Service Workers” 标签下可查看 Worker 线程日志
