用Web Worker解析AI返回的大文本不卡UI

AI 一口气返回一篇几万字、夹着几十段代码和表格的长文，前端在主线程做 markdown 解析 + 语法高亮，页面直接卡成 PPT。这次把解析挪进 Web Worker，主线程只管渲染，记录一下踩坑过程。原生 Worker，不依赖框架。

先确认到底卡在哪

别凭感觉优化。打开 Performance 面板录一段，我这边明确看到：长亮条几乎全在 highlight() 和 markdown 的 token 化上，单次能跑 200ms+。主线程一被占 200ms，输入框打字、滚动全部掉帧。这种纯计算、不碰 DOM 的活，正是 Worker 的菜。

把解析搬进 Worker

Worker 里只做「文本进、HTML 字符串出」，绝不碰 DOM（Worker 里也没有 DOM）。语法高亮用能在 Worker 跑的库（highlight.js 这类纯 JS 的就行）。

parser.worker.js：

javascript 复制代码

import { marked } from 'marked';
import hljs from 'highlight.js';

marked.setOptions({
  highlight: (code, lang) =>
    hljs.getLanguage(lang)
      ? hljs.highlight(code, { language: lang }).value
      : hljs.highlightAuto(code).value,
});

self.onmessage = (e) => {
  const { id, text } = e.data;
  try {
    const html = marked.parse(text);
    self.postMessage({ id, html });
  } catch (err) {
    self.postMessage({ id, error: String(err) });
  }
};

Vite/webpack 里这样实例化：

go 复制代码

const worker = new Worker(
  new URL('./parser.worker.js', import.meta.url),
  { type: 'module' }
);

主线程：用 id 配对请求和结果

Worker 是异步的，连续发好几段文本回来顺序不保证，得用一个自增 id 把请求和回包对上：

ini 复制代码

let seq = 0;
const pending = new Map();

worker.onmessage = (e) => {
  const { id, html, error } = e.data;
  const job = pending.get(id);
  if (!job) return;
  pending.delete(id);
  error ? job.reject(new Error(error)) : job.resolve(html);
};

function parseInWorker(text) {
  return new Promise((resolve, reject) => {
    const id = ++seq;
    pending.set(id, { resolve, reject });
    worker.postMessage({ id, text });
  });
}

流式场景的关键取舍

AI 是逐字流式返回的，最天真的做法是每来一个 delta 就整篇丢进 Worker 重解析一遍。文本越长，每次全量解析越慢，到后面 Worker 也开始堆积。两个办法：

一是节流。 不要每帧都解析，攒一段或隔一段时间解析一次：

ini 复制代码

let timer = null, latest = '';
function onDelta(fullText) {
  latest = fullText;
  if (timer) return;
  timer = setTimeout(async () => {
    timer = null;
    const html = await parseInWorker(latest);
    render(html);
  }, 60);   // 60ms 一拍，够顺滑也不压垮 Worker
}

二是丢弃过期结果。 节流期间用户可能已经收到更新的文本，旧的解析结果回来直接扔掉。配合上面的 seq，只认最新那个 id 的结果。

别忽略的两个细节

postMessage 传大字符串有拷贝成本。 几万字的字符串来回拷贝本身也要时间。我实测几万字范围内可以接受；要是真到几十万字，得考虑分块解析、或用 ArrayBuffer + transferable 把数据所有权转过去而非拷贝。
v-html / innerHTML 的 XSS。 Worker 出来的 HTML 在塞进 DOM 前最好过一遍 DOMPurify（这步得在主线程做，Worker 里没有 DOM）。AI 返回的内容不可全信，markdown 里藏 <img onerror> 是真会发生的。

老实说的缺点

引入 Worker 不是白嫖。多了构建配置、多了一份打包产物、调试时断点要切到 Worker 上下文，体感比主线程麻烦。文本不长（几千字以内）其实主线程 + requestIdleCallback 切片就够了，没必要上 Worker。我是确实有「长报告」场景才上的。

补一句背景。这些长文本是哪来的？我用讯飞Agent生成的------它是 MaaS，现成大模型 API，长文档总结这类输出特别能产出大段 markdown。我自己没部署模型，就专心在前端把渲染性能这块抠顺，Worker 这套刚好接住它吐的大文本。