AI 对话流性能调优：万级消息的虚拟滚动落地

AI 对话流性能调优：万级消息的虚拟滚动落地

一、流式输出与万级消息：对话前端的性能塌陷

大模型对话产品的交互形态决定了消息列表是一个「持续追加、永不卸载」的长列表。用户在一次会话中可能产生数百轮对话，叠加长回答与多模态附件，单会话消息数轻易突破数千条；在客服、研究助手等重度场景下，万级消息并非罕见。每条消息的渲染成本并不低：Markdown 解析、代码语法高亮、KaTeX 数学公式、图片懒加载、引用气泡，这些子组件叠加后，单条消息的 DOM 节点数往往超过 200。

直接全量渲染会触发三类性能塌陷：首屏渲染阻塞（同步解析数千条消息导致主线程长时间占用）、滚动帧率下降（重排重绘成本随可见节点数指数上升）、内存峰值飙升（每条消息的 React Fiber 与 DOM 节点常驻内存）。更棘手的是流式输出：模型逐 token 返回，每秒触发十数次到数十次状态更新，若每次更新都引发整个列表的重渲染，主线程会被持续占用，滚动直接掉帧。

虚拟滚动（virtual scrolling）是这一场景的标准解法：只渲染可视区及其缓冲区的少量消息，离屏消息回收 DOM。但 AI 对话场景对虚拟滚动提出了三个独特挑战：消息高度动态变化（流式输出时高度持续增长）、消息内容异构（文本、代码块、图片高度差异巨大）、用户交互锚定（新消息到达时需保持当前阅读位置）。这三个挑战决定了通用虚拟列表库（如 react-window 的固定高度模式）无法直接套用，需要工程化的动态高度方案。

二、虚拟滚动的渲染管线：可视窗口与回收机制

虚拟滚动的核心是「以位置代替渲染」：维护一份所有消息的预估高度与偏移量索引，根据滚动位置计算出当前应渲染的消息区间，仅对该区间内的消息挂载真实 DOM。

┌──────────────────────────────────────────────┐
│ 消息列表（10000 条，逻辑存在） │
│ msg[0] offset: 0 height: 120 (预估) │
│ msg[1] offset: 120 height: 340 (实测) │
│ … │
│ msg[5000] offset: 1.2M height: 280 │
│ … │
│ msg[9999] offset: 2.4M height: 150 │
└──────────────────────────────────────────────┘
│ scrollTop = 1.18M
▼
┌──────────────────────────────────────────────┐
│ 可视窗口（viewport: 800px）+ 缓冲(上下各 3 条) │
│ ┌────────────────────────────────────────┐ │
│ │ msg[4998] (实测 280) ← 缓冲上 │ │
│ │ msg[4999] (实测 340) │ │
│ │ msg[5000] (实测 280) ← 可视区 │ │
│ │ msg[5001] (实测 410) │ │
│ │ msg[5002] (实测 150) ← 缓冲下 │ │
│ └────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘
│
▼ 滚动 → 重新计算区间 → 复用/回收 DOM

关键数据结构是「偏移量索引」，它将消息 id 映射到 (offsetTop, height)。理想情况下该索引支持二分查找，使任意 scrollTop 都能在 O(log n) 内定位起始消息。高度分两类：未渲染消息使用预估高度（基于消息类型与字符数的启发式估算），已渲染消息使用实测高度（通过 ResizeObserver 采集）。

动态高度的难点在于：预估高度与实测高度存在偏差，当消息进入可视区被实测后，其高度的修正会引发后续消息偏移量的连锁更新，导致滚动条抖动。工程上需要「向前补偿」机制：当某条消息实测高度大于预估时，把多出的高度从已渲染的上方消息偏移中扣除，保持当前可视内容的位置不变。

三、生产级实现：动态高度与流式追加的兼容

下面是一个面向 AI 对话场景的动态高度虚拟列表实现，核心处理三件事：高度索引的二分查找、流式输出时的滚动锚定、ResizeObserver 的高度采集与回写。

// virtual-messages.ts —— AI 对话消息流的虚拟列表核心
import { useCallback, useEffect, useRef, useState } from 'react';

