从零构建流式 AI 对话框：原生缓冲处理与前端工程化实践

引言

越来越多的对话式产品不再让用户盯着空白页面等待完整回复，而是像真人对话一样逐字呈现答案。这种“边说边显示”的交互模式，不仅显著降低用户对等待的焦虑，也让系统有机会在生成过程中持续反馈状态。要实现这一效果，前端不能只等待一个完整的 HTTP 响应，而需要具备接收、解码、累积并逐段渲染数据流的能力。

本文将围绕流式输出这一核心场景，从浏览器如何处理二进制数据块讲起，再结合 Vue 3 与 Vite 构建一个可运行的流式聊天界面。文中会给出关键代码结构与实现说明，既兼顾初学者对 Buffer 的理解，也为有经验的开发者提供工程化参考。

第一章：流式输出为什么重要

1.1 交互体验的差异

传统非流式接口通常由服务端完整计算后再一次性返回。例如用户提问后，客户端需要等待数秒甚至更久，期间界面只能通过加载动画提示“正在生成”。一旦生成时间较长，用户可能怀疑请求失败，或产生重复点击、离开页面等行为。

流式输出则不同。服务端可以在生成第一段文本时立即发送，客户端收到后马上渲染。用户看到文字陆续出现，会更自然地认为系统正在持续工作，等待的感知时间明显缩短。即使总耗时不变，分块到达也能让体验更顺畅。

1.2 技术层面的要求

流式输出要求客户端具备三方面能力：

1. 以流模式发起请求：告知浏览器不要等待完整响应体，而是持续读取数据分片。
2. 正确处理二进制数据：网络传输的原始内容是二进制块，而非直接可用的字符串。
3. 管理渲染状态：将多次到达的数据块累积成完整文本，并驱动界面更新。

缺少任意一个环节，都会导致乱码、更新不连续或无法实时显示。

第二章：Buffer——二进制数据的“翻译缓冲区”

2.1 为什么需要 Buffer

浏览器与服务器之间的数据传输本质上是字节流。无论返回的是 JSON、纯文本还是图片，底层都会先以二进制形式到达客户端。JavaScript 默认使用字符串处理文本，但在流式场景下，数据是分块到达的，每一块都可能不完整。例如一个中文字符通常由多个字节组成，如果某个分块恰好把一个字符的字节切开了，直接按字符串解码就会出现乱码。

Buffer 的作用就是暂存这些二进制数据，等待足够多的字节到达后再统一解码。可以把它理解为一个“翻译缓冲区”：先把不完整的字节碎片收集起来，确认能组成合法字符后再交给上层逻辑。

2.2 浏览器中的 Buffer 实现

在浏览器环境中，处理二进制数据主要依靠 ArrayBuffer、Uint8Array 和 TextDecoder。其中：

• ArrayBuffer 表示一段连续的内存区域，用于存放原始字节；
• Uint8Array 是 ArrayBuffer 的视图，方便按字节读写；
• TextDecoder 负责将字节序列解码为字符串，并支持处理跨分片的多字节字符。

示例代码如下：

// 假设收到两个分片，分别包含不完整的中文字符字节
const chunk1 = new Uint8Array([0xe4, 0xbd]); // “你”的前两个字节
const chunk2 = new Uint8Array([0xa0]);       // “你”的最后一个字节
const decoder = new TextDecoder('utf-8');
const text1 = decoder.decode(chunk1, { stream: true });
const text2 = decoder.decode(chunk2, { stream: false });
console.log(text1);   // 可能为空，因为前两个字节尚未构成完整字符
console.log(text2);   // 输出“你”

decode 方法的 stream 参数非常关键。当值为 true 时，会告知解码器“后续仍有数据”，因此对不完整字节不会强行输出，而是暂时缓存。当最后一块数据用 stream: false 解码时，残留字节会被处理完毕。

第三章：从零实现流式读取逻辑

3.1 使用 Fetch API 读取流

现代浏览器支持通过 fetch 获取响应体后，使用 response.body.getReader() 逐块读取数据。reader.read() 返回 Promise，每次 resolve 一个包含 value 与 done 的对象。

async function readStream(response, onText) {
  const reader = response.body.getReader();
  const decoder = new TextDecoder('utf-8');
  let buffer = '';
  while (true) {
    const { value, done } = await reader.read();
    if (done) break;
    // 当前分片解码后追加到已有文本
    const text = decoder.decode(value, { stream: true });
    buffer += text;
    // 将最新累积结果交给界面渲染
    onText(buffer);
  }
  // 处理最后残留字节
  const tail = decoder.decode();
  if (tail) {
    buffer += tail;
    onText(buffer);
  }
}

该实现将每次读取到的二进制区块解码为字符串，再累加到 buffer 中。onText 回调用于通知界面更新，从而形成逐段渲染的效果。

3.2 处理分片边界问题

如果不使用 TextDecoder 的流式模式，而直接对每个 Uint8Array 调用 decode，多字节字符可能被错误拆分。例如某些中文字符占三个字节，当一个分片只包含前两个字节时，单独解码会得到替换字符或乱码。

