JS执行密集型任务效能提速：从事件循环到Worker与GPU计算

大家不要嫌我啰嗦，先说一个我自己的真实场景:有一次我给一个内部数据系统写前端，功能是解析一份两万行的CSV文件，每条记录要进行字段清洗、日期格式化、关联查表，最后还要聚合统计。第一次写完，点击按钮之后整个页面直接"冻结"了四秒多。那四秒里，滚动条拖不动，弹窗点不开，甚至鼠标移到按钮上连 hover 态都不反馈——用户当场就问我："是不是死机了？"

这就是典型的 JS执行密集型任务 把主线程堵死的状态。JS本身是单线程语言，它要同时承担页面渲染、事件响应和业务脚本三件事，一旦计算量过大，渲染和交互就会被无限期搁置。很多人一看到"效能提速"就觉得要去改算法、抠语法，但实际上，想真正把这类任务跑顺，需要从运行机制、线程模型、计算下放到代码细节几个层面同时下功夫。这篇文章不打算讲那些花哨的框架技巧，而是从引擎和浏览器的工作方式出发，用我自己实测过的一些方案，聊清楚密集型任务到底该怎么提速。

这个话题适合谁来读？不管是只写过 jQuery 时代的页面、第一次在 React 里遇到大数据渲染卡顿，还是在 Node 端写数据处理脚本、被同步遍历压垮了接口响应的人，都应该能从里面找到自己的解药。下面按我平时排查问题的顺序来拆。

1. 卡顿的真相：事件循环为什么会被密集任务拖死

先搞清楚一个问题：JS 不是"慢"，而是它干活的时候，别的活没人干。

1.1 单线程模型下的主线程调度逻辑

浏览器里负责执行 JS 的主线程，同时也负责解析 DOM、计算样式、生成布局草稿、绘制图像、处理用户的点击和键盘事件。这个线程在一个循环里反复执行这几类任务，这个循环就叫 事件循环（Event Loop）。事件循环的基本单元是"任务"（task），每一个宏任务执行完之后，浏览器才有机会去看看动画帧需不需要更新、事件队列里有没有新的用户操作。

这里的关键在于：一个"任务"一旦开始，就会一直运行到完成，中途不会被打断。如果你的某个任务是一次几千万次的循环，那这期间浏览器根本没有机会去渲染页面，也没有机会去处理鼠标点击，表现出来就是页面"卡死"。

很多人把"卡死"归咎于"数据量太大"，但实际上数据量是固定的，更本质的问题是：你把一个耗时极长的计算任务整块地丢进了主线程的宏任务队列。这就像你在一个双人合用的办公室里，搬了一张巨大的桌子占满了所有过道，另一个人无论想走到饮水机还是洗手间，都得等你把桌子放稳。

1.2 帧率与长任务的关系

浏览器的动画和交互反馈一般要保持在每秒60帧，也就是每一帧的时间预算大约是 16.67ms。这里面还包括浏览器渲染一帧内部所有步骤的时间。换句话说，如果主线程上某个任务占了50ms，那就意味着至少三帧错过了，用户会明显感觉到卡顿；如果占了4秒，那就是整整240帧没被渲染，用户体验接近"假死"。

现在 DevTools 里专门把超过50ms的任务标记为 Long Task（长任务），就是这个原因。50ms 已经足以让用户觉得"不跟手"了，长任务一旦超过 1s，用户基本就会认为程序坏了。所以判断一个密集型任务是否需要优化，第一步不是看代码长的多不多，而是量一量它到底在主线程上占了多长时间。

1.3 主线程繁忙带来的连锁反应

除了渲染和交互之外，密集型任务还会间接引发另外两类问题：内存压力和事件延迟。

内存压力来自哪里？很多密集计算往往要生成大量临时对象。比如解析 CSV 时，每一条记录都拆出若干字符串，这些字符串转成数字、日期对象，做完计算之后又没人引用了，GC（垃圾回收）就需要出去清理。GC 清理动作本身也会占用主线程，只要临时对象一多，GC 出现的频率和时间就会暴增，进一步拖慢其他任务。