interface MessageMeta {
id: string;
estimatedHeight: number; // 启发式预估高度
measuredHeight: number | null; // 实测高度，未渲染时为 null
isStreaming: boolean; // 是否正在流式输出
}

// 二分查找：返回第一个 offsetTop + height > scrollTop 的消息索引
function findStartIndex(
metas: MessageMeta[],
scrollTop: number,
): number {
let lo = 0;
let hi = metas.length – 1;
while (lo < hi) {
const mid = (lo + hi) >> 1;
const offset = getOffset(metas, mid);
if (offset + getHeight(metas[mid]) > scrollTop) {
hi = mid;
} else {
lo = mid + 1;
}
}
return lo;
}

function getHeight(m: MessageMeta): number {
// 未实测时用预估，避免索引构建阻塞主线程
return m.measuredHeight ?? m.estimatedHeight;
}

// 计算第 index 条消息的 offsetTop（前缀和）
// 生产环境应配合前缀和缓存优化到 O(1)，此处保留线性实现便于阅读
function getOffset(metas: MessageMeta[], index: number): number {
let offset = 0;
for (let i = 0; i < index; i++) {
offset += getHeight(metas[i]);
}
return offset;
}

export function useVirtualMessages(
messages: MessageMeta[],
viewportHeight: number,
overscan = 3,
) {
const containerRef = useRef<HTMLDivElement>(null);
const [scrollTop, setScrollTop] = useState(0);
const [metas, setMetas] = useState(messages);

// 滚动节流：用 rAF 合并高频滚动事件，避免 setState 风暴
const rafId = useRef<number>(0);
const onScroll = useCallback((e: React.UIEvent<HTMLDivElement>) => {
if (rafId.current) cancelAnimationFrame(rafId.current);
rafId.current = requestAnimationFrame(() => {
setScrollTop(e.currentTarget.scrollTop);
});
}, []);

// 计算可视区间，叠加 overscan 作为缓冲
const startIndex = findStartIndex(metas, scrollTop);
let endIndex = startIndex;
let accHeight = 0;
while (endIndex < metas.length && accHeight < viewportHeight + overscan * 200) {
accHeight += getHeight(metas[endIndex]);
endIndex++;
}
const renderStart = Math.max(0, startIndex – overscan);
const renderEnd = Math.min(metas.length, endIndex + overscan);

// 渲染层注册的待测量节点，由消息组件挂载时写入
const measureNodesRef = useRef<Map<string, HTMLElement>>(new Map());

// ResizeObserver 采集实测高度并回写索引
useEffect(() => {
if (typeof ResizeObserver === 'undefined') return;
const ro = new ResizeObserver((entries) => {
setMetas((prev) => {
let changed = false;
const measured = new Map<string, number>();
for (const entry of entries) {
const id = (entry.target as HTMLElement).dataset.msgId;
if (!id) continue;
const h = entry.contentRect.height;
measured.set(id, h);
}
const next = prev.map((m) => {
const h = measured.get(m.id);
if (h != null && h !== m.measuredHeight) {
changed = true;
return { …m, measuredHeight: h };
}
return m;
});
return changed ? next : prev;
});
});
// 观察当前渲染区间的消息节点（由渲染层注册 ref）
measureNodesRef.current.forEach((node) => {
if (node) ro.observe(node);
});
return () => ro.disconnect();
}, [renderStart, renderEnd]);

// 流式消息高度变化时，保持用户当前阅读位置不跳动
const anchorRef = useRef<{ id: string; offsetFromTop: number } | null>(null);
useEffect(() => {
if (!anchorRef.current || !containerRef.current) return;
const { id, offsetFromTop } = anchorRef.current;
const idx = metas.findIndex((m) => m.id === id);
if (idx < 0) return;
const newTop = getOffset(metas, idx) + offsetFromTop;
// 仅在偏差超过 1px 时校正，避免与用户主动滚动冲突
if (Math.abs(containerRef.current.scrollTop – newTop) > 1) {
containerRef.current.scrollTop = newTop;
}
}, [metas]);

return {
containerRef,
onScroll,
measureNodesRef,
renderRange: [renderStart, renderEnd] as const,
totalHeight: getOffset(metas, metas.length),
offsetY: getOffset(metas, renderStart),
};
}

