让主线程喘口气：Web Worker 计算卸载与任务池调度实战
一、当主线程被十万行排序拖死：计算卸载的必要性
某 SaaS 数据看板项目曾出过一次事故。业务方在筛选器里选了"全量按月聚合"，前端拿到的数据是 18 万行。一次多字段 group 加自定义 reduce 跑下来，主线程卡了 4.2 秒。期间页面完全无响应，连按钮 hover 都不亮。用户连点三次"导出"，最后浏览器弹出"页面无响应"提示。
这事我见过太多团队栽进去——把重计算硬塞进主线程，以为现代 JS 引擎够快。但 V8 单线程语义决定了主线程要同时承担 JS 执行、布局计算、合成层绘制与事件分发。一段占用 200 毫秒以上的同步任务，会让 60 帧每秒的帧预算直接归零。
更隐蔽的问题是交互延迟。即使数据量小到几千行，复杂的自定义聚合在频繁筛选场景下也会被反复触发。用户每改一次条件就拖 80 毫秒，体感是"系统在抖"。低端机上更明显，单次筛选能把整个标签页冻结。
把这类计算搬到 Web Worker，是当前唯一的工程化解法。但搬到 Worker 不等于万事大吉。postMessage 的序列化开销、Transferable 的所有权边界、SharedArrayBuffer 的安全约束，每一项都可能让"卸载"反而变慢。本文把这条路上的关键决策讲清楚。
二、底层机制：postMessage 序列化代价与零拷贝通道
postMessage 默认走结构化克隆算法。它会对传入对象做深拷贝，递归遍历每个字段。10 万行的二维数组克隆耗时大约在 30 到 80 毫秒区间，且会按数据规模线性增长。也就是说，主线程在派发任务时仍要付出序列化时间，只是后续计算不再阻塞渲染而已。
当数据规模进一步上涨，序列化本身可能比计算还贵。这时要切换到 Transferable Objects。把 ArrayBuffer、MessagePort、ImageBitmap 等可转移对象交给 Worker。通过 transfer 数组传递，主线程不再持有原对象，无需拷贝。零拷贝代价，但代价是所有权转移：主线程拿不到原 buffer 了。
对共享读写场景，SharedArrayBuffer 加 Atomics 是更彻底的方案。主线程与 Worker 共享同一段内存，读写无需拷贝。但 SharedArrayBuffer 要求跨域隔离环境，必须在响应头里配置 COOP 与 COEP。一旦配置不完整，浏览器会静默禁用，不少团队上线时发现 SAB 直接不可用，就是没配这两个头。
任务池的必要性在于：每次新建 Worker 都要拉脚本、初始化 isolate，开销在 50 到 200 毫秒。复用固定数量的 Worker，能把"启动开销"摊薄到首次访问。任务池还要负责超时兜底。Worker 内的同步死循环会卡住整个 isolate，外部必须用 timer 强制中止并销毁重建。
综上，Worker 卸载重计算的关键在四件事：postMessage 默认走结构化克隆、大数据要切 Transferable 做零拷贝、共享场景用 SharedArrayBuffer 但必须配齐 COOP/COEP、任务池复用固定 Worker 并做超时兜底与死循环重建。把序列化、所有权与隔离约束理清楚，计算才真正从主线程卸下来。
三、生产级代码：支持超时与错误兜底的 Worker 任务池
下面给出一个可复用的任务池。它预热固定数量 Worker，支持 Transferable 零拷贝、超时兜底与异常重建。
// 任务池：复用固定数量 Worker，支持 transfer 零拷贝、超时与异常兜底 export interface TaskResult<T> { ok: boolean; data?: T; error?: string; } export class WorkerPool<TInput, TOutput> { private workers: Worker[] = []; private idle: Worker[] = []; // 任务 id → resolver，用于把回包路由到对应 Promise private pending = new Map<string, (r: TaskResult<TOutput>) => void>(); // 任务 id → timer，超时主动销毁卡死的 Worker private timers = new Map<string, ReturnType<typeof setTimeout>>(); private seq = 0; constructor( private url: string, // 留一核给主线程做事件分发，避免全部抢占 private size = Math.min(4, (navigator.hardwareConcurrency || 2) - 1), private timeoutMs = 10_000, ) { // 启动期就预热 Worker，避免首任务承担初始化开销 for (let i = 0; i < this.size; i++) { const w = new Worker(url, { type: 'module' }); w.onmessage = (e) => this.onDone(e.data); w.onerror = (err) => this.onCrash(w, err); this.workers.push(w); this.idle.push(w); } } // 提交任务：data 走结构化克隆，transfer 列表走零拷贝 submit(data: TInput, transfer: Transferable[] = []): Promise<TaskResult<TOutput>> { const id = String(++this.seq); return new Promise((resolve) => { this.pending.set(id, resolve); // 超时兜底：Worker 内死循环时 isolate 无法被中断，只能销毁重建 this.timers.set(id, setTimeout(() => this.onTimeout(id), this.timeoutMs)); const w = this.acquire(); w.postMessage({ id, data }, transfer); }); } private acquire(): Worker { // 池里有空闲就复用，否则退化到复用第一个（生产实现可改 Promise 队列） const w = this.idle.pop(); return w ?? this.workers[0]; } private onDone(msg: { id: string; ok: boolean; data?: TOutput; error?: string }) { const resolve = this.pending.get(msg.id); if (!resolve) return; // 已被超时清理，丢弃迟到回包避免污染 clearTimeout(this.timers.get(msg.id)!); this.timers.delete(msg.id); this.pending.delete(msg.id); resolve({ ok: msg.ok, data: msg.data, error: msg.error }); } private onTimeout(id: string) { const resolve = this.pending.get(id); if (!resolve) return; this.pending.delete(id); this.timers.delete(id); resolve({ ok: false, error: 'worker timeout' }); // 超时意味着 isolate 卡死，必须销毁该 Worker 并重建 this.replaceWorker(); } private onCrash(w: Worker, err: ErrorEvent) { console.error('[WorkerPool] crash', err.message); if (this.workers.includes(w)) this.replaceWorker(w); } private replaceWorker(old?: Worker) { if (old) { const i = this.workers.indexOf(old); if (i >= 0) this.workers.splice(i, 1); const j = this.idle.indexOf(old); if (j >= 0) this.idle.splice(j, 1); old.terminate(); } const w = new Worker(this.url, { type: 'module' }); w.onmessage = (e) => this.onDone(e.data); w.onerror = (e) => this.onCrash(w, e); this.workers.push(w); this.idle.push(w); } dispose() { this.workers.forEach((w) => w.terminate()); this.workers = []; this.idle = []; this.pending.clear(); this.timers.forEach((t) => clearTimeout(t)); this.timers.clear(); } }Worker 端脚本骨架如下：
// worker.ts：执行单元，统一 try/catch 防止 isolate 静默崩溃 self.onmessage = (e: MessageEvent<{ id: string; data: unknown }>) => { const { id, data } = e.data; try { const result = heavyCompute(data); (self as unknown as Worker).postMessage({ id, ok: true, data: result }); } catch (err) { // 异常必须显式回传，否则主线程 Promise 永远悬挂 (self as unknown as Worker).postMessage({ id, ok: false, error: (err as Error).message }); } }; function heavyCompute(input: unknown): unknown { // 实际业务里的排序、聚合、分组逻辑 return input; }关键点三处。其一，预热 Worker 把初始化开销摊到启动期。其二，超时兜底是硬性要求，否则 isolate 内死循环会把整个任务卡死。其三，回包必须按 id 路由，超时后的迟到回包要丢弃，否则会污染下一次 resolve。
四、边界分析：通信开销临界点与零拷贝的代价
Worker 不是万能加速器。当任务本身执行时间低于 5 毫秒，postMessage 的序列化与调度开销，会让总耗时反而高于主线程直接执行。临界点经验值：纯计算耗时低于 16 毫秒（一帧预算）的小任务，留在主线程更划算。只有当计算预期超过两帧（33 毫秒），卸载收益才稳定为正。
Transferable 也有代价。所有权转移后，主线程不能再用原 buffer，这在数据需要多次复用的场景下不友好。例如一份待多次聚合的源数据，转移一次就要在主线程侧维护一份副本，反而增加内存。这时应优先考虑 SharedArrayBuffer 共享，而不是 Transferable。
SharedArrayBuffer 的限制更硬。COOP 与 COEP 头要求服务端配合，部分 CDN 与第三方资源（字体、外链图片）会让隔离失败。一旦失败，浏览器会静默禁用 SAB。线上排查时这是高频盲区，必须用crossOriginIsolated全局变量主动探测。
任务池的并发数也要克制。盲目开 8 个 Worker 在 4 核机器上会被操作系统调度抢占，反而拉低吞吐。经验值是min(4, hardwareConcurrency - 1)，留一核给主线程做事件分发。超过这个值后边际收益接近零。
适用边界：单次计算大于 33 毫秒、数据可序列化、结果可批量回传的场景收益最高。例如离线数据分析看板、大文件解析、复杂聚合。对实时性要求极强（小于 16 毫秒响应）的交互，主线程直接执行更稳。
五、总结
Web Worker 的核心价值是把重计算与渲染解耦。落地建议：第一，按min(4, hardwareConcurrency - 1)预热固定数量 Worker，避免频繁创建销毁。第二，超过 33 毫秒的任务再卸载，小任务留在主线程。第三，能用 Transferable 就别走结构化克隆，零拷贝在大数据场景收益显著。第四，超时兜底不可省，isolate 死循环只能靠销毁重建。第五，SharedArrayBuffer 上线前先探测crossOriginIsolated，COOP 与 COEP 配置是前置条件。最终在主线程流畅度、通信开销与内存占用之间取得平衡。这条路在十万级数据计算下能跑通，回报是值得的。