事件延迟则更隐蔽。用户点击按钮后的响应，会被排在当前长任务之后；如果长任务跑不完，点击事件就一直躺在队列里。有时候用户多点了几次，队列里积压了好几个事件，等长任务终于跑完之后，这些事件又会在极短的时间内集中执行，导致一些本来只运行一次的副作用突然执行了好几次，很容易引发逻辑 bug。

理解了这些，你就能明白：密集任务提速的核心目标，不是让 CPU 算得更快，而是让主线程尽快被释放，让它有空去处理渲染和用户交互。 下面的所有优化手段，基本都是围绕这个目标展开的——除了代码本身变快之外，还要想办法让计算不占着主线程，或者把计算切成小片，让浏览器有时间呼吸。

2. 先量化再优化：用 Performance 面板定位真正的"凶手"

我见过很多同学一上来就开始改代码：把 for 循环改成 while，把字符串拼接改成数组 join，改完发现提速微乎其微。这种做法的最大问题在于，没找到真正的瓶颈在哪儿就乱开刀。盲目优化往往只在代码层面挤出了 10% 的收益，而真正的性能黑洞可能藏在一个你从来没注意过的嵌套循环或者隐藏的内存拷贝里。

2.1 建立一份可靠的性能基线

优化之前，我强烈建议先做一次性能采样，记录优化前的数字。这个数字不光是总耗时，还包括任务分解后的耗时分布。

拿 Chrome DevTools 举例：打开 Performance 面板，点击录制，然后触发你要优化的那一段逻辑，比如点击"导入 CSV"按钮，等任务跑完之后停止录制。你会看到一条主线程时间线，上面有从左到右依次排列的任务块。点开某个大块，就能看到里面是什么函数在执行，每个函数自己花了多少时间，多少次调用是 CPU 密集，多少次是 GC，多少次是等待。

这里有个容易被忽略的细节：Performance 面板的采样本身是有开销的。在极其密集的循环里，采样器会额外造成 3% 到 5% 的开销，所以真实线上环境的耗时通常会比你在 DevTools 里看到的低一点。但只要优化前后用的是同样的环境，这个相对差异仍然可信。

2.2 Long Tasks 与 PerformanceEntry 的自动化测量

如果觉得打开 DevTools 手工录制太麻烦，也可以在代码里用 Performance Observer 自动收集长任务数据。浏览器提供了 PerformanceObserver API，可以监听 longtask 类型的条目，这样页面里每一项超过 50ms 的任务都会被记录下来。

这段代码可以直接放在生产环境里做线上性能监控：

javascript复制const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.startTime 是任务开始时间
    // entry.duration 是任务耗时
    if (entry.duration > 200) {
      // 上报到日志系统或者直接 console.warn
    }
  }
});
observer.observe({ entryTypes: ['longtask'] });

有了这个自动测量之后，你可以给页面设置一条性能红线，比如"主线程任何任务不得超过 500ms"。一旦某个任务突破了红线，日志里就能抓到现场，再结合当时的用户操作路径，排查效率会高很多。

2.3 代码剖析的常见误区

第一个误区是"凭感觉定位"。我在写 CSV 解析器的时候，最开始也以为是正则匹配慢，结果把正则替换掉之后发现总耗时只降了 8%。后来用面板一看，最耗时的函数其实是一个看起来人畜无害的 Array.prototype.reduce——它里面每一次迭代都改了字符串，生成了大量中间字符串，导致 GC 频繁触发，总耗时反而远超正则。

第二个误区是只看函数自身的耗时，不看它触发的后续影响。有些函数本身执行时间很短，但它制造了大量垃圾对象，导致紧随其后的 GC 标记阶段时间暴涨。Perfomance 面板里有一个"Memory"区域，如果你看到紫色的 GC 条特别频繁、特别宽，那就要考虑是不是临时对象分配太多了。

第三个误区是忽略环境差异。同一个函数在 8GB 内存的办公电脑上很快，到了用户 4GB 内存、后台还开着十几个标签页的环境里，可能就慢得离谱。所以我建议在优化前和执行后测试时，尽量模拟目标用户的硬件条件，至少保证 CPU 降频、内存不足这些极端情况不能直接崩掉。

定位做完之后，就该进入具体的优化环节了。我习惯把优化分成三个层级：不动线程的代码优化、搬离线程的 Worker 优化、以及把活分给 GPU 的异构计算优化。下面一层一层说。