流式输出场景下，最后一条消息的高度会随 token 追加持续增长。若用户正在阅读历史消息（非滚动到底部），直接更新索引会导致可视内容跳动。上面的 anchorRef 机制记录「用户当前可视区第一条消息的 id 及其相对可视区顶部的偏移」，在高度索引更新后重新校正 scrollTop，使可视内容保持原位。

错误处理与降级：当 ResizeObserver 在某些环境（如旧版 WebView）不可用时，应降级为「固定预估高度 + 滚动到指定消息时再实测」的策略，并在控制台告警。流式消息的 token 追加应通过 queueMicrotask 合批，避免每个 token 触发一次 React 状态更新。上游消息流断连时，需在 3 秒内重试一次，失败后明确提示用户「连接中断」，而非静默卡住。

四、虚拟滚动的代价：可访问性与搜索的折中

虚拟滚动用空间换性能，但其代价往往在性能之外显现，落地前必须明确以下边界。

第一，浏览器原生 Ctrl+F 搜索失效。 离屏消息的 DOM 被回收，浏览器无法在未渲染的文本中匹配关键词。工程上的缓解方案有两种：一是实现应用内的全文搜索（维护一份消息文本的内存索引，搜索结果点击后滚动到对应消息并临时渲染），二是保留一个隐藏的「搜索镜像层」存放所有消息的纯文本（牺牲部分内存换取原生搜索可用）。前者工程量大但内存可控，后者实现简单但削弱了虚拟滚动的内存收益。

第二，屏幕阅读器无法读取未渲染内容。 ARIA Live Region 只能播报当前 DOM 中存在的消息，虚拟滚动导致历史消息对辅助技术「不可见」。需要为消息列表提供「加载更多历史」的显式按钮，并通过 aria-rowcount、aria-rowindex 声明完整的逻辑行数，让辅助技术感知到列表的总体规模。

第三，滚动条高度抖动。 预估高度与实测高度的偏差会导致总高度频繁变化，滚动条 thumb 尺寸跳动。缓解方案是：预估高度采用「按消息类型分桶的统计均值」（如纯文本消息均高 120px、含代码块消息均高 340px），并定期用已渲染消息的实测均值更新分桶系数，使偏差控制在 10% 以内。

第四，流式输出时的新消息锚定与「滚动到底部」冲突。 用户在阅读历史消息时，新消息到达不应抢占滚动位置；用户在底部时，新消息应自动滚动到底部。需要维护「用户是否在底部」的状态，判定阈值通常为 scrollTop + clientHeight >= scrollHeight – 32（留 32px 容差，避免用户轻微滚动后丢失自动跟随）。

第五，复杂消息组件的测量开销。 含图片、代码高亮、公式的消息在首次渲染时高度可能多次变化（图片加载、字体加载、KaTeX 异步渲染）。ResizeObserver 会触发多次回调，每次都引发索引更新与滚动校正。工程上应对单条消息设置「测量稳定窗口」（如 300ms 内无高度变化才视为稳定），稳定前不回写索引，避免抖动。

适用边界与禁用场景：

五、总结

AI 对话流的虚拟滚动落地，核心是「动态高度索引 + 流式锚定 + 测量稳定窗口」三件套。落地步骤为：首先建立基于消息类型分桶的预估高度模型，作为索引初始化基准；其次实现偏移量索引的二分查找，保证万级消息下的滚动定位性能；接着用 ResizeObserver 采集实测高度并回写索引，配合向前补偿消除滚动条抖动；然后实现流式输出的滚动锚定，保证用户阅读历史消息时新消息追加不抢占位置；最后补充应用内全文搜索与 ARIA 声明，弥补虚拟滚动对可访问性的削弱。

虚拟滚动不是单纯的性能优化，而是一次渲染模型的重新设计。它把「全量渲染」转变为「按需渲染 + 位置索引」，必然带来搜索、可访问性、测量稳定性的额外工程成本。在短会话场景下，这些成本可能超过收益，应保持全量渲染的简单实现；在长会话场景下，虚拟滚动是不可替代的方案，但必须把上述边界问题纳入设计范围，而非作为事后补丁。