用 Web Worker 把大文件解析移出主线程：一次页面卡顿优化实测

一、卡顿从哪里来

上周我在做一个内部日志分析小工具：用户上传一个 12.4MB 的 CSV 日志文件（约 8 万行），页面要把它解析成表格并做汇总统计。最初的实现很直接——FileReader 读完文件后，在主线程里 split、逐行切分字段、再做一次聚合。结果一上传文件，页面就“死”了：按钮点不动、进度条定格、滚动条拖不动，整整卡了约 4.2 秒。

用 Chrome DevTools 的 Performance 面板录了一次，问题很清楚：主线程被一个超过 4 秒的长任务占满。解析本身是纯 CPU 计算，完全不依赖 DOM，这种活本来就不该占着主线程。

二、方案：把解析交给 Web Worker

思路很简单：主线程只负责读文件和更新界面，解析交给 Worker 里的独立线程。文件数据用可转移对象传过去，避免大块内存被结构化克隆复制一份。

主线程这样写：

const worker = new Worker('parse-worker.js');
worker.onmessage = (e) => {
  if (e.data.type === 'progress') {
    updateProgress(e.data.percent); // 进度条照常刷新
  } else if (e.data.type === 'done') {
    renderTable(e.data.rows);      // 只在最后渲染一次
    worker.terminate();
  }
};
const buffer = await file.arrayBuffer();
worker.postMessage({ buffer }, [buffer]); // 转移所有权，不复制

Worker 里只做计算，每处理 1 万行就回传一次进度：

self.onmessage = (e) => {
  const text = new TextDecoder().decode(e.data.buffer);
  const lines = text.split('\n');
  const rows = [];
  for (let i = 0; i < lines.length; i++) {
    rows.push(parseLine(lines[i]));
    if (i % 10000 === 0) {
      self.postMessage({ type: 'progress', percent: Math.round(i / lines.length * 100) });
    }
  }
  self.postMessage({ type: 'done', rows });
};

三、实测数据

同一台电脑、同一个 12.4MB 文件、同一版 Chrome，各测 3 次取平均：

Worker 里的解析本身只快了约 0.6 秒，真正的收益在体验上：页面从“卡死 4.2 秒”变成“全程可操作”，用户能看到进度、能随时取消。卡顿优化很多时候优化的不是总耗时，而是主线程的占用。

四、踩过的几个坑

1. 不要一次性回传超大结果。Worker 一次 postMessage 几万行对象仍会让主线程在接收和渲染时卡一下，改成分批回传或只回传汇总结果，表格按需分页渲染。
2. 一定要接错误处理。Worker 里的异常不会冒泡到主线程，要写 worker.onerror，并在 Worker 内 try/catch 后回传 { type: 'error', message }，否则解析失败时页面会静默地一直转圈。
3. 用完就 terminate。页面是单页应用，Worker 不回收会一直占着线程和内存，解析完成或组件卸载时及时释放。
4. Worker 里没有 DOM。没有 window、document，也不能直接操作页面，所有界面更新都得靠 postMessage 回主线程做。

五、什么时候不值得用

文件小于 1MB、解析不到 50 毫秒时，直接在主线程做更简单：Worker 有创建成本和通信成本，小任务上收益还抵不过开销。我的经验是：解析超过 100 毫秒、或者用户会明显感知到卡顿时，再考虑迁到 Worker。

一句话总结：能移出主线程的纯计算，就别让它占着主线程。Web Worker 的接入成本很低，收益却直接体现在用户能不能点得动页面上。