3. 主线程内的第一层优化：算法选型、数据结构与 V8 的执行习惯

如果离开主线程的成本很高（比如计算过程中要和 DOM 频繁交互，或者结果要被其他模块同步使用），那么先在主线程内部把代码本身的速度榨干，是第一层值得做的优化。这一层的核心不是"把代码写得短"，而是 尊重 JS 引擎的运行规律。

3.1 算法复杂度才是最大的杠杆

很多密集任务的瓶颈压根不在编码细节上，而在算法复杂度上。我见过有人把一组用户数据按 ID 去匹配另一组数据，直接用数组 filter + includes，两层嵌套一跑就是 O(n²)。数据量小的时候看不出来，数据量一上万，循环次数就是过亿级别，不卡才是怪事。

正确的做法是先把数据转换成 Map 或者 Set，查表从线性遍历变成哈希查找，复杂度直接降到 O(n)。这里给一个简单例子：

javascript复制// 低效做法：O(n²)
const matched = source.filter(item => target.includes(item.id));

// 高效做法：O(n)
const targetIds = new Set(target.map(item => item.id));
const matched = source.filter(item => targetIds.has(item.id));

这种结构上的改动，比任何语法层面的微优化都值钱得多。所以在动手抠代码之前，先问自己一个问题：能不能把嵌套循环展开？能不能用哈希结构替代遍历？能不能用排序加二分替代线性查找？数据结构的合理选择，往往能把耗时从"秒级"直接降到"毫秒级"。

3.2 V8 引擎的隐式优化：稳定对象形状与单态调用

V8 是现代 Chrome 和 Node 使用的 JS 引擎，它有一个很深层的道理：如果代码能保持"可预测"，JIT 编译器就能生成更快的机器码。这里最典型的就是"隐藏类（Hidden Class）"和"内联缓存（Inline Cache）"。

隐藏类可以理解为对象形状的记录。当你写 obj.a = 1 的时候，V8 会先给 obj 一个隐藏类，之后再给 obj.b = 2，它会把隐藏类切换成包含两个属性的新类。每次切换都有开销。所以如果你在一个循环里频繁创建同一批结构的对象，最好的方式是用同一个构造函数或者同一个工厂函数去创建，保证它们一路走来的隐藏类路径一致。

而"单态调用"的意思是：一个函数如果每次都被同一个类型的参数调用，V8 会为其生成专门优化的代码；如果传进来的参数类型五花八门，它就会退回慢速的"多态"模式。这条规则放到业务代码里的启示是：别在热路径里往一个变量里塞不同类型的值。

看起来好像很玄学，但实测确实有影响。我给一个典型的例子：

javascript复制// 不稳定的对象创建方式：属性顺序每次都不一样
function createBadObject(flag) {
  const obj = {};
  if (flag) {
    obj.name = 'a';
    obj.value = 1;
  } else {
    obj.value = 2;
    obj.name = 'b';
  }
  return obj;
}

// 稳定的对象创建方式：属性顺序保持一致
function createGoodObject(flag) {
  return {
    name: flag ? 'a' : 'b',
    value: flag ? 1 : 2
  };
}

第二种写法在循环里反复调用时，V8 能复用同一套隐藏类路径，对象创建和后续属性访问都会快一些。这类优化单次收益不明显，但放在一个每秒执行上万次的循环里，收益就会放大成明显的整体提升。

3.3 减少中间对象，让 GC 压力降下来

JS 引擎的内存管理自动进行，但不能指望它免费。密集型计算里最常见的性能杀手就是"循环里创建临时对象/临时字符串"。

字符串拼接就是一个典型。很多人知道 += 拼字符串耗时，但不太清楚为什么。字符串在 JS 里是不可变的，每次拼接都会生成一个新字符串，旧的字符串变成垃圾，等待回收。如果你在一个 10 万次的循环里不断拼接，那就产生了 10 万个中间字符串，GC 会被频繁触发。

我建议在上规模的数据处理场景里，尽量用数组收集再统一 join：

javascript复制// 低效：循环里反复拼接
let result = '';
for (const row of rows) {
  result += row.name + ',' + row.value + '\n';
}

// 高效：先收集再 join
const parts = [];
for (const row of rows) {
  parts.push(row.name, ',', row.value, '\n');
}
const result = parts.join('');

