原文链接用 Web Workers 优化前端重计算任务避免主线程卡顿的实战方案前端性能问题中有一类问题很容易被忽略接口很快、组件也没有明显的重复渲染但用户一输入筛选条件、拖动时间范围或切换图表维度页面就会短暂“失去响应”。这通常不是网络慢而是CPU 密集型 JavaScript 长时间占用了主线程。浏览器主线程需要处理输入事件、执行 JavaScript、进行样式计算、布局和绘制当一次计算持续太久新的点击、键盘输入和下一帧渲染都只能排队。长任务会拉长交互延迟并可能恶化 INPInteraction to Next Paint。web.dev 对主线程与 Worker 的说明Web Worker 的价值不在于“让代码神奇地更快”而在于将不依赖 DOM 的重计算移出 UI 线程让主线程优先服务交互与渲染。本文以“大数组筛选与聚合”为例给出一套可扩展到图表预处理、富文本解析、地理数据计算、本地规则引擎等场景的工程化方案。先判断这个任务真的适合放进 Worker 吗适合迁移的任务通常同时满足以下条件CPU 密集处理时间随数据量明显增长例如排序、聚合、解析、编码、规则匹配、图像或二进制数据处理。计算相对独立输入数据准备好后任务可以在后台独立执行。不需要直接访问 DOMDedicated Worker 运行在独立的全局上下文中不能直接读写window、document或页面节点。单次任务足够重收益能够抵消 Worker 创建、脚本加载和消息传输带来的额外成本。以下场景则不应第一时间搬进 Worker网络请求等待、轻量级格式化等非 CPU 瓶颈高频触发、每次仅耗时几毫秒的小任务必须同步读取布局、操作 DOM或依赖框架渲染上下文的逻辑算法本身存在明显低效问题例如本可使用索引或线性扫描解决却采用多重嵌套遍历。Worker 是线程隔离工具不是算法优化的替代品。先减少无效计算再决定是否迁移。不要凭感觉迁移先建立性能基线打开 Chrome DevTools 的Performance面板录制一次可稳定复现的操作例如输入搜索词、切换筛选条件或拖动图表范围。重点观察主线程是否存在长任务持续超过 50ms 的任务值得重点排查。火焰图中的耗时函数排序、序列化、数据转换、正则解析或循环计算是否集中出现在输入事件回调中。交互是否被阻塞用户输入到下一次可见绘制之间是否存在明显空档。端到端完成时间从用户发起操作到最终结果渲染完成不能只看某个函数的执行时间。Long Task 并不自动等于“必须使用 Worker”。如果一个任务能被拆成多个短任务并主动让出主线程也可能改善输入响应但对于持续的大规模计算将工作移到 Worker 往往更直接。长任务与任务拆分的优化方法实战场景大数组聚合为什么会卡住页面假设页面展示订单分析结果。用户持续输入搜索词时需要在几十万条记录中完成名称匹配按城市聚合金额按聚合金额排序返回图表需要的序列。如果业务还要展示命中的订单明细再单独对明细排序不要在只需要城市聚合结果时先对全部命中订单排序因为这会引入不必要的O(n log n)开销。如果以下逻辑直接运行在输入事件中计算期间主线程无法及时处理下一次键盘事件也无法绘制 loading 状态function recalculateOnMainThread(rows: Order[], keyword: string) { const normalized keyword.trim().toLowerCase(); const totals new Mapstring, number(); for (const row of rows) { if (!row.customerName.toLowerCase().includes(normalized)) continue; totals.set(row.city, (totals.get(row.city) ?? 0) row.amount); } return [...totals.entries()] .map(([city, amount]) ({ city, amount })) .sort((a, b) b.amount - a.amount); }问题不在于这段代码不能运行而在于数据量上来后它会在一个主线程任务中连续执行。用户随后输入的新字符即使只需要更新输入框也得等这一轮计算结束。Worker 的基本模型计算在线程外UI 仍留在主线程Dedicated Worker 与页面通过postMessage()和message事件通信。默认情况下消息数据会经过结构化克隆接收方得到的是独立的数据副本而非发送方对象的同一引用。Worker 可以执行计算并回传结果但不能直接操作 DOM。MDNUsing Web Workers推荐将通信设计成显式协议而不是随意发送裸对象// worker-protocol.ts export type Order { id: string; customerName: string; city: string; amount: number; }; export type StartTaskMessage { type: start; taskId: string; version: number; keyword: string; rows: Order[]; }; export type CancelTaskMessage { type: cancel; taskId: string; }; export type MainToWorkerMessage StartTaskMessage | CancelTaskMessage; export type WorkerToMainMessage | { type: progress; taskId: string; version: number; progress: number } | { type: result; taskId: string; version: number; data: Array{ city: string; amount: number }; } | { type: cancelled; taskId: string; version: number } | { type: error; taskId: string; version: number; message: string };这里有三个关键字段taskId标识一次具体任务便于取消、超时、日志关联以及精确判断消息是否属于当前任务。version代表当前 UI 输入版本避免旧结果覆盖新状态。type让进度、结果、错误和取消成为可区分的消息类型。使用模块 Worker主线程只负责调度与提交 UI 状态在 Vite 与 webpack 5 中都可以使用接近浏览器标准的模块 Worker 写法const worker new Worker( new URL(./analytics.worker.ts, import.meta.url), { type: module }, );Vite 推荐在new Worker()中使用new URL()webpack 5 也原生支持这一模式无需旧版的worker-loader。Vite Worker 文档webpack Web Workers 指南主线程封装可以这样写import type { MainToWorkerMessage, Order, WorkerToMainMessage, } from ./worker-protocol; const worker new Worker( new URL(./analytics.worker.ts, import.meta.url), { type: module }, ); let currentVersion 0; let activeTask: { taskId: string; version: number } | null null; worker.addEventListener(message, (event: MessageEventWorkerToMainMessage) { const message event.data; // 进度、结果、错误和取消消息都必须同时匹配任务 ID 与版本。 // 仅比较 version 虽然通常可行但 taskId 能让协议更明确、更便于排查问题。 if ( !activeTask || message.taskId ! activeTask.taskId || message.version ! activeTask.version ) { return; } if (message.type progress) { updateProgress(message.progress); return; } if (message.type result) { renderChart(message.data); activeTask null; return; } if (message.type cancelled) { activeTask null; return; } showCalculationError(message.message); activeTask null; }); worker.addEventListener(error, (event) { // 运行时异常通常意味着该 Worker 已不适合继续承担后续任务。 console.error(Worker runtime error:, event.message); activeTask null; showCalculationError(后台计算异常已停止本次分析。); }); worker.addEventListener(messageerror, () { console.error(Worker message cannot be deserialized); activeTask null; showCalculationError(任务数据无法在线程间传递。); }); export function recalculate(rows: Order[], keyword: string) { currentVersion 1; if (activeTask) { const cancelMessage: MainToWorkerMessage { type: cancel, taskId: activeTask.taskId, }; worker.postMessage(cancelMessage); } const taskId crypto.randomUUID(); activeTask { taskId, version: currentVersion }; showCalculatingState(); const startMessage: MainToWorkerMessage { type: start, taskId, version: currentVersion, keyword, rows, }; try { worker.postMessage(startMessage); } catch (error) { // 不可结构化克隆的数据通常会在发送侧同步抛出 DataCloneError。 activeTask null; showCalculationError(任务数据无法在线程间传递。); console.error(Failed to post message to worker:, error); } }在 React、Vue 等框架中Worker 不应承担状态管理或视图更新它只返回纯计算结果主线程仍负责防抖输入、提交状态、触发组件更新和渲染图表。对于连续输入先做 150300ms 的防抖通常比“每输入一个字符就发一次 Worker 消息”更有效。上例为了突出协议设计在每次任务中都传入rows。如果rows是在页面生命周期内基本不变的大型数据集更合适的做法是初始化时传入一次数据后续只发送keyword、筛选条件等增量参数。否则频繁的结构化克隆可能抵消 Worker 带来的收益。Worker 内的关键实现分块、进度与可取消一个常见误区是发出cancel消息后Worker 会立刻停止当前死循环。并不会。Worker 同样依赖事件循环如果它一直同步执行一个超长循环就没有机会处理排队中的取消消息。因此可取消任务必须在分块边界主动让出执行权。// analytics.worker.ts import type { MainToWorkerMessage, Order, WorkerToMainMessage, } from ./worker-protocol; const cancelledTaskIds new Setstring(); function reply(message: WorkerToMainMessage) { self.postMessage(message); } function yieldToWorkerEventLoop() { return new Promisevoid((resolve) setTimeout(resolve, 0)); } self.addEventListener(message, async (event: MessageEventMainToWorkerMessage) { const message event.data; if (message.type cancel) { cancelledTaskIds.add(message.taskId); return; } const { taskId, version, rows, keyword } message; try { const normalized keyword.trim().toLowerCase(); const totals new Mapstring, number(); const chunkSize 5_000; for (let start 0; start rows.length; start chunkSize) { if (cancelledTaskIds.has(taskId)) { cancelledTaskIds.delete(taskId); reply({ type: cancelled, taskId, version }); return; } const end Math.min(start chunkSize, rows.length); accumulate(rows, start, end, normalized, totals); reply({ type: progress, taskId, version, progress: end / rows.length, }); // 让 Worker 有机会处理取消消息避免任务长期独占其事件循环。 await yieldToWorkerEventLoop(); } if (cancelledTaskIds.has(taskId)) { cancelledTaskIds.delete(taskId); reply({ type: cancelled, taskId, version }); return; } const data [...totals.entries()] .map(([city, amount]) ({ city, amount })) .sort((a, b) b.amount - a.amount); reply({ type: result, taskId, version, data }); } catch (error) { reply({ type: error, taskId, version, message: error instanceof Error ? error.message : Unknown worker error, }); } }); function accumulate( rows: Order[], start: number, end: number, keyword: string, totals: Mapstring, number, ) { for (let index start; index end; index 1) { const row rows[index]; if (!row.customerName.toLowerCase().includes(keyword)) continue; totals.set(row.city, (totals.get(row.city) ?? 0) row.amount); } }这段代码实现了四个工程约束分块计算避免一个 Worker 任务无限期占用自身事件循环。逻辑取消取消请求在分块边界生效适合用户不断修改筛选条件的场景。进度上报适合任务确实较长、用户需要等待反馈的场景。版本与任务校验即使旧任务晚到主线程也会丢弃其结果。chunkSize 5_000只是示例不是通用最优值。每条记录的计算复杂度、设备性能和消息频率都会影响合适的分块大小应在目标设备上通过性能录制和压测确定。进度消息也不能无限频繁。若每处理一条数据就postMessage()通信和主线程状态更新本身会变成新瓶颈。实践中应按块、按时间间隔或只在进度变化达到阈值时上报。数据传输成本别把“搬运数据”变成新瓶颈Worker 与主线程默认使用结构化克隆传递数据。它支持许多复杂值但函数和 DOM 节点等不能被克隆传递时可能抛出DataCloneError。更重要的是大型普通对象会产生克隆与反序列化成本。MDN结构化克隆算法对于大型二进制数据、数值矩阵、音视频帧或图像字节优先评估ArrayBuffer与 TypedArray。可以转移底层ArrayBuffer的所有权避免常规复制const values new Float64Array(1_000_000); worker.postMessage( { type: start-binary-task, buffer: values.buffer }, [values.buffer], ); // 此后 values.buffer 已被转移主线程不能继续依赖它读取或写入数据。Transferable 的本质是所有权转移接收方获得缓冲区发送方的原始缓冲区会被 detached。因此它适合“数据交给 Worker 后主线程暂时不再使用”的场景如果主线程还要保留原始数据需要重新设计数据流或接受复制成本。MDNTransferable objectsSharedArrayBuffer允许主线程和 Worker 访问同一段内存但它不是默认优化选项。它要求页面处于跨源隔离状态通常涉及Cross-Origin-Opener-Policy: same-origin与Cross-Origin-Embedder-Policy: require-corp或credentialless等响应头同时还要处理Atomics、同步顺序、数据竞争和第三方资源兼容性问题。除非确实需要共享内存或极高频的数据交换否则应优先使用普通消息与 Transferable。MDNcrossOriginIsolated生命周期与调度复用 Worker但不要盲目建池对于持续存在的分析页、编辑器或图表页通常应复用一个 Dedicated Worker而不是每次输入都创建新 Worker。创建线程、加载 Worker 脚本、分配内存和复制数据都需要成本。Worker 池只适合以下情况同时存在多个彼此独立、确实耗 CPU 的任务单 Worker 已成为后台吞吐瓶颈任务能够安全切分且结果不依赖严格顺序。池的大小并非越大越好。Worker 过多会增加内存、调度竞争和设备发热低性能移动设备尤其明显。应从单 Worker 开始通过真实设备压测决定是否增加有限并发。当用户离开页面、组件卸载或任务必须立即中断时可以调用worker.terminate()。该方法会立即停止 Worker不会等待当前操作完成如需继续使用必须重新创建 Worker 实例。MDNWorker.terminate()错误处理与降级把 Worker 当作可失败的基础设施生产环境至少要覆盖以下情况Worker不可用或初始化失败Worker 内运行时异常消息无法克隆或反序列化任务长时间没有返回Worker 被终止后仍有调用方等待结果。一个实用的降级策略是使用typeof Worker ! undefined做能力检测Worker 初始化失败时回退到主线程的分片执行数据量超出前端可接受范围时改用服务端聚合或预计算接口为任务设置超时超时后提示用户重试并按需终止失控 Worker对错误日志记录任务规模、传输方式、浏览器信息与taskId方便定位异常。注意降级到主线程不代表直接运行原来的超长同步函数。应优先切分任务并让出主线程避免“Worker 挂了以后页面更卡”。如何验收不要只比较 Worker 内计算耗时Worker 化后的验收指标至少应包含指标要回答的问题主线程 Long Task重计算是否不再长时间阻塞输入与渲染交互响应 / INP输入、点击、拖动后的视觉反馈是否更及时Worker 计算耗时算法本身有没有退化消息传输耗时结构化克隆是否抵消了线程迁移收益端到端完成时间从用户操作到结果渲染完成是否更快或至少可接受内存峰值是否因为双份数据、缓存或 Worker 池导致内存压力上升低端设备表现优化是否只在高性能开发机上成立一个常见结果是Worker 方案的端到端完成时间未必显著更短甚至可能因传输成本略长但页面输入框、加载状态和滚动仍保持可响应。这依然可能是成功的优化因为核心目标是降低主线程竞争而不是孤立地缩短某个函数的运行时间。web.dev优化 INP常见误区与替代方案误区一把所有逻辑都扔进 WorkerWorker 适合足够重且可独立的计算。轻量任务、高频消息和 DOM 强相关逻辑迁移后常常只会增加复杂度。误区二忽略消息数据大小如果每次都向 Worker 发送巨大的嵌套对象结构化克隆可能成为主要耗时。对于二进制或数值数据应评估 Transferable对于重复使用的静态数据应考虑初始化一次、后续只发送增量参数。误区三认为 Worker 会自动并行加速单个算法Worker 解决的是主线程阻塞问题。单个任务是否更快仍取决于算法、数据规模、线程启动成本和通信成本。需要并行化时还要额外设计任务切分、汇总与有限并发。误区四只取消 UI不取消后台任务如果用户已经输入了新条件旧任务仍消耗 CPU不仅浪费资源还会抢占其他后台任务。应同时具备“逻辑取消 过期结果丢弃”只有在必须立即停止时才使用terminate()。误区五把 Worker 当作唯一方案根据瓶颈选择工具算法可优化优先减少复杂度、建立索引、缓存中间结果。工作不重但会形成长任务分片并让出主线程。计算重且不依赖 DOM使用 Web Worker。数值计算密集且已有成熟实现评估 WebAssembly 与 Worker 组合。绘制本身昂贵评估 OffscreenCanvas 与 Worker。数据量超过设备承载能力转向服务端计算、预聚合或分页。结语把重计算放进 Web Worker不应理解为一次 API 改造而应理解为一次任务架构调整主线程负责交互、状态和渲染Worker 负责独立、可取消、可观测的纯计算通信协议负责版本、进度、错误与结果一致性性能验证同时关注主线程、传输成本、内存和端到端体验。当你发现某段计算让输入、滚动或动画变得迟钝时先用性能面板确认主线程瓶颈再用这套协议和测量方法迁移。这样得到的不是“多开一个线程”而是一个在真实用户操作下依然保持流畅的前端计算系统。参考资料MDNUsing Web WorkersMDNTransferable objectsMDNStructured clone algorithmMDNWorkerGlobalScope.crossOriginIsolatedweb.devUse web workers to run JavaScript off the browsers main threadweb.devOptimize long tasksweb.devOptimize Interaction to Next PaintViteWeb WorkerswebpackWeb Workers 用 Web Workers 优化前端重计算任务：避免主线程卡顿的实战方案
原文链接用 Web Workers 优化前端重计算任务避免主线程卡顿的实战方案前端性能问题中有一类问题很容易被忽略接口很快、组件也没有明显的重复渲染但用户一输入筛选条件、拖动时间范围或切换图表维度页面就会短暂“失去响应”。这通常不是网络慢而是CPU 密集型 JavaScript 长时间占用了主线程。浏览器主线程需要处理输入事件、执行 JavaScript、进行样式计算、布局和绘制当一次计算持续太久新的点击、键盘输入和下一帧渲染都只能排队。长任务会拉长交互延迟并可能恶化 INPInteraction to Next Paint。web.dev 对主线程与 Worker 的说明Web Worker 的价值不在于“让代码神奇地更快”而在于将不依赖 DOM 的重计算移出 UI 线程让主线程优先服务交互与渲染。本文以“大数组筛选与聚合”为例给出一套可扩展到图表预处理、富文本解析、地理数据计算、本地规则引擎等场景的工程化方案。先判断这个任务真的适合放进 Worker 吗适合迁移的任务通常同时满足以下条件CPU 密集处理时间随数据量明显增长例如排序、聚合、解析、编码、规则匹配、图像或二进制数据处理。计算相对独立输入数据准备好后任务可以在后台独立执行。不需要直接访问 DOMDedicated Worker 运行在独立的全局上下文中不能直接读写window、document或页面节点。单次任务足够重收益能够抵消 Worker 创建、脚本加载和消息传输带来的额外成本。以下场景则不应第一时间搬进 Worker网络请求等待、轻量级格式化等非 CPU 瓶颈高频触发、每次仅耗时几毫秒的小任务必须同步读取布局、操作 DOM或依赖框架渲染上下文的逻辑算法本身存在明显低效问题例如本可使用索引或线性扫描解决却采用多重嵌套遍历。Worker 是线程隔离工具不是算法优化的替代品。先减少无效计算再决定是否迁移。不要凭感觉迁移先建立性能基线打开 Chrome DevTools 的Performance面板录制一次可稳定复现的操作例如输入搜索词、切换筛选条件或拖动图表范围。重点观察主线程是否存在长任务持续超过 50ms 的任务值得重点排查。火焰图中的耗时函数排序、序列化、数据转换、正则解析或循环计算是否集中出现在输入事件回调中。交互是否被阻塞用户输入到下一次可见绘制之间是否存在明显空档。端到端完成时间从用户发起操作到最终结果渲染完成不能只看某个函数的执行时间。Long Task 并不自动等于“必须使用 Worker”。如果一个任务能被拆成多个短任务并主动让出主线程也可能改善输入响应但对于持续的大规模计算将工作移到 Worker 往往更直接。长任务与任务拆分的优化方法实战场景大数组聚合为什么会卡住页面假设页面展示订单分析结果。用户持续输入搜索词时需要在几十万条记录中完成名称匹配按城市聚合金额按聚合金额排序返回图表需要的序列。如果业务还要展示命中的订单明细再单独对明细排序不要在只需要城市聚合结果时先对全部命中订单排序因为这会引入不必要的O(n log n)开销。如果以下逻辑直接运行在输入事件中计算期间主线程无法及时处理下一次键盘事件也无法绘制 loading 状态function recalculateOnMainThread(rows: Order[], keyword: string) { const normalized keyword.trim().toLowerCase(); const totals new Mapstring, number(); for (const row of rows) { if (!row.customerName.toLowerCase().includes(normalized)) continue; totals.set(row.city, (totals.get(row.city) ?? 0) row.amount); } return [...totals.entries()] .map(([city, amount]) ({ city, amount })) .sort((a, b) b.amount - a.amount); }问题不在于这段代码不能运行而在于数据量上来后它会在一个主线程任务中连续执行。用户随后输入的新字符即使只需要更新输入框也得等这一轮计算结束。Worker 的基本模型计算在线程外UI 仍留在主线程Dedicated Worker 与页面通过postMessage()和message事件通信。默认情况下消息数据会经过结构化克隆接收方得到的是独立的数据副本而非发送方对象的同一引用。Worker 可以执行计算并回传结果但不能直接操作 DOM。MDNUsing Web Workers推荐将通信设计成显式协议而不是随意发送裸对象// worker-protocol.ts export type Order { id: string; customerName: string; city: string; amount: number; }; export type StartTaskMessage { type: start; taskId: string; version: number; keyword: string; rows: Order[]; }; export type CancelTaskMessage { type: cancel; taskId: string; }; export type MainToWorkerMessage StartTaskMessage | CancelTaskMessage; export type WorkerToMainMessage | { type: progress; taskId: string; version: number; progress: number } | { type: result; taskId: string; version: number; data: Array{ city: string; amount: number }; } | { type: cancelled; taskId: string; version: number } | { type: error; taskId: string; version: number; message: string };这里有三个关键字段taskId标识一次具体任务便于取消、超时、日志关联以及精确判断消息是否属于当前任务。version代表当前 UI 输入版本避免旧结果覆盖新状态。type让进度、结果、错误和取消成为可区分的消息类型。使用模块 Worker主线程只负责调度与提交 UI 状态在 Vite 与 webpack 5 中都可以使用接近浏览器标准的模块 Worker 写法const worker new Worker( new URL(./analytics.worker.ts, import.meta.url), { type: module }, );Vite 推荐在new Worker()中使用new URL()webpack 5 也原生支持这一模式无需旧版的worker-loader。Vite Worker 文档webpack Web Workers 指南主线程封装可以这样写import type { MainToWorkerMessage, Order, WorkerToMainMessage, } from ./worker-protocol; const worker new Worker( new URL(./analytics.worker.ts, import.meta.url), { type: module }, ); let currentVersion 0; let activeTask: { taskId: string; version: number } | null null; worker.addEventListener(message, (event: MessageEventWorkerToMainMessage) { const message event.data; // 进度、结果、错误和取消消息都必须同时匹配任务 ID 与版本。 // 仅比较 version 虽然通常可行但 taskId 能让协议更明确、更便于排查问题。 if ( !activeTask || message.taskId ! activeTask.taskId || message.version ! activeTask.version ) { return; } if (message.type progress) { updateProgress(message.progress); return; } if (message.type result) { renderChart(message.data); activeTask null; return; } if (message.type cancelled) { activeTask null; return; } showCalculationError(message.message); activeTask null; }); worker.addEventListener(error, (event) { // 运行时异常通常意味着该 Worker 已不适合继续承担后续任务。 console.error(Worker runtime error:, event.message); activeTask null; showCalculationError(后台计算异常已停止本次分析。); }); worker.addEventListener(messageerror, () { console.error(Worker message cannot be deserialized); activeTask null; showCalculationError(任务数据无法在线程间传递。); }); export function recalculate(rows: Order[], keyword: string) { currentVersion 1; if (activeTask) { const cancelMessage: MainToWorkerMessage { type: cancel, taskId: activeTask.taskId, }; worker.postMessage(cancelMessage); } const taskId crypto.randomUUID(); activeTask { taskId, version: currentVersion }; showCalculatingState(); const startMessage: MainToWorkerMessage { type: start, taskId, version: currentVersion, keyword, rows, }; try { worker.postMessage(startMessage); } catch (error) { // 不可结构化克隆的数据通常会在发送侧同步抛出 DataCloneError。 activeTask null; showCalculationError(任务数据无法在线程间传递。); console.error(Failed to post message to worker:, error); } }在 React、Vue 等框架中Worker 不应承担状态管理或视图更新它只返回纯计算结果主线程仍负责防抖输入、提交状态、触发组件更新和渲染图表。对于连续输入先做 150300ms 的防抖通常比“每输入一个字符就发一次 Worker 消息”更有效。上例为了突出协议设计在每次任务中都传入rows。如果rows是在页面生命周期内基本不变的大型数据集更合适的做法是初始化时传入一次数据后续只发送keyword、筛选条件等增量参数。否则频繁的结构化克隆可能抵消 Worker 带来的收益。Worker 内的关键实现分块、进度与可取消一个常见误区是发出cancel消息后Worker 会立刻停止当前死循环。并不会。Worker 同样依赖事件循环如果它一直同步执行一个超长循环就没有机会处理排队中的取消消息。因此可取消任务必须在分块边界主动让出执行权。// analytics.worker.ts import type { MainToWorkerMessage, Order, WorkerToMainMessage, } from ./worker-protocol; const cancelledTaskIds new Setstring(); function reply(message: WorkerToMainMessage) { self.postMessage(message); } function yieldToWorkerEventLoop() { return new Promisevoid((resolve) setTimeout(resolve, 0)); } self.addEventListener(message, async (event: MessageEventMainToWorkerMessage) { const message event.data; if (message.type cancel) { cancelledTaskIds.add(message.taskId); return; } const { taskId, version, rows, keyword } message; try { const normalized keyword.trim().toLowerCase(); const totals new Mapstring, number(); const chunkSize 5_000; for (let start 0; start rows.length; start chunkSize) { if (cancelledTaskIds.has(taskId)) { cancelledTaskIds.delete(taskId); reply({ type: cancelled, taskId, version }); return; } const end Math.min(start chunkSize, rows.length); accumulate(rows, start, end, normalized, totals); reply({ type: progress, taskId, version, progress: end / rows.length, }); // 让 Worker 有机会处理取消消息避免任务长期独占其事件循环。 await yieldToWorkerEventLoop(); } if (cancelledTaskIds.has(taskId)) { cancelledTaskIds.delete(taskId); reply({ type: cancelled, taskId, version }); return; } const data [...totals.entries()] .map(([city, amount]) ({ city, amount })) .sort((a, b) b.amount - a.amount); reply({ type: result, taskId, version, data }); } catch (error) { reply({ type: error, taskId, version, message: error instanceof Error ? error.message : Unknown worker error, }); } }); function accumulate( rows: Order[], start: number, end: number, keyword: string, totals: Mapstring, number, ) { for (let index start; index end; index 1) { const row rows[index]; if (!row.customerName.toLowerCase().includes(keyword)) continue; totals.set(row.city, (totals.get(row.city) ?? 0) row.amount); } }这段代码实现了四个工程约束分块计算避免一个 Worker 任务无限期占用自身事件循环。逻辑取消取消请求在分块边界生效适合用户不断修改筛选条件的场景。进度上报适合任务确实较长、用户需要等待反馈的场景。版本与任务校验即使旧任务晚到主线程也会丢弃其结果。chunkSize 5_000只是示例不是通用最优值。每条记录的计算复杂度、设备性能和消息频率都会影响合适的分块大小应在目标设备上通过性能录制和压测确定。进度消息也不能无限频繁。若每处理一条数据就postMessage()通信和主线程状态更新本身会变成新瓶颈。实践中应按块、按时间间隔或只在进度变化达到阈值时上报。数据传输成本别把“搬运数据”变成新瓶颈Worker 与主线程默认使用结构化克隆传递数据。它支持许多复杂值但函数和 DOM 节点等不能被克隆传递时可能抛出DataCloneError。更重要的是大型普通对象会产生克隆与反序列化成本。MDN结构化克隆算法对于大型二进制数据、数值矩阵、音视频帧或图像字节优先评估ArrayBuffer与 TypedArray。可以转移底层ArrayBuffer的所有权避免常规复制const values new Float64Array(1_000_000); worker.postMessage( { type: start-binary-task, buffer: values.buffer }, [values.buffer], ); // 此后 values.buffer 已被转移主线程不能继续依赖它读取或写入数据。Transferable 的本质是所有权转移接收方获得缓冲区发送方的原始缓冲区会被 detached。因此它适合“数据交给 Worker 后主线程暂时不再使用”的场景如果主线程还要保留原始数据需要重新设计数据流或接受复制成本。MDNTransferable objectsSharedArrayBuffer允许主线程和 Worker 访问同一段内存但它不是默认优化选项。它要求页面处于跨源隔离状态通常涉及Cross-Origin-Opener-Policy: same-origin与Cross-Origin-Embedder-Policy: require-corp或credentialless等响应头同时还要处理Atomics、同步顺序、数据竞争和第三方资源兼容性问题。除非确实需要共享内存或极高频的数据交换否则应优先使用普通消息与 Transferable。MDNcrossOriginIsolated生命周期与调度复用 Worker但不要盲目建池对于持续存在的分析页、编辑器或图表页通常应复用一个 Dedicated Worker而不是每次输入都创建新 Worker。创建线程、加载 Worker 脚本、分配内存和复制数据都需要成本。Worker 池只适合以下情况同时存在多个彼此独立、确实耗 CPU 的任务单 Worker 已成为后台吞吐瓶颈任务能够安全切分且结果不依赖严格顺序。池的大小并非越大越好。Worker 过多会增加内存、调度竞争和设备发热低性能移动设备尤其明显。应从单 Worker 开始通过真实设备压测决定是否增加有限并发。当用户离开页面、组件卸载或任务必须立即中断时可以调用worker.terminate()。该方法会立即停止 Worker不会等待当前操作完成如需继续使用必须重新创建 Worker 实例。MDNWorker.terminate()错误处理与降级把 Worker 当作可失败的基础设施生产环境至少要覆盖以下情况Worker不可用或初始化失败Worker 内运行时异常消息无法克隆或反序列化任务长时间没有返回Worker 被终止后仍有调用方等待结果。一个实用的降级策略是使用typeof Worker ! undefined做能力检测Worker 初始化失败时回退到主线程的分片执行数据量超出前端可接受范围时改用服务端聚合或预计算接口为任务设置超时超时后提示用户重试并按需终止失控 Worker对错误日志记录任务规模、传输方式、浏览器信息与taskId方便定位异常。注意降级到主线程不代表直接运行原来的超长同步函数。应优先切分任务并让出主线程避免“Worker 挂了以后页面更卡”。如何验收不要只比较 Worker 内计算耗时Worker 化后的验收指标至少应包含指标要回答的问题主线程 Long Task重计算是否不再长时间阻塞输入与渲染交互响应 / INP输入、点击、拖动后的视觉反馈是否更及时Worker 计算耗时算法本身有没有退化消息传输耗时结构化克隆是否抵消了线程迁移收益端到端完成时间从用户操作到结果渲染完成是否更快或至少可接受内存峰值是否因为双份数据、缓存或 Worker 池导致内存压力上升低端设备表现优化是否只在高性能开发机上成立一个常见结果是Worker 方案的端到端完成时间未必显著更短甚至可能因传输成本略长但页面输入框、加载状态和滚动仍保持可响应。这依然可能是成功的优化因为核心目标是降低主线程竞争而不是孤立地缩短某个函数的运行时间。web.dev优化 INP常见误区与替代方案误区一把所有逻辑都扔进 WorkerWorker 适合足够重且可独立的计算。轻量任务、高频消息和 DOM 强相关逻辑迁移后常常只会增加复杂度。误区二忽略消息数据大小如果每次都向 Worker 发送巨大的嵌套对象结构化克隆可能成为主要耗时。对于二进制或数值数据应评估 Transferable对于重复使用的静态数据应考虑初始化一次、后续只发送增量参数。误区三认为 Worker 会自动并行加速单个算法Worker 解决的是主线程阻塞问题。单个任务是否更快仍取决于算法、数据规模、线程启动成本和通信成本。需要并行化时还要额外设计任务切分、汇总与有限并发。误区四只取消 UI不取消后台任务如果用户已经输入了新条件旧任务仍消耗 CPU不仅浪费资源还会抢占其他后台任务。应同时具备“逻辑取消 过期结果丢弃”只有在必须立即停止时才使用terminate()。误区五把 Worker 当作唯一方案根据瓶颈选择工具算法可优化优先减少复杂度、建立索引、缓存中间结果。工作不重但会形成长任务分片并让出主线程。计算重且不依赖 DOM使用 Web Worker。数值计算密集且已有成熟实现评估 WebAssembly 与 Worker 组合。绘制本身昂贵评估 OffscreenCanvas 与 Worker。数据量超过设备承载能力转向服务端计算、预聚合或分页。结语把重计算放进 Web Worker不应理解为一次 API 改造而应理解为一次任务架构调整主线程负责交互、状态和渲染Worker 负责独立、可取消、可观测的纯计算通信协议负责版本、进度、错误与结果一致性性能验证同时关注主线程、传输成本、内存和端到端体验。当你发现某段计算让输入、滚动或动画变得迟钝时先用性能面板确认主线程瓶颈再用这套协议和测量方法迁移。这样得到的不是“多开一个线程”而是一个在真实用户操作下依然保持流畅的前端计算系统。参考资料MDNUsing Web WorkersMDNTransferable objectsMDNStructured clone algorithmMDNWorkerGlobalScope.crossOriginIsolatedweb.devUse web workers to run JavaScript off the browsers main threadweb.devOptimize long tasksweb.devOptimize Interaction to Next PaintViteWeb WorkerswebpackWeb Workers