Web Worker的核心价值是将CPU密集型任务移出主线程以解决卡顿，适用纯计算、无DOM依赖、数据可序列化的场景，需合理设计通信、管理生命周期并做好兼容性兜底。
Web Worker 的核心价值不是“多开几个线程”，而是把真正拖垮页面的 CPU 密集型任务，干净利落地移出主线程。它不解决所有性能问题，但对卡顿类问题几乎是立竿见影的解药。关键在于选对场景、建好通信、管住资源。
哪些任务值得交给 Worker
不是所有耗时操作都适合 Worker——重点看是否满足三个条件：纯计算、无 DOM 依赖、数据可序列化。
- 典型适用场景：大数组排序/过滤（如万级商品实时搜索）、图像像素处理（灰度、锐化）、CSV/JSON 数据解析与清洗、RSA/AES 加解密、质数检测、物理模拟、WASM 模块调用
-
明显不适用场景：需要修改 DOM 的动画控制、调用
localStorage.getItem（同步阻塞）、操作document或window对象、频繁读写 cookie -
容易误判的灰色地带：
fetch请求本身可放 Worker，但若后续要直接插入 HTML 字符串到页面，就得拆成两步——Worker 处理响应体，主线程负责渲染
通信设计不能只图简单
消息传递不是“发完就完”，它是 Worker 性能的隐形瓶颈。结构化克隆虽方便，但大数据量下序列化/反序列化开销显著。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 避免反复传整个大数组，改用
postMessage(data, [data.buffer])实现零拷贝传输（适用于ArrayBuffer、ImageBitmap等） - 给消息加明确类型字段，例如
{ type: 'FILTER_START', payload: { keyword: 'abc', items: [...] } }，方便 Worker 内部路由和调试 - 不要在 Worker 中用
console.log打印巨型对象，会触发深度克隆并拖慢通信；改用采样日志或仅打印摘要
Worker 生命周期必须主动管理
一个没被终止的 Worker 会持续占用内存和线程资源，尤其在 SPA 页面中反复创建却未销毁，极易引发内存泄漏。
- 任务完成后立即调用
worker.terminate()，而不是等 GC —— Worker 不会自动销毁 - 对于需复用的场景（如高频图像处理），用 Worker Pool 管理固定数量实例，避免反复创建/销毁开销
- 监听
worker.onerror和worker.onmessage的异常分支，失败时也要确保清理逻辑执行
调试与兼容性要提前兜底
Worker 在 Chrome/Firefox/Edge 中支持良好，但 iOS Safari 对某些 API（如 OffscreenCanvas）支持有限，且调试体验远不如主线程。
- 创建前先检测：
if (typeof Worker !== 'undefined')，不支持时降级为主线程分片执行（requestIdleCallback或setTimeout分帧） - 利用浏览器开发者工具的 “Application → Service Workers” 或 “Sources → Workers” 面板查看运行中的 Worker，断点调试需在 Worker 脚本内设置
- Worker 内不可用
localStorage，但可用IndexedDB；不可用document，但可用self.location获取当前脚本 URL
