前端AI应用开发：流式渲染与状态管理工程实践

1. 这个系列到底在写什么，为什么第四篇才是真正的分水岭

“前端手摸手跑路之 AI 应用开发”这个系列，我从第一篇追到第四篇，越看越觉得它踩中了一个很真实的痛点：前端开发者想往 AI 应用方向靠，但市面上要么是纯算法视角的论文式教程，要么是后端工程师写的 API 调用示例，真正从“前端怎么落地一个能用的 AI 应用”这个角度切入的内容少得可怜。第四篇之所以关键，是因为前三篇基本在铺基础设施——环境搭建、模型接口对接、基础对话流打通，而到了第四篇，才开始碰真正的工程问题：流式输出怎么在前端优雅地渲染、多轮对话的状态怎么管理、上下文超长之后怎么截断、以及一个前端工程师在 AI 应用开发里到底该承担哪些职责边界。

我先把结论放前面：前端做 AI 应用开发，核心竞争力不在于你会不会调大模型 API，而在于你能不能把“不确定性极强的模型输出”包装成“用户体验稳定的产品界面”。这句话听起来有点抽象，但你在实际项目里踩过几次坑之后就会明白——模型返回慢、返回格式飘、返回内容长、返回中途断掉，这些全是前端要兜住的事。第四篇讲的就是这些兜底逻辑。

这篇文章适合三类人看：第一类是有 Vue 或 React 基础、想切入 AI 应用方向的前端；第二类是在做 AI 产品但流式渲染和状态管理一直写得很别扭的开发者；第三类是想搞清楚“AI 应用开发工程师”这个岗位到底要求什么能力的人。我会把第四篇涉及的核心技术点拆开，补上原系列可能没展开的工程细节，再结合我自己做过的几个 AI 对话类项目的经验，把踩过的坑和验证过的方案都摊开讲。

2. 第四篇的核心命题：把“流”变成“稳”

2.1 为什么流式输出是前端在 AI 应用里的第一个硬骨头

大模型的响应天生就是流式的。你调一次接口，它不是等全部生成完再一次性返回，而是一个 token 一个 token 地吐出来。这个特性对后端来说只是数据传输方式，但对前端来说，它直接决定了整个交互架构。如果你还用传统的“请求-等待-渲染”三段式思维去做，用户会盯着一个空白页面等十几秒，体验直接崩掉。

第四篇里我注意到一个很关键的转变：它不再把 AI 接口当成普通 REST 接口来处理，而是引入了 SSE（Server-Sent Events）或者基于 fetch 的 ReadableStream 来接收流式数据。这个选择背后有明确的工程考量。WebSocket 虽然也能做流式，但它是双向的，对于“用户发一句、模型回一段”这种单向流场景来说太重了，而且连接维护成本高。SSE 是单向服务端推送，天然适配这种场景，浏览器原生支持 EventSource，虽然 EventSource 只支持 GET 请求、不能自定义 header，所以很多项目会改用 fetch + ReadableStream 手动解析流。

我实测下来，fetch + ReadableStream 的方案灵活性最高，因为你可以自由控制请求头、请求体，还能在中途 abort。但它的代价是你得自己处理分块解析，因为流返回的是 Uint8Array，需要手动 decode 成字符串，再按行或按 SSE 格式切分。这里有个很容易踩的坑：中文字符在 UTF-8 编码下可能被切分到两个 chunk 里，如果你直接对每个 chunk 单独 decode，会出现乱码。正确做法是用 TextDecoder 并开启 stream 模式，让它自己处理跨 chunk 的字符边界。

const decoder = new TextDecoder('utf-8'); const reader = response.body.getReader(); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); // 按 SSE 格式切分处理 const lines = buffer.split('\n'); buffer = lines.pop(); // 最后一行可能不完整，留到下次 for (const line of lines) { if (line.startsWith('data: ')) { const data = line.slice(6); if (data === '[DONE]') return; // 解析并渲染 } } }

