应使用线程池管理 Worker：按 hardwareConcurrency 预建实例，空闲超 30 秒自动 terminate，卸载前统一清理；合并任务、用 Transferable 传 ArrayBuffer、缓存中间结果；通过 DevTools 监控 GC 次数、耗时及内存分配。
用线程池代替频繁新建
每次 new Worker() 都会初始化独立 JS 引擎实例，触发内存分配和上下文构建，任务一多，GC 压力就明显上升。更优做法是预先创建一组 Worker 实例，组成可复用的线程池。比如根据设备 CPU 核心数动态设定数量：
- 通过 navigator.hardwareConcurrency 获取核心数（通常为 4–16），池大小设为该值或其 1.5 倍
- 首次需要时批量创建，后续任务从空闲 Worker 中取用，执行完不销毁，而是标记为“就绪”状态
- 配合简单队列管理，避免多个任务争抢同一 Worker
主动控制 Worker 生命周期
不使用的 Worker 若长期闲置，仍会占用内存并可能被 GC 扫描。应设置超时机制，在空闲超过一定时间后手动终止：
- 每个 Worker 绑定一个定时器，收到任务时重置；空闲超 30 秒自动 terminate()
- 页面卸载前统一清理：window.addEventListener('beforeunload', () => pool.forEach(w => w.terminate()))
- 避免依赖浏览器自动回收，防止 GC 在关键时刻集中触发
减少通信带来的隐性开销
高频 postMessage 不仅增加主线程调度负担，还会引发大量序列化/反序列化，间接推高 GC 频率：
- 合并小任务：把多次轻量计算打包成单次消息，例如分批处理数组时，一次传入 1000 条而非逐条发送
- 用 Transferable 对象传递 ArrayBuffer 类数据，避免拷贝，直接移交内存所有权
- Worker 内部尽量缓存中间结果，避免重复计算后反复回传相同结构数据
监控与验证优化效果
是否真缓解了 GC 卡顿，不能只看页面是否“顺”，要观察底层指标：
- 在 Chrome DevTools 的 Memory 面板中开启 “Record allocation stack traces”，定位高频分配对象来源
- 使用 Performance 面板录制操作，筛选 “Garbage Collection” 事件，对比优化前后 GC 次数与耗时
- 监听 Long Tasks API，确认 50ms 以上任务是否显著减少
