Web Worker 中闭包导致全局变量无法释放的本质是引用链未切断，使GC无法回收对象；关键在于闭包意外持有self、定时器、事件监听器等长期存活对象的强引用，需避免捕获全局对象、及时清理资源并谨慎处理主线程传入的函数。
Web Worker 中闭包引发的全局变量无法释放，本质是引用链未被正确切断，导致 JavaScript 垃圾回收器（GC）无法回收相关对象。关键不在于“用了闭包”，而在于闭包意外持有了本该被释放的全局或长期存活对象（如 self、postMessage 回调、定时器、事件监听器等）。
避免在闭包中长期持有对 worker 全局对象的强引用
Worker 全局作用域（self 或 globalThis）生命周期与 Worker 本身一致。若闭包内保存了 self、self.postMessage 或其他全局属性的引用，且该闭包又被长期存活的对象（如未清除的定时器、未注销的 addEventListener）所引用，就会形成内存滞留。
- ❌ 错误示例：在 setTimeout 回调中直接使用 self.postMessage，且未清理定时器
- ✅ 正确做法：用局部变量缓存必要参数，避免闭包捕获
self；或显式清除定时器（clearTimeout）和监听器（removeEventListener） - ⚠️ 注意：
self在 Worker 中不可被 delete，但可主动置为null（仅限你创建的引用变量），帮助 GC 判断可达性
谨慎处理从主线程传入的函数或对象
主线程通过 postMessage 传递的数据默认是结构化克隆，但若使用 transferable（如 ArrayBuffer）或 SharedArrayBuffer，就可能引入跨线程共享状态。更危险的是——主线程传入一个函数（例如通过 eval、Function 构造或序列化再还原），该函数若闭包捕获了主线程环境中的变量（即使只是隐式），将因跨上下文无法回收而造成泄漏。
- ❌ 避免接收并执行主线程传来的任意函数（尤其是带闭包的箭头函数字符串）
- ✅ 接收纯数据（JSON-safe 对象）、预定义消息类型（如
{ type: 'PROCESS', payload: ... }），在 Worker 内部用固定逻辑处理 - ✅ 如需动态逻辑，改用 WebAssembly 模块或预编译的策略函数表，而非运行时构造闭包
及时清理闭包依赖的外部资源
闭包本身不可怕，可怕的是它让外部资源“活”得比预期更久。常见泄漏源包括：
- 未清除的
setInterval/setTimeout（尤其回调中引用了大数组、DOM-like 对象或self） - 注册了
self.addEventListener('message', handler)却未配对调用removeEventListener（尤其在多次初始化场景下） - 闭包中持有大型计算中间结果（如
new Map()、new ArrayBuffer）且未在任务结束后清空 - 使用
importScripts动态加载脚本后，脚本内定义的全局函数/变量仍驻留于 Worker 全局作用域
验证是否已释放：用 Chrome DevTools 快速定位
Worker 内存泄漏不易察觉，但可通过以下方式确认：
- 打开 DevTools → Memory → Take Heap Snapshot，筛选
WorkerGlobalScope或查找疑似泄漏对象（如重复出现的闭包、未释放的ArrayBuffer） - 在 Performance 面板录制一段典型工作流，查看 JS heap 是否阶梯式上涨且不回落
- 在代码中添加
console.count('worker-init')和console.timeEnd('task')，配合self.close()后观察是否仍有活跃计时器或监听器残留
