闲置Web Worker是否有显著性能开销？是否需调用worker.terminate()？

你提到创建新Worker耗时约200ms、闲置Worker在数量可控时对性能影响不大，这个观察是符合实际场景的，但在某些情况下，调用worker.terminate()确实有性能层面的必要性，具体如下：

• 内存资源累积占用：每个Worker哪怕处于闲置状态，也会占用独立的内存空间——包括它的全局作用域、已加载的脚本、初始化时创建的变量等。如果你的应用长期保留大量闲置Worker，哪怕数量没到2500的崩溃阈值，累积的内存占用会挤压主线程和其他关键进程的可用内存，导致系统在内存紧张时垃圾回收（GC）的频率升高，而GC过程可能引发短暂卡顿，尤其是在低配置设备上。
• 线程调度的隐性开销：浏览器的线程池存在上限，闲置Worker虽然不占用CPU执行时间，但浏览器仍需维护这些线程的调度元数据。当系统有大量后台任务（比如其他标签页的进程）时，过多的闲置Worker会增加线程调度的复杂度，可能导致真正需要执行的任务（比如新的Worker任务或主线程高优先级任务）被延迟调度。
• 资源受限环境的竞争问题：在移动设备、老旧PC这类资源受限的环境中，即使是几百个闲置Worker，也可能和主线程或其他关键进程竞争系统资源（如内存带宽、CPU缓存）。比如设备处于低电量模式时，浏览器会限制后台线程的资源分配，过多闲置Worker可能被系统强制回收，反而不如主动terminate后按需创建更可控。
• 潜在内存泄漏的风险：如果Worker内部存在隐性内存泄漏（比如未清理的定时器、闭包引用、未关闭的WebSocket连接等），闲置状态下这些泄漏会持续累积，长期保留Worker会导致内存占用持续增长，最终影响应用稳定性。主动调用worker.terminate()可以彻底清除这些潜在的泄漏点。

当然，如果你的应用场景中Worker复用频率极高，且能严格控制闲置Worker的数量（比如维持在几十到几百个的合理范围），保留Worker复用确实能节省创建开销。但从长期性能和稳定性角度，当Worker确定不再被使用时，调用worker.terminate()是更稳妥的选择。

内容的提问来源于stack exchange，提问作者Isaac King