内联 worker 脚本须完全自包含，用模板字符串定义并避免全局对象；blob mime 类型必须为"application/javascript"，使用后需调用worker.terminate()和url.revokeobjecturl()清理；通信应通过postmessage传递结构化数据而非拼接脚本。
脚本字符串必须完全自包含
内联 Worker 的代码不能访问主线程的变量、函数或闭包，所有逻辑必须写在字符串内部。常见做法是用模板字符串包裹整个脚本，支持换行和注释，但要注意引号嵌套问题。例如：
- 使用反引号定义脚本，内部可写
self.onmessage和纯函数 - 避免直接写
console.log以外的全局对象（如document、window），它们在 Worker 环境中不可用 - 若需复用函数逻辑，把函数体转为字符串拼入，而不是调用外部
toString()后直接插入——后者可能丢失作用域或上下文
Blob 类型与 URL 生命周期管理
MIME 类型必须明确设为"application/javascript"，部分浏览器对"text/javascript"有兼容性，但严格场景下会报错。生成的 Blob URL 是临时的，绑定当前文档生命周期，页面关闭即失效。频繁创建 Worker 时容易内存泄漏，所以务必手动清理：
- 每次用完 Worker 后调用
worker.terminate() - 紧接着调用
URL.revokeObjectURL(blobUrl)释放引用 - 不建议依赖自动回收，尤其在单页应用中反复创建/销毁 Worker 的场景
通信设计优先于代码拼接
不要为了“传参”把数据拼进脚本字符串里，容易引发语法错误或 XSS 风险。正确方式是保持 Worker 脚本静态，所有动态输入走postMessage：
- Worker 内统一用
e.data接收结构化数据（数组、对象、TypedArray 均可） - 主线程发送前可做预处理，比如将配置项序列化为普通 JS 对象
- 如需初始化参数，可在
onmessage首次触发时判断并缓存，后续复用
调试与模块化替代方案
Blob URL 在 Chrome DevTools 的 Sources 面板中可见，但断点调试不如外部文件直观。若逻辑复杂，可考虑以下替代路径：
- 开发阶段先写成独立
.js文件，验证逻辑后再转为字符串 - 用
import()动态加载 ES 模块 Worker（现代浏览器支持，需设置type: "module"） - 借助
threads.js等库封装 Blob Worker 创建流程，隐藏底层细节，提升可维护性