同理，在热循环里少写 { ...obj } 这种展开语法，少用 Array.prototype.map 连续链式调用产生多层中间数组。每个中间数组都是一次内存分配，都会给 GC 增加负担。不是不能用，而是要知道它们各自的成本。

3.4 在正确的地方使用缓存

如果某些计算结果在短时间内不会变化，千万不要重复计算。业务代码里常见的重复计算有两类：一类是同一次操作中反复计算同一个纯函数值，另一类是不同请求之间反复计算同一批公共数据。

针对前者，可以在函数内部做记忆化缓存（memoization）；针对后者，可以在模块层做一个带失效策略的缓存池。缓存不是万能的，但它在密集任务里是最简单又最见效的手段。比如一个需要正则解析的日期格式化函数，如果一万条记录里只有几十个不同的日期，那完全可以用 Map 把解析结果缓存起来，后续直接命中缓存，省掉 99% 的正则调用。

值得一提的边界是：缓存本身也会占内存，如果缓存的内容很大、命中率又很低，还不如不过缓存。 一般我会以"重复计算频率高 + 结果体积小"两个条件来判断该不该加缓存。

4. 换一条赛道：用 Web Worker 把密集计算搬离主线程

主线程内的优化能做的终归有限。只要计算还在主线程上，它的每一步都是在跟渲染与交互抢时间。真正的釜底抽薪方案，是把整个计算任务丢出主线程，放到独立的线程上执行。这个方案就是 Web Worker。

4.1 Web Worker 的基本形态与能力边界

Web Worker 是可以运行 JS 脚本的后台线程。它和主线程并行执行，互不阻塞。主线程通过 postMessage 给 Worker 发数据，Worker 算完之后再通过 postMessage 把结果发回主线程。

下面是一个最基础的示例：主线程创建 Worker，把一个大数组丢给它，然后立刻可以继续做自己的事，用户交互完全不受影响。

javascript复制// main.js
const worker = new Worker('./calc.worker.js');
worker.postMessage(bigArray); // 把数据发过去

worker.onmessage = (e) => {
  console.log('计算结果：', e.data);
};

// 发完消息后，主线程完全自由
updateUIWhileWaiting();

// calc.worker.js
self.onmessage = (e) => {
  const result = heavyCalculation(e.data);
  self.postMessage(result);
};

需要注意 Web Worker 里的运行环境和主线程不完全一样。Worker 拿不到 window、document，不能直接操作 DOM。所以在设计的时候一定要想清楚：哪些逻辑是纯计算的，哪些逻辑必须回主线程处理。数据解析、图像处理、排序搜索、文本分析这类和 UI 无关的活儿，都是 Worker 的舒适区；操作 DOM、读取布局属性这些就得留在主线程。

4.2 转移数据的开销问题：善用 Transferable

很多人第一次用 Worker 的时候会遇到一个尴尬情况：数据量一大，postMessage 本身就成了瓶颈。这是因为结构化克隆算法在传递数据时会把对象深拷贝一遍，一个 100MB 的数组从主线程发到 Worker，可能需要几百毫秒拷贝时间。

解决办法是使用 Transferable（可转移）对象。当你用转移方式传递 ArrayBuffer 时，底层内存块的所有权直接从主线程移交给 Worker，不需要复制数据。代价是主线程这边原来的 ArrayBuffer 会被清空，再也用不了。

javascript复制const buffer = new ArrayBuffer(1024 * 1024 * 64); // 64MB
// 把 buffer 的所有权转移给 worker
worker.postMessage({ buffer }, [buffer]);
// 之后主线程不能再访问原来那个 buffer

这里我再多说一句：如果你在做的是"读取文件 → Worker 解析 → 主线程展示"的场景，完全可以先把文件读成 ArrayBuffer，再转移给 Worker，整个流程都不用复制数据，速度会非常快。

对于 SharedArrayBuffer，它允许主线程和 Worker 共享一块内存，不需要任何复制。但它也带来了并发写的问题，必须使用 Atomics 对象来做同步。这个方案本身没有问题，只是使用门槛更高了，我一般建议：先用 Transferable 减少拷贝，等确实出现共享内存需求，再上 SharedArrayBuffer。

4.3 Worker 池：让多个 Worker 并行分担任务

