WebWorker必须使用外部JS文件，通信靠postMessage，数据通过结构化克隆复制，需手动terminate()释放资源，调试需在DevTools Threads面板进行。
WebWorker 创建必须用外部 JS 文件，不能直接写内联脚本
浏览器强制要求 Worker 构造函数的参数必须是外部 JavaScript 文件路径，传入字符串字面量或内联函数都会报错：DOMException: Failed to construct 'Worker': Script at 'blob:...' cannot be accessed from origin。这是因为 Worker 运行在独立上下文，无法访问当前页面的 DOM、window 或闭包变量。
实操建议：
- 把耗时逻辑（如大数组排序、加密解密、Canvas 像素处理）单独写进一个文件，比如
processor.js - 创建时用相对路径：
const worker = new Worker('processor.js'); - 不要试图用
URL.createObjectURL(new Blob([...]))动态生成 URL —— 现代 Chrome/Firefox 虽支持，但 Safari 仍限制，且调试困难、缓存不可控
主线程与 Worker 通信只能靠 postMessage() 和 onmessage，不共享内存
WebWorker 和主线程之间没有变量共享，所有数据都通过结构化克隆算法复制传递，这意味着 Date、RegExp、Map、Set、TypedArray 等可以传，但函数、DOM 节点、undefined、function 会丢失或报错。
常见错误现象：传了带方法的对象过去，Worker 收到后方法没了；或者传了大 JSON，发现卡顿 —— 实际是克隆过程耗时，不是 Worker 执行慢。
立即学习“前端免费学习笔记（深入）”；
使用建议：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 主线程发送：
worker.postMessage({ type: 'SORT', data: [/* 10w 条数字 */] }); - Worker 内接收并响应：
self.onmessage = function(e) { if (e.data.type === 'SORT') { const result = e.data.data.sort((a, b) => a - b); self.postMessage({ type: 'SORT_DONE', result }); } }; - 避免频繁传大对象；必要时用
Transferable（如ArrayBuffer）零拷贝传输，例如：worker.postMessage(buffer, [buffer]); // buffer 将被移出主线程上下文
terminate() 必须手动调用，否则 Worker 持续占用内存和线程
Worker 启动后不会自动销毁，即使主线程导航离开页面，它仍可能运行（尤其在未监听 onmessage 或未 close() 的情况下）。长期泄漏会导致 CPU 占用升高、内存不释放。
典型场景：
- 用户快速切换页面，每次新建 Worker 但没关旧的
- 异步任务失败后忘记清理，
onerror里没调terminate() - Worker 自身陷入死循环，主线程无法强制中断，只能
terminate()
安全做法：
- 任务完成或出错后立即终止：
worker.onmessage = (e) => { if (e.data.type === 'SORT_DONE') { handleResult(e.data.result); worker.terminate(); // 主动结束 } }; - 加超时保护：
const timeout = setTimeout(() => worker.terminate(), 5000);
，并在成功响应后clearTimeout(timeout) - Worker 内部也可自我终止：
self.close(); // 在 Worker 线程中调用，等价于主线程 terminate()
调试 WebWorker 很麻烦，Chrome DevTools 需手动打开专用面板
Worker 不出现在常规 Sources 面板里，默认断点不生效，控制台日志也默认不显示 —— 容易误判“Worker 没运行”。
实操步骤：
- Chrome 中打开
DevTools → More Tools → Renderers（新版叫Sources → Threads），找到对应 Worker 标签页 - 在 Worker 脚本里加
debugger;，或直接在 Sources 面板里找到processor.js手动打断点 - 日志要用
console.log，但输出位置在 Worker 对应的 Console 子面板，不是主页面 Console - 报错堆栈默认只显示
Uncaught Error，需点开才看到完整路径；若 Worker 报错未捕获，主线程会触发worker.onerror，但错误对象不包含堆栈，得靠self.addEventListener('error', ...)捕获
真正难的不是语法，是理解它和主线程之间那层看不见的隔离边界 —— 数据怎么过、谁负责清理、出错了往哪看，这些细节不亲手试几次根本记不住。