这段代码看起来简单，但buffer的保留逻辑和stream: true这两个细节，是我见过最多人写错的地方。少了任何一个，中文就会间歇性乱码，而且这种 bug 很难复现，因为取决于网络分块时机。

2.2 多轮对话的状态管理，别再用 useState 硬撑了

第四篇另一个重点是对话状态的管理。前三篇可能只做了单轮问答，到第四篇开始处理多轮上下文。很多人的第一反应是用一个数组存消息列表，每条消息有 role 和 content，然后每次请求把整个数组发给后端。这个思路没错，但问题在于：当对话轮次多了之后，这个数组会变得非常大，每次请求都全量发送，token 消耗爆炸，而且前端渲染长列表也会卡。

我在实际项目里的做法是分两层管理：一层是“展示用的消息列表”，一层是“发送给模型的上下文窗口”。展示列表可以无限长，用户往上翻能看到所有历史；但发送给模型的上下文需要做截断策略。常见的截断策略有三种：按轮次截断（只保留最近 N 轮）、按 token 数截断（估算总 token 不超过模型上限的某个比例）、以及摘要压缩（把早期对话用模型总结成一段话）。第四篇里我推测它用的是按轮次截断，因为实现最简单，对于大多数场景够用。

但这里有个细节值得展开：截断的时候不能把 system prompt 截掉，也不能让对话历史出现“用户发了消息但助手没回复”的断裂。我一般会保留 system 消息 + 最近 N 轮完整对话，如果 N 轮之后还有空间，再往前补。另外，前端做 token 估算不需要精确，用字符数除以 1.5 到 2 之间的系数粗略估算就够了，精确计算交给后端或专门的 tokenizer 库。

状态管理工具的选择上，如果项目是 Vue3，用 Pinia 管理对话 store 比用 ref 散落在组件里清晰得多；React 的话 Zustand 或 Jotai 都比 Redux 轻。关键是要把“流式接收中的临时状态”和“已完成的消息状态”分开，因为流式接收时内容在不停变化，如果直接往消息列表里 push 一个不断更新的对象，会触发大量无意义的重渲染。

3. 前端在 AI 应用里的职责边界，比你想的要宽

3.1 不只是画界面，你要兜住模型的“不确定性”

传统前端开发里，后端返回的数据结构是确定的，你按约定渲染就行。但 AI 应用里，模型返回的内容格式是不确定的。它可能返回 Markdown、可能返回 JSON、可能返回一半突然断了、可能在 JSON 外面包一层自然语言。前端如果假设“返回的一定是标准格式”，那线上一定会出问题。

第四篇里我看到的处理思路是：在渲染层做“渐进式降级”。具体来说，流式接收到的内容先按纯文本渲染，等流结束后再尝试解析 Markdown 或结构化数据。这样做的好处是用户能立刻看到内容在往外冒，而不是等解析完才显示。如果解析失败，就退化成纯文本展示，至少不会白屏。

代码高亮也是同理。AI 应用里模型经常返回代码块，如果你在流式过程中就实时高亮，性能会很差，因为每来一个字符都要重新解析。我的做法是流式过程中用等宽字体纯文本展示，流结束后再触发一次高亮渲染。这个细节在第四篇里可能没展开，但实际项目里对流畅度影响很大。

还有一个容易被忽略的点：模型返回的内容里可能包含 HTML 标签或脚本。如果你直接用 v-html 或 dangerouslySetInnerHTML 渲染，会有 XSS 风险。必须做 sanitize，或者干脆用 Markdown 渲染库并禁用原始 HTML。这个安全边界前端必须自己守住，不能指望模型“不会返回恶意内容”。

3.2 错误处理和重试，AI 应用的可用性全靠这里

大模型接口的失败率比普通接口高得多。超时、限流、内容审核拦截、模型过载，各种情况都会出现。第四篇如果涉及了错误处理，那它的价值就很高，因为这是区分“demo”和“产品”的分水岭。