一个 Worker 就算独立于主线程，它自己也只有一个线程。如果计算任务是可并行的（比如把一万条记录拆成十组，每组算完再合并），那更好的做法是建一个 Worker 池，让多个 Worker 同时干活。

实现一个简单的 Worker 池并不复杂。核心思路是：把任务切成多个分片，每个分片交给一个空闲的 Worker，等所有 Worker 都返回后，在主线程合并结果。

javascript复制class WorkerPool {
  constructor(workerFactory, size) {
    this.workerFactory = workerFactory;
    this.queue = [];
    this.workers = Array.from({ length: size }, () => ({
      worker: workerFactory(),
      busy: false
    }));
  }

  runTask(payload) {
    return new Promise((resolve, reject) => {
      const item = { payload, resolve, reject };
      this.queue.push(item);
      this.dispatch();
    });
  }

  dispatch() {
    for (const slot of this.workers) {
      if (slot.busy || this.queue.length === 0) continue;
      const task = this.queue.shift();
      slot.busy = true;
      slot.worker.onmessage = (e) => {
        slot.busy = false;
        task.resolve(e.data);
        this.dispatch();
      };
      slot.worker.postMessage(task.payload);
    }
  }
}

这里要提醒一个并行度的把握问题：并不是 Worker 越多越快。每个线程都有创建成本和内存开销，如果你的机器是 4 核，开 16 个 Worker 反而会因为上下文切换和内存争抢让性能下降。一般经验值是创建 navigator.hardwareConcurrency - 1 个 Worker，留一个核心给主线程处理交互和渲染。

4.4 用 Worker 后依然要做任务分解

把计算丢进 Worker，主线程是不卡了，但 Worker 线程本身算得慢还是慢。如果用户要等 10 秒才能看到结果，体验依然不好。所以 Worker 方案通常还要配合"分片 + 进度反馈"一起用。主线程可以把一个大任务切分成若干小片，每完成一片，Worker 就给主线程发一个进度消息，主线程据此更新进度条。

这个模式既保证了主线程不阻塞，又让用户知道"程序还在干活，没死"。实际产品里，用户能感知到的除了"不卡"，还有"有反馈"，这两样缺一不可。

5. 极致提速：把任务交给 GPU 做通用计算

如果计算密集型任务的规模大到多线程 Worker 都觉得吃力，比如图像卷积、矩阵乘法、物理模拟、批量数值计算，这时候还有一条更硬核的路：用 GPU 做通用计算。GPU 拥有成百上千个并行计算单元，在合适的任务上，它的吞吐量高到 CPU 望尘莫及。

5.1 WebGL 与通用计算的基本思路

WebGL 本身是为图形渲染设计的，但它的核心管线是"顶点着色器 + 片元着色器"，片元着色器会对每个像素执行一次程序。这个"对每个元素执行同一个程序"的模式，天然就是一个并行计算单元。我们可以把数据编码成纹理（Texture），把计算逻辑写进片元着色器，然后用绘制一个屏幕大小矩形的行为来触发每个像素上的计算，最后把结果从纹理中读出来。

这个思路在 GPU 图形编程领域叫 GPGPU（General-Purpose computing on Graphics Processing Units），在浏览器里最成熟的实现就是 WebGL 和 WebGL2。比如一个 4096×4096 的矩阵乘法，如果用 CPU 跑可能要好几秒，用 WebGL 片元着色器跑可能只需要几十毫秒，效果相差两个数量级。

5.2 数据编码与传输成本

用 WebGL 做计算，最大的麻烦不是写着色器，而是数据进出 GPU 的成本。把 CPU 内存里的数据上传到 GPU 显存、计算完再把结果从 GPU 读回来，这两个方向的传输都会占带宽。如果你的任务本身计算量不大，只是数据量特别大，那传输成本可能超过计算收益，反而不如直接用 CPU 划算。

所以判断一个任务适不适合 GPU，不能只看计算量，还要看计算密度。计算操作数和数据体积的比值越高，越适合交 GPU。比如图像处理里每个像素都要做几百次乘加运算，这种任务密度极高，非常适合 GPU；而只是要把数组里每个元素加 1 这种任务，GPU 的优势就发挥不出来，因为传输数据的功夫已经够 CPU 干完了。

5.3 WebGPU：更现代、更可控的路线

