Web Worker 内存泄漏主因是终止不及时、不明确、不彻底；应于主线程确认无后续用途时立即调用 terminate() 并置 worker 为 null，取消操作或组件卸载时必须强制终止，不可依赖 self.close() 或自动回收。
Web Worker 内存泄漏往往不是因为“忘了关”，而是关得不及时、不明确、不彻底。主动调用 terminate() 是最直接的释放手段，但它的最佳时机不是任务结束“之后”，而是在主线程确认 Worker 已无后续用途的“那一刻”——哪怕任务还没开始，或刚发完消息就取消。
任务明确结束时立即终止
当 Worker 完成计算、返回结果、且主线程已收到 final 消息后，应立刻调用 terminate()。不要等用户操作、不依赖超时兜底、不指望 Worker 自己 close。
- 收到
{ status: 'done', result: ... }后，马上执行worker.terminate() - 避免写成 “收到结果 → 更新 UI → 几秒后再 terminate”，延迟会增加意外引用或重复使用的风险
- 调用后立即将 worker 变量置为
null，防止后续误调postMessage()报错
用户主动取消或流程中断时果断终止
用户点击“取消”“停止”“重试”或页面跳转、组件卸载时，Worker 很可能还在运行（尤其含 fetch、轮询、长循环）。此时不能只发 cancel 指令，必须配合 terminate() 确保线程真正退出。
- 例如：上传预处理中用户关闭弹窗 → 主线程先发
{ type: 'cancel' }，再立刻worker.terminate() - React 组件
useEffect的清理函数、VueonBeforeUnmount中，必须包含worker?.terminate() - 注意：cancel 消息只是协作提示，
terminate()才是强制保障
避免隐式泄漏：无引用即终止
有些场景下 Worker 创建后只用一次，但主线程未保存引用（比如 new Worker('./calc.js') 后没赋值给变量），这会导致线程持续运行却无法控制——浏览器不会自动回收。
- 永远用
const worker = new Worker(...)显式持有引用 - 若确为一次性使用（如启动时做环境检测），创建后立即
worker.terminate()，哪怕不发任何消息 - 在插件或模块化场景中（如 VS Code 扩展），确保
deactivate()钩子中遍历并终止所有已创建的 Worker 实例
别等 Worker 自己 close，除非你完全掌控流程
self.close() 是安全退出方式，但它依赖 Worker 内部逻辑配合：要监听消息、检查状态、等待当前同步代码完成。一旦 Worker 卡在死循环、Promise pending 或未响应的 fetch 中，self.close() 就永远不会执行。
- 纯计算型任务（如大数组排序）无法插入检查点 → 必须靠
terminate()强制退出 - 含异步操作的任务，可先发指令让 Worker 尝试
self.close()，但设 100–200ms 超时，超时后仍调用terminate() - 不要把
self.close()当作默认方案；terminate()才是主线程该承担的资源管理责任
