Web Worker 不会自动关闭，必须由开发者显式终止；其资源回收依赖主线程调用 terminate() 或页面卸载时浏览器清理，专用 Worker 持续运行直至 terminate()、页面关闭或未捕获异常（不可靠），无空闲超时机制，Shared Worker 依引用计数回收，主动管理是唯一可靠手段。
Web Worker 不会自动关闭，必须由开发者显式终止；它的资源回收依赖于主线程主动调用 terminate() 或页面卸载时浏览器的清理行为。
Worker 生命周期由创建者控制
专用 Worker（Dedicated Worker）一旦创建，就会持续运行，直到以下任一情况发生：
- 主线程调用
worker.terminate()—— 这是最直接、最可靠的关闭方式，立即销毁 Worker 线程及其全部执行上下文； - 创建它的页面被完全关闭（如标签页关闭、导航跳转），此时浏览器通常会自动回收该 Worker 的线程和内存；
- Worker 自身抛出未捕获异常且未监听
onerror，部分浏览器可能终止它，但行为不统一，不可依赖。
没有“空闲超时”或后台 GC 触发机制
Worker 不像服务端进程那样具备空闲自动销毁能力。即使它长时间没有收到消息、也没有执行任务，线程仍驻留内存中：
- 浏览器不会因“无 activity”而自动终止 Worker；
- JavaScript 引擎的垃圾回收（GC）只负责 Worker 内部对象（如数组、闭包），不会回收整个 Worker 实例；
- 线程资源（CPU 时间片、栈空间、JS 执行环境）持续占用，长期闲置会造成隐性资源浪费。
Shared Worker 的特殊回收逻辑
共享 Worker 的生命周期独立于单个页面，其存活取决于是否有至少一个上下文保持连接：
- 当所有引用它的页面/iframe/Worker 都断开连接（调用
port.close()或页面卸载），浏览器才会释放该 Shared Worker； - 它不响应
terminate()（因为没有单一 owner），只能靠引用计数归零后由浏览器回收； - 若某个页面忘记调用
port.start()后再port.close()，可能导致连接泄漏，延长 Shared Worker 存活时间。
主动管理是唯一可靠手段
为避免内存泄漏和性能损耗，建议在业务逻辑明确结束时主动终止：
- 任务完成回调中调用
self.close()（Worker 线程内）； - 主线程监听任务完成消息后，立即执行
worker.terminate()； - 在页面
beforeunload或组件unmounted钩子中做兜底清理； - 对频繁启停的场景，可复用 Worker 实例（而非反复新建），减少线程创建开销。