WebGPU 是 WebGL 的下一代继任者，目前在 Chrome、Edge、Firefox 的部分版本已经支持。它提供了更底层的 GPU 控制能力，内存管理和计算管线更清晰，不再像 WebGL 那样要靠"画三角形"来强行做计算。它是单独的 compute shader 通道，直接以通用计算的方式调用 GPU。

不过我要泼一盆冷水：WebGPU 的 API 还比较新，浏览器兼容性参差不齐，学习成本也比 WebGL 高不少。如果你是第一次接触浏览器 GPU 计算，我建议先观察一下线上用户的浏览器环境再决定是否引入。先保证兼容，再追求性能，这个顺序不能乱。

5.4 混合计算的现实选择

实际项目里，我很少把整条链路全丢给 GPU。更常见的做法是：识别出一个大的密集任务里最耗时的 20% 的环节，把那个环节单独抽出来丢给 GPU 或者 Worker，剩下对延迟不敏感的部分留在主线程。这个"二八定律"同样适用于性能优化——你不需要把每一行代码都改到极致，只要把最大的那个瓶颈解决掉，整体体验就能得到指数级改善。

6. 有些任务不需要一次跑完：分片调度与空闲期执行

还有一类情况比较特殊：单个任务确实没有那么重，但你又不想让它在某一瞬间抢占太多时间。比如大列表的渲染、数据的渐进式校验、搜索建议的实时过滤。这类问题的核心思路是 把任务切碎，让主线程有时间喘息，这个思路通常比 Worker 更简单直接。

6.1 时间切片：在宏任务之间插入渲染机会

时间切片（Time Slicing）是一种典型的 "让出主线程" 策略。思路是把一个大循环拆成若干小循环，每个小循环执行完，就把控制权交还给事件循环，让浏览器有机会渲染一帧、处理用户事件，然后再继续下一段。

这里有个现成的工具方法：用 Async/Await 配合定时器实现"切片"。

