1. 万级消息下 AI 对话流为什么会卡到崩溃AI 对话类产品有个很隐蔽的性能陷阱会话越长越卡。用户和助手来回上千轮、消息累积到上万条时页面滚动开始掉帧、输入框打字延迟、内存曲线一路往上爬严重时整个标签页直接崩掉。这个现象在长会话场景里几乎必然出现因为大多数前端的第一版实现都是把消息全量渲染成 DOM。我见过最常见的写法是这样div classNamemessage-list {messages.map((msg) ( MessageItem key{msg.id} message{msg} / ))} /div几十条消息时这套写法毫无问题但消息量到万级问题会集中爆发。每条消息不只是纯文本它包含头像、气泡容器、Markdown 渲染后的段落、代码块、有序列表、引用块单条消息轻松产生几十个 DOM 节点一万条就是几十万个节点。浏览器的样式计算、布局、绘制全部要在这几十万节点上跑一遍首屏渲染和每次重排的成本高得离谱。更麻烦的是 AI 回复是流式输出的。逐 token 返回意味着每来一个字符就要触发一次组件更新而messages.map是全量重渲染等于每次 token 到达都在重算上万条消息。Markdown 解析是重灾区代码高亮、复杂表格、内联公式的解析本身就耗时流式过程中反复全量渲染会让 CPU 长时间打满风扇狂转。还有一个容易被忽略的体验问题滚动锚定失效。用户往上翻阅历史消息时如果列表因为新消息插入或高度变化被动重排阅读位置会被强行拽走眼睛刚看到的那段内容瞬间跳没了。这种割裂感比卡顿更让人抓狂。解决思路的核心就是虚拟滚动Virtual Scrolling只渲染可视区域内的消息其余消息用计算出的占位空间代替。它把渲染成本从 O(消息总数) 降到 O(可视消息数)是长会话场景绕不开的基础设施。但光有虚拟滚动还不够AI 对话流有它自己的特殊性——动态高度、流式增量、自动滚动与用户阅读的冲突这些都需要单独处理。下面我会从原理到可复制配置再到压测验证完整走一遍落地路径。2. 虚拟滚动核心原理与 TaoToken 接入前置准备虚拟滚动的本质是「空间换时间」的逆向操作不渲染不可见内容用计算出的空白占位维持滚动条的真实感。它有三个核心概念需要先理清。可视区Viewport是滚动容器的可见高度缓冲区Buffer是在可视区上下额外渲染的少量消息避免快速滚动时出现白屏偏移量Offset是通过累加不可见消息的高度计算出当前内容的平移距离。整体流程是滚动事件触发读取 scrollTop根据消息高度推算 startIndex确定可视区加缓冲区的消息范围只渲染该范围内的消息用上下 padding 撑起总高度再应用 translateY 偏移。这套流程把渲染成本从 O(n) 降到 O(1)。在动手写虚拟列表之前如果你要接入真实的大模型对话流做联调需要先准备好 API 访问凭证。TaoToken 提供了兼容主流协议的统一接口接入前你需要拿到三件套Base URL、API Key、Model ID。Base URL 是https://taotoken.net/apiAPI Key 在控制台的 API Keys 页面创建Model ID 根据你选的模型填写。创建 Key 的入口在这里https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite拿到 Key 之后本地联调时建议用环境变量管理不要硬编码进前端代码。前端直连会暴露 Key生产环境应该走自己的后端代理。本地开发可以这样配置# .env.local VITE_TAOTOKEN_BASE_URLhttps://taotoken.net/api VITE_TAOTOKEN_API_KEYsk-你的key VITE_TAOTOKEN_MODELclaude-sonnet-4-5如果你用的是 Claude Code 这类编码工具做前端开发可以通过 Coding Plan 接入配置方式在文档里有完整说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite接入文档地址https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要说明的是TaoToken 在这里的角色是提供模型对话能力的接口层虚拟滚动是纯前端渲染优化两者是配合关系。你完全可以用 mock 数据先把虚拟列表跑通再接真实流式接口。但真实流式输出的 token 到达节奏、消息高度增长曲线和 mock 数据差别很大所以最终验证一定要用真实接口压测。3. 可复制的虚拟列表配置与滚动锚定参数先跑通定高方案的最小闭环。如果每条消息高度固定虚拟滚动实现非常直接const ITEM_HEIGHT 72; const BUFFER 5; function VirtualChatList({ messages }: { messages: Message[] }) { const containerRef useRefHTMLDivElement(null); const [scrollTop, setScrollTop] useState(0); const [viewportHeight, setViewportHeight] useState(0); useEffect(() { const el containerRef.current; if (!el) return; setViewportHeight(el.clientHeight); const onResize () setViewportHeight(el.clientHeight); window.addEventListener(resize, onResize); return () window.removeEventListener(resize, onResize); }, []); const startIndex Math.max(0, Math.floor(scrollTop / ITEM_HEIGHT) - BUFFER); const visibleCount Math.ceil(viewportHeight / ITEM_HEIGHT) BUFFER * 2; const endIndex Math.min(messages.length, startIndex visibleCount); const visibleMessages messages.slice(startIndex, endIndex); const totalHeight messages.length * ITEM_HEIGHT; const offsetY startIndex * ITEM_HEIGHT; return ( div ref{containerRef} classNamevirtual-list onScroll{(e) setScrollTop(e.currentTarget.scrollTop)} div style{{ height: totalHeight, position: relative }} div style{{ transform: translateY(${offsetY}px) }} {visibleMessages.map((msg) ( MessageItem key{msg.id} message{msg} / ))} /div /div /div ); }这个版本能解决节点爆炸问题但对 AI 对话流远远不够因为聊天消息高度天然不固定一条简短回复可能只有 40px一段带代码块的回答可能有 2000px。所以必须引入动态高度测量。动态高度方案需要在渲染后测量每条消息的真实高度并缓存滚动时基于缓存用二分查找推算位置type MeasuredItem { id: string; height: number; offset: number; // 该消息顶部相对列表总高度的偏移 }; function useVariableVirtualList(messages: Message[]) { const measurementsRef useRef(new Mapstring, MeasuredItem()); const [scrollTop, setScrollTop] useState(0); const [viewportHeight, setViewportHeight] useState(0); const findStartIndex (scrollTop: number) { const items messages; let low 0; let high items.length - 1; while (low high) { const mid (low high) 1; const m measurementsRef.current.get(items[mid].id); if (m m.offset m.height scrollTop) { high mid; } else { low mid 1; } } return low; }; // ... }高度测量依赖 ResizeObserver监听每条消息容器尺寸变化后更新缓存function MessageRow({ message, onResize, }: { message: Message; onResize: (id: string, height: number) void; }) { const ref useRefHTMLDivElement(null); useEffect(() { const el ref.current; if (!el) return; const observer new ResizeObserver((entries) { const height entries[0].contentRect.height; onResize(message.id, height); }); observer.observe(el); return () observer.disconnect(); }, [message.id, onResize]); return ( div ref{ref} MessageItem message{message} / /div ); }滚动锚定是动态高度方案里最关键的一环。高度变化会引发经典问题用户翻阅历史时新消息插入或旧消息高度变化会把他正在看的内容顶走。解决思路是保存滚动锚点以某条可见消息为参照在内容变化后重算 scrollTop让它相对视口的位置保持不变function restoreScrollAnchor( container: HTMLElement, anchorId: string, changeDelta: number, ) { const anchorEl container.querySelector([data-id${anchorId}]); if (!anchorEl) return; const rect anchorEl.getBoundingClientRect(); const containerRect container.getBoundingClientRect(); container.scrollTop rect.top - containerRect.top - changeDelta; }浏览器原生提供的 CSSoverflow-anchor可以缓解这个问题但它对「虚拟列表 高度剧烈变化」的组合支持并不完美关键路径上仍建议用 JS 手动锚定兜底。锚定策略的参数建议这样设锚点选择当前视口顶部第一条可见消息高度变化量超过 1px 才触发修正修正时用requestAnimationFrame包裹避免和滚动事件打架。流式输出下的增量更新需要做渲染节流。AI 回复逐 token 到达时如果每来一个 token 都触发整条消息的 Markdown 全量重渲染CPU 会被解析器吃满。工程上以固定频率批量落盘到 UIuseEffect(() { if (!streamingDelta) return; const timer setTimeout(() { flushStreamingContent(streamingDelta); }, 50); return () clearTimeout(timer); }, [streamingDelta]);自动滚动与用户阅读的冲突也要处理。当用户距底部小于阈值时视为跟随模式自动滚到底部一旦用户主动往上滚动立即退出跟随模式并给出「回到底部」的悬浮按钮function shouldAutoScroll(container: HTMLElement) { const distanceToBottom container.scrollHeight - container.scrollTop - container.clientHeight; return distanceToBottom 40; }4. 验证请求与压测确认万级消息下滚动稳定配置写完之后必须用真实数据验证收益否则你无法判断优化是否生效。验证分两步先确认模型接口能正常返回流式数据再对虚拟列表做压力测试。先验证接口连通性。用 curl 发一个流式请求确认 Base URL、Key、Model ID 三件套正确curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: claude-sonnet-4-5, stream: true, messages: [ {role: user, content: 用 200 字解释虚拟滚动} ] }如果返回的是逐块 SSE 数据流说明接口正常。你也可以直接在模型对话页面手动验证模型是否可用https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite接口通了之后构造压测数据。以 10000 条消息、平均每条 5 个 Markdown 段落为例对比全量渲染和虚拟滚动的指标指标全量渲染虚拟滚动后DOM 节点数约 280,000约 2,500首屏渲染耗时3200ms180ms 左右流式输出 CPU 占用持续 90%峰值 35% 左右滚动帧率25fps 以下55fps 以上压测时用 Chrome DevTools 的 Performance 面板录制滚动过程重点看三件事主线程是否有长任务阻塞、滚动帧率是否稳定在 55fps 以上、内存曲线是否随滚动持续上涨。如果内存持续上涨说明离开视口的消息没有被正确释放检查 ResizeObserver 是否在组件卸载时 disconnect以及图片是否加了loadinglazy。流式输出的验证要单独做。让模型连续输出一段长回复观察打字机效果期间 CPU 占用。如果没做节流你会看到 CPU 曲线在输出期间一直贴着高位做了 50ms 节流后曲线会变成有节奏的波峰波谷。同时观察滚动位置在流式输出过程中手动往上滚动如果阅读位置被拽回底部说明跟随模式的退出逻辑没生效。落地顺序建议按这个节奏推进每一步都能独立验证、快速回滚先接入虚拟列表保证不崩不卡撑住万级消息量再处理动态高度测量与滚动锚定保证翻阅历史不跳动然后对流式输出做渲染节流降低打字机效果期间的 CPU 开销接着加入自动滚动的交互策略兼顾跟随与不打扰最后做内存与图片懒加载优化处理长会话的持久化场景。5. 常见报错排查401、local proxy failed 与 reading choices接入和压测过程中会遇到几类典型报错这里按真实错误信息逐一排查。401 Unauthorized。这是最常见的鉴权失败。先检查请求头里的Authorization字段格式必须是Bearer sk-xxxBearer 和 Key 之间有一个空格很多人漏掉。再确认 Key 没有多余空格或换行从控制台复制时容易带上尾部空白。如果 Key 确认无误仍报 401检查是不是用了已删除或过期的 Key去 API Keys 页面重新创建一个https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewritelocal proxy failed。这个报错通常出现在本地开发环境说明请求没有正确到达目标地址。检查 Base URL 是否写成了https://taotoken.net/api注意结尾不要多加/v1或斜杠路径拼接错误会导致请求打到不存在的端点。如果你在 Vite 或 Next.js 里配了 devServer 代理检查 proxy 配置的 target 和 rewrite 规则是否把路径改错了。前端直连时还要确认没有浏览器扩展拦截请求。reading choices 报错。这类错误一般是解析响应结构时字段对不上。流式响应的每个 chunk 结构是choices[0].delta.content非流式是choices[0].message.content。如果你按非流式的结构去解析流式数据就会读到 undefined 然后报错。检查你的解析逻辑是否根据stream参数走了不同分支。另外流式响应的最后一个 chunk 的delta可能是空对象解析前要判空。OAuth 相关报错。如果你用 Claude Code 或类似工具接入遇到 OAuth 报错通常是认证方式选错了。这类工具应该用 API Key 方式接入而不是走 OAuth 登录流程。在工具的配置文件里把认证方式改成 API Key填入 Base URL 和 Key。以 Claude Code 为例配置项需要同时写全 Base URL、API Key、Model ID 三件套缺一个都会认证失败。滚动跳动排查。如果虚拟列表接好了但滚动时位置乱跳先检查测量时机。ResizeObserver 的回调是异步的如果高度还没测量完就参与位置计算会导致 offset 错乱。解决方法是给未测量的消息一个预估高度测量完成后再修正并用锚点补偿高度差。再检查二分查找的边界条件findStartIndex在 scrollTop 为 0 或接近总高度时容易越界。流式输出卡顿排查。如果节流做了还是卡检查是不是每次 token 到达都触发了整个列表的 state 更新。流式内容应该只更新当前正在输出的那一条消息已完成的旧消息走 memo 缓存不参与重渲染。用 React DevTools 的 Profiler 看哪些组件在重复渲染把 MessageItem 用React.memo包起来props 里避免传每次新建的对象或函数。6. 从虚拟滚动到完整对话流性能方案AI 对话流的性能调优虚拟滚动只是切入点真正拉开差距的是它背后的一整套组合拳动态高度测量、滚动锚定、流式渲染节流、自动滚动交互、内存懒释放。这五件事缺一件长会话体验都会有明显短板。核心思路可以浓缩成三句话用「只渲染可视区」把渲染成本从 O(n) 降到 O(1)用「缓存加增量」把流式输出从全量重渲染变成定点更新用「锚点加交互策略」让性能优化不牺牲阅读体验。当消息量从百级走向万级这些优化不是锦上添花而是产品能否继续使用的分水岭。如果你还在早期阶段建议先用 mock 数据把虚拟列表和锚定逻辑跑通再接真实流式接口。接入时记得把 Base URL、API Key、Model ID 三件套配全本地用环境变量管理生产走后端代理。需要长期做编码和 Agent 类开发的话Coding Plan 的接入方式会更顺手https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite最后留一个我踩过的坑虚拟列表的缓冲区不要设太大。BUFFER 设成 5 到 10 足够覆盖快速滚动设成 50 会让可视区外的渲染量翻好几倍反而拖慢帧率。缓冲区大小要根据单条消息的平均高度动态调整消息越高缓冲区条数应该越少。