我的经验是至少要做三层处理：第一层是请求层的超时和 abort，用户切换会话或关闭页面时要能中断正在进行的流；第二层是业务层的重试，对于限流和临时故障，做指数退避重试；第三层是 UI 层的降级，重试失败后要给用户明确的提示和“重新生成”按钮，而不是转圈转到天荒地老。

这里有个实操技巧：流式请求的中断不能只靠 AbortController，因为有些后端在连接断开后仍然会继续生成（浪费 token）。如果后端支持，最好在 abort 的同时发一个取消信号。另外，重试的时候要注意不要把已经接收了一半的内容丢掉，要么从头重试并清空，要么从断点续传（后者实现复杂，一般不做）。

4. 从第四篇延伸出去：一个完整 AI 应用前端的落地清单

4.1 技术选型和目录结构，别一上来就堆功能

如果你跟着这个系列做到第四篇，准备自己起一个完整项目，我建议先把目录结构定清楚。我常用的结构是这样的：api目录放模型接口封装和流式解析逻辑，stores放对话状态，components放消息气泡、输入框、流式光标这些原子组件，composables或hooks放流式接收、自动滚动、token 估算这些可复用逻辑。这样分层的好处是，流式解析这种容易出 bug 的逻辑被隔离在 api 层，测试和替换都方便。

技术栈上，Vue3 + Pinia + TypeScript 是我目前最推荐的组合，TypeScript 在 AI 应用里尤其重要，因为消息类型、流式事件类型、错误类型都需要明确定义，不然协作和重构会很痛苦。UI 库用 Element Plus 或 Ant Design Vue 都行，但消息列表建议自己写，因为 AI 对话的交互细节（流式光标、代码块复制、消息重新生成）通用组件库覆盖不了。

4.2 性能优化：长对话列表和流式渲染的冲突怎么解

当对话超过几十轮，消息列表的渲染就会成为瓶颈，而流式渲染又在不停地触发更新，两者叠加会明显卡顿。我的解法是：流式中的那条消息单独用一个组件渲染，不放进主列表的响应式数组里，等流结束后再合并进去。这样流式更新只影响一个组件，不会导致整个列表 diff。

另外，消息列表用虚拟滚动是必要的，但虚拟滚动和“自动滚动到底部”会打架。我的做法是监听用户是否手动向上滚动，如果用户在看历史消息，就停止自动滚动，并在底部显示“有新消息”的提示按钮。这个交互细节在 AI 应用里很关键，因为用户经常会在模型生成时往上翻看之前的对话。

4.3 常见问题速查

这张表里的每一条，都是我在实际项目里真实遇到过的。尤其是第一条和第二条，几乎每个做流式 AI 应用的人都会踩一遍。

5. 我个人的一些实操心得

做 AI 应用前端这段时间，最大的体会是：这个方向和传统前端最大的区别，在于你要习惯和“不确定性”共处。传统前端可以把接口契约卡得很死，但 AI 应用的契约是模糊的，模型的行为你控制不了，你只能控制自己怎么响应。所以前端的价值反而更大了，因为用户体验的上限和下限，很大程度上由前端决定。

另外，别被“AI 应用开发工程师”这个 title 吓到。它不要求你会训练模型、会调参、会写推理框架。它要求的是你能把模型能力产品化，而这恰恰是前端最擅长的事——把复杂的技术包装成用户能用的界面。第四篇之所以重要，就是因为它开始触碰这些产品化的核心问题。如果你能把流式渲染、状态管理、错误兜底这三件事做扎实，你就已经超过大部分只会调 API 的开发者了。

最后分享一个小技巧：在开发阶段，用一个 mock 的流式接口来模拟各种异常情况（慢速、中途断开、返回乱码、返回超长内容），比等真实接口出问题再排查高效得多。我一般会写一个简单的 Node 脚本，按字符间隔推送预设文本，这样前端的所有边界情况都能在本地复现和修复。这个习惯帮我省了大量联调时间，也让我对流的理解深了很多。