使用 stream: true 后，解码器会保留不完整的字节序列，并在后续分片补齐时自动拼接，因此能有效避免乱码。这也是流式文本处理中最容易踩坑却最值得重视的一点。

3.3 与服务端配合

流式读取要求服务端返回的响应头中声明合适的传输模式。常见做法是使用分块传输编码，让服务端可以多次写入响应体而不关闭连接。客户端无需关心具体传输细节，只需要确保服务端不会在一次响应中等待全部内容生成完毕。

如果服务端返回的是纯文本，且每次写入的内容本身就是合法文本片段，客户端处理会更简单。但如果服务端返回 JSON 结构或自定义协议，则需要在客户端解析后再提取文本。本文以纯文本流为例展开，便于聚焦核心技术。

第四章：用 Vue 3 + Vite 搭建流式聊天界面

4.1 项目初始化

使用 Vite 创建 Vue 3 项目后，可获得即开即用的开发环境。聊天界面通常包括消息列表、输入框和发送按钮。组件状态至少需要维护：

• 消息数组：记录用户与 AI 的每条消息；
• 当前 AI 回复：流式输出过程中持续更新的字符串；
• 加载状态：标识是否正在生成。

4.2 核心组件实现

以下是一个简化版聊天组件的结构：

<template>
  <div class="chat">
    <div v-for="msg in messages" :key="msg.id" class="message">
      {{ msg.role }}: {{ msg.content }}
    </div>
    <div v-if="isStreaming" class="message ai">
      AI: {{ streamingText }}
    </div>
    <input v-model="inputText" placeholder="输入问题" />
    <button @click="send" :disabled="isStreaming">发送</button>
  </div>
</template>
<script setup>
import { ref } from 'vue';
const messages = ref([]);
const streamingText = ref('');
const isStreaming = ref(false);
const inputText = ref('');
async function send() {
  if (!inputText.value.trim() || isStreaming.value) return;
  messages.value.push({ id: Date.now(), role: 'user', content: inputText.value });
  inputText.value = '';
  streamingText.value = '';
  isStreaming.value = true;
  try {
    const response = await fetch('/api/chat', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ message: '输入内容' })
    });
    await readStream(response, (text) => {
      streamingText.value = text;
    });
    // 流式结束后，将累积文本作为完整 AI 消息保存
    messages.value.push({ id: Date.now(), role: 'ai', content: streamingText.value });
  } finally {
    isStreaming.value = false;
    streamingText.value = '';
  }
}
</script>

4.3 渲染性能与更新策略

流式输出可能触发高频状态更新。对于较短的回复，直接更新 streamingText 没有问题；但如果回复很长，每到达一个分片就整体重绘会带来额外开销。常见优化包括：

• 节流更新：限制每秒最多更新若干次界面；
• 局部渲染：只更新当前正在生成的 AI 消息，而非整个消息列表；
• 虚拟滚动：当消息数量很多时，仅渲染可见区域。

对大多数对话式应用来说，先保证正确性，再根据实际性能表现决定是否引入上述优化即可。

第五章：工程化扩展与边界处理

5.1 错误恢复与中断

流式输出过程中如果连接中断，前端应能识别并给出友好提示。reader.read() 抛出的异常需要捕获，同时可以将已生成的部分文本保存，让用户至少看到部分结果。

用户主动停止生成也是常见需求。可以使用 AbortController 取消请求：

const controller = new AbortController();
const response = await fetch('/api/chat', {
  signal: controller.signal
});
// 用户点击停止
controller.abort();

取消后需要妥善处理 reader 阻塞状态，避免后续读取卡住。

5.2 协议与格式约定

如果服务端返回的不是纯文本，而是结构化数据，例如每行一个 JSON 对象，客户端需要先按行拆分，再解析字段。此时 Buffer 累积逻辑可以保持不变，只是在上层增加一层协议解析。

例如约定返回格式为：

{"type":"text","content":"你"}
{"type":"text","content":"好"}
{"type":"done"}

客户端可以逐行解析 JSON，提取 content 字段并追加到界面。采用行分隔的 JSON 流，既能保持可读性，也便于扩展类型，如后续加入状态信息或引用来源。

5.3 安全与体验细节

流式输出涉及实时数据渲染，需要注意：

• 对输出内容的转义，避免直接插入 HTML 导致风险；
• 对请求频率与并发数的合理限制；
• 在接口异常时保留用户已输入内容，避免丢失。

这些细节虽然不直接决定流式能力是否可用，但直接影响产品稳定性和用户信任。

结语

流式输出并不是高不可攀的技术，它的核心在于理解浏览器如何接收二进制数据块，如何利用解码器处理分片边界，以及如何驱动前端状态持续更新。通过原生 Fetch 流读取配合 TextDecoder，可以获得轻量且可控的实现基础；结合 Vue 3 与 Vite，则可快速搭建一个具备工程化结构的聊天界面。

当开发者掌握了从字节到字符、从分片到渲染的完整链路后，无论是接入大模型服务，还是构建对话式业务功能，都将具备更强的自主实现与问题排查能力。