Web Worker 正确使用需规避四大反模式：一不能访问 DOM 或全局对象，须用 postMessage 通信；二避免频繁创建销毁，应复用实例；三传递数据须为可克隆纯对象，大数组优先用 transferable；四必须监听 onerror 并设置超时终止机制。
Web Worker 是解决主线程阻塞的利器，但用不好反而会引入新问题。关键不是“用了没”，而是“怎么用对”。下面几个高频反模式，开发者常踩坑，也最容易优化。
反模式一：在 Worker 里尝试访问 DOM 或全局对象
Worker 运行在独立上下文，没有 window、document、localStorage，甚至不能用 alert 或 console.log（部分浏览器限制，应改用 self.console.log）。一旦写错，代码静默失败或直接报错。
- ❌ 错误示例：
document.getElementById('result').innerText = data;（Worker 内执行） - ✅ 正确做法：所有 DOM 操作严格保留在主线程；Worker 只负责计算/解析/转换，结果通过
postMessage传回 - ? 小技巧：在 Worker 文件顶部加
'use strict';并检查typeof window === 'undefined'，可提前拦截误用
反模式二：频繁创建和销毁 Worker 实例
每次调用 new Worker() 都涉及线程启动、脚本加载、初始化开销。短时高频任务（如实时滤镜预览、输入校验）反复新建 Worker，性能可能比不使用还差。
- ❌ 错误做法：每个按钮点击都
new Worker('./ocr.js') - ✅ 推荐方案：复用 Worker 实例。Vue 场景可用
vue-worker插件自动管理生命周期；原生场景建议封装成单例或池化调度器（如 Tesseract.js 的Scheduler模式） - ? 提示：Worker 实例可多次调用
postMessage，无需为每次任务新建
反模式三：传递大量未序列化数据或引用类型
Worker 与主线程通信靠结构化克隆算法（Structured Clone Algorithm），不支持函数、DOM 节点、undefined、Symbol 等。若传入含循环引用的对象或巨型数组，要么失败，要么触发严重内存拷贝延迟。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- ❌ 危险操作：
worker.postMessage({ config, data: hugeArray, handler: () => {} }); - ✅ 安全做法：只传纯数据（POJO、
ArrayBuffer、TypedArray）。大图处理优先用transferable机制零拷贝传输：worker.postMessage(imageData, [imageData.buffer]); - ? 验证方法：主线程中用
structuredClone(obj)预检是否可跨线程传递
反模式四：忽略错误处理与超时控制
Worker 执行出错不会冒泡到主线程，onerror 事件可能被遗漏；长时间无响应也无法感知，导致 UI 假死。
- ❌ 默认状态：没设
worker.onerror，也没监听message超时 - ✅ 必做两件事：
• 主线程监听worker.onerror并记录错误详情
• 用setTimeout包裹任务请求，超时后主动worker.terminate()并提示用户 - ? 进阶建议：给 Worker 加心跳机制，定期
postMessage({ type: 'ping' })，确保其存活
避开这些反模式，Web Worker 就能真正成为后台“隐形劳模”，而不是又一个维护负担。