javascript复制async function processInChunks(items, chunkSize = 100) {
  let index = 0;
  while (index < items.length) {
    const chunk = items.slice(index, index + chunkSize);
    await runChunk(chunk);
    index += chunkSize;
    // 让出主线程，让浏览器处理渲染和事件
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

这里的关键点是 setTimeout(0) 并不代表"零延迟立即执行"，它只是把后续任务排到当前任务队列的末尾。浏览器在执行完当前宏任务后，会先检查是否有渲染帧需要更新，然后再拾起下一个宏任务。这样就给渲染留出了缝隙，页面就不会再卡死了。

这个方案的缺点是总耗时会被拉长，因为每次让出主线程都有一些上下文开销。但它换来了极致流畅的交互体验，在数据展示型业务里非常值。

6.2 用 requestIdleCallback 填充浏览器空闲时间

requestIdleCallback 是一个更聪明的调度方式。它会在浏览器进入空闲状态的时候，调起你的回调函数，并且给你一个 deadline 对象，告诉你还能占用多少时间。你的回调应该在这个时限内分片处理任务，如果处理不完，就安排下一次空闲再继续。

code复制requestIdleCallback(myTask, { timeout: 2000 });

它的使用场景很明确：只适合执行那些"不急、可以等"的任务，比如提前预处理下一步可能要用的数据、埋点上报、非关键路径的格式化。如果你把它用于"用户点击按钮后必须尽快响应"的场景，那就错了——因为浏览器可能长时间没有空闲，回调一直被延后推迟。考虑到兼容性，建议在使用前先判断 requestIdleCallback 是否存在，不存在就回退到 setTimeout 方案。

6.3 任务优先级的合理分配

优化密集任务时，还要学会区分"哪些任务必须现在做，哪些可以稍后做"。传统同步代码写多了，很多人容易陷入一种状态：所有逻辑都堆在一起，一股脑执行完，结果就是一块巨大的长任务。

更好的做法是给任务划分优先级。举个例子：搜索结果页里，真正不能让用户等的是首屏里的前 20 条结果；而统计所有结果的数量、生成图表数据、计算推荐位这些，完全可以放到首屏渲染完成后再做。你可以用一个简单的 queue 加 setTimeout 机制实现"低优先级任务延迟执行"：

javascript复制const lowPriorityQueue = [];

function scheduleLowPriorityTask(task) {
  lowPriorityQueue.push(task);
  if (lowPriorityQueue.length === 1) {
    setTimeout(flushLowPriorityQueue, 0);
  }
}

function flushLowPriorityQueue() {
  const start = performance.now();
  while (lowPriorityQueue.length && performance.now() - start < 10) {
    lowPriorityQueue.shift()();
  }
  if (lowPriorityQueue.length) {
    setTimeout(flushLowPriorityQueue, 0);
  }
}

这种"按批次 + 限时执行"的模式，能确保低优先级任务不会反客为主、把主线程占满。你还可以在其中插入优先级字段，实现一个更灵活的任务队列，用来满足更复杂的业务场景。

6.4 与后端配合的前置计算

有些密集任务其实根本不该放在前端。如果数据量特别大，而且计算结果需要极强的一致性，最合理的方案是把计算挪到后端，或者在后端预处理后直接返回轻量级结果。前端只做展示和交互，承担它最擅长的那部分职责。

比如我前面提到的 CSV 解析场景，与其在前端解析两万行，不如让后端先把文件解析成 JSON，前端直接接 JSON 渲染。前端省去了字符串解析、类型转换、数据结构构造这些苦差事，后端的 CPU 又足够强大，两边一拍即合。性能优化不是一场秀，能用最简单的方案解决问题，就是最好的方案。

7. 踩过这些坑之后，我总结的几条高效实践

讲到这里，该聊的底层原理和方案基本都覆盖了。最后我想从一个实操者的角度，把自己实际几次优化里踩过的坑和对方案选择的重新认识，原原本本分享出来。

7.1 瓶颈转移的坑：优化完一段，卡顿又出现在下一段

第一次做 CSV 解析优化时，我用 Performance 面板定位到耗时最长的循环，把它优化了，耗时降了 40%。结果一测整体流程，发现页面还是卡。为什么？因为那个循环只占总耗时的 40%，剩下的 60% 分散在后面几段代码里。我只优化了一段，其它几段积在一起还是形成了长任务。

优化密集任务，一定要有全景视角。 先把整个流程里的所有耗时任务全部列出来，按耗时从大到小排序，然后逐个击破，而不是只盯着最扎眼的那一个。否则每次优化完，都会发现瓶颈转移到了一个之前没注意到的函数上，整个优化过程会变得又臭又长。

7.2 过度优化也是坏味道

还有一次，我为了让一个两万次循环更快，给里面用了非常复杂的位运算替代取模运算，还用上了各种 V8 小技巧。结果代码可读性大幅下降，同事后来维护的时候花了两天才看懂。更打脸的是，性能测试显示整体提速只有 5%，完全可以通过别的基础优化达到。

这里我得到一个深刻体会：做性能优化先计算投入产出比，不值得为了 5% 的收益把代码复杂度翻倍。 代码是写给人读的，其次才是让机器运行。能用 Worker 把耗时任务移走，就别在主线程抠那些可有可无的语法细节。Worker 方案省下的时间可能远大于代码微优化，而且不会损害可读性。

7.3 一定要在真实环境压测

最后提醒一下：所有优化方案做完，一定要在接近真实用户的环境中做压测。真机环境里会有很多你在本地可能没意识到的变量：内存更小、CPU 可能降频、后台还开着各种其他标签页。推荐用 Chrome DevTools 里的 CPU 4x/6x 降速模拟，再配合多开标签页做内存压力测试。只有在这种"恶劣"条件下页面还能保持流畅，你的优化才算是真正落地了。

我见过太多在开发机上跑得飞快、一上线就卡的案例，原因就是开发机性能太强，把问题掩盖了。性能优化不是做给开发机看的，是做给最差环境的真实用户看的。 这句话值得贴在每个前端开发者的显示器边上。

好了，关于 JS 执行密集型任务的效能提速，我能想到的实操内容基本都倒出来了。这些东西有些来自官方文档，更多来自平时一遍遍压测、一次次看 Performance 面板总结出来的经验。优化本身不是目的，让用户在使用产品时感觉不到计算的存在，才是我们真正想达到的状态。如果你也在处理类似的问题，不妨从自己的项目里挑一个最卡的操作，按文章里的思路走一遍——先量化，再分层优化，最后用压测验证。我相信你会有收获。