Web Worker 不能直接写在 HTML 中且必须通过 HTTP/HTTPS 加载，file:// 协议被浏览器禁止，报错“Script at 'file://' cannot be accessed from origin 'null'”；需用本地服务器（如 http-server）运行，并推荐 new Worker(new URL('./worker.js', import.meta.url)) 写法。
Web Worker 不能替代主线程做 DOM 操作，也不适合处理小任务——它只在「主线程明显卡顿」时才值得引入。
为什么 new Worker('./worker.js') 在本地双击打开就报错？
因为 file:// 协议被浏览器硬性禁止加载 Worker 脚本，错误信息是：Failed to construct 'Worker': Script at 'file:///' cannot be accessed from origin 'null'。
- 必须用本地服务启动：比如
npx http-server、VS Code 的 Live Server 插件，或 Vite/webpack dev server - 路径别写相对字符串：像
new Worker('./worker.js')在 ESM 环境（Vite、Webpack）下可能解析失败 - 最稳写法是
new Worker(new URL('./worker.js', import.meta.url))，它由浏览器原生解析，绕过构建工具路径歧义 - 绝对不能用 CDN 地址（如
https://cdn.example.com/worker.js），即使加了 CORS 头也会被拒绝——new Worker()只认同源脚本
主线程发了 postMessage，Worker 却收不到？
常见原因是监听器注册时机不对，或者 Worker 内根本没绑定 self.onmessage。
- 主线程必须在
postMessage()之前设置监听：先worker.onmessage = ...或worker.addEventListener('message', ...)，否则第一次消息直接丢失 - Worker 文件里不能只写
console.log('loaded')就以为逻辑跑起来了——必须显式写self.onmessage = ...或self.addEventListener('message', ...) - 如果用了
importScripts()加载依赖，确保脚本执行完毕后再绑定onmessage，否则可能因执行顺序问题漏绑 - 调试时可在 Worker 开头加
console.log(self)确认全局对象存在，但注意：仅 log 不等于已监听
传大数组进 Worker 为什么页面卡住几百毫秒？
因为默认走结构化克隆（structured clone），深拷贝 10MB 数组会同步阻塞主线程。
立即学习“前端免费学习笔记（深入）”；
- 能转移的 ArrayBuffer 必须显式传入
postMessage()第二个参数：worker.postMessage(data, [data.buffer]) - 转移后主线程的
data.buffer变成null，不能再读——这是设计使然，不是 bug - 普通
Array、Object、TypedArray（非 ArrayBuffer 底层）无法转移，只能拷贝；想避免卡顿，得提前转成Uint8Array+ArrayBuffer - 若数据量超过 100MB，建议分块传输，Worker 端用
self.onmessage累积拼接，而不是一次性塞进去
Worker 报错却没任何提示？
Worker 内未捕获的异常默认静默，主线程也收不到通知，除非你主动监听。
- 主线程要加
worker.onerror = e => console.error('Worker error:', e.message) - Worker 内建议统一兜底：
self.onerror = e => self.postMessage({ type: 'error', message: e.message }) -
self.onunhandledrejection同样需要手动监听，Promise reject 不会自动冒泡到主线程 - Chrome 调试必须去
Sources → Page → workers面板找对应 Worker，它不会出现在常规Console或Network中
Worker 本身没有生命周期管理能力，self.close() 或 worker.terminate() 必须由业务代码明确触发；没人关它，它就一直占着线程资源——这点容易被忽略，尤其在 SPA 页面跳转后。
