AI 流式回答收尾不完整怎么处理：增量缓冲、结束事件与可恢复状态

AI 对话页面最容易被忽略的故障，不是请求完全失败，而是文字已经显示了大半，连接却在最后一个片段附近断掉。用户看到的是一段像“完成了”又没有收尾的回答，重试后还可能出现两份内容拼在一起。处理这类问题，关键是把“收到文本”“收到结束事件”和“已经可以恢复”当成三个不同状态。

增量片段只负责追加到缓冲区，只有明确的结束事件才把回答标记为完成；连接中断时保留可识别的缓冲内容，恢复操作从上次游标继续，而不是把旧文本再拼一次。

先区分三种收尾结果

假设服务端把回答拆成若干事件：文本事件携带一小段增量，结束事件携带最终状态，异常事件说明连接不能继续。前端如果只监听文本，就会在最后一个增量到达后立刻显示“已完成”，这正是半截回答最常见的来源。

ReadableStream 只追加片段，不负责宣布完成

浏览器读取流时，reader.read() 返回的是当前可用的一段字节。文本可能被拆在任意位置，甚至一个多字节字符也可能跨越两次读取，所以要用同一个 TextDecoder 维护解码状态，再把事件交给解析器。

async function readAnswer(response, onUpdate) {
  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  let buffer = '';
  let state = 'receiving';

  try {
    while (true) {
      const { value, done } = await reader.read();
      if (done) break;
      buffer += decoder.decode(value, { stream: true });

      const lines = buffer.split('\n');
      buffer = lines.pop() ?? '';
      for (const line of lines) {
        if (!line.startsWith('data:')) continue;
        const event = JSON.parse(line.slice(5));
        if (event.type === 'text') {
          onUpdate({ type: 'text', text: event.text });
        }
        if (event.type === 'done') {
          state = 'completed';
          onUpdate({ type: 'done' });
        }
      }
    }
    if (state !== 'completed') state = 'recoverable';
  } catch (error) {
    state = 'recoverable';
    onUpdate({ type: 'recoverable', error });
  }
  return state;
}

这段代码有两个刻意的边界。第一，末尾没有换行的残余内容仍留在 buffer 中，不能直接当作完整事件解析；第二，流结束但没有收到 done 时，返回的是 recoverable，而不是 completed。页面可以展示已经收到的文字，但按钮应写成“继续获取”，不能写“已完成”。

用 AbortController 把主动停止和断线恢复分开

用户点击停止时，前端知道这是主动行为，可以把状态落为 stopped；网络异常则应保留回答缓冲并落为 recoverable。如果两个分支都只设置一个布尔值，下一次点击恢复时就无法判断该从哪里继续。

const controller = new AbortController();
let answer = { text: '', cursor: 0, state: 'receiving' };

function stopAnswer() {
  controller.abort();
  answer.state = 'stopped';
  render(answer);
}

function appendText(text, cursor) {
  if (cursor 

cursor 是去重的关键，resumeAnswer 只在可恢复状态下使用它。服务端恢复接口收到 after 后，只返回这个位置之后的事件；前端的 appendText 仍然做一次保护，遇到旧游标直接丢弃。这样即使网络重试把上一段事件送来两次，也不会让回答重复。

恢复动作要经过一次轻量验收

恢复按钮不要只重新发起同一个请求。点击后至少检查三件事：当前回答确实处于 recoverable，保存的 cursor 不是空值，服务端返回的新事件编号大于本地游标。任何一项不满足，都先显示“请重新开始”，避免把不完整上下文伪装成续写。

• 恢复成功：新片段接在原缓冲后面，收到 done 后才显示完成。
• 再次断开：保留最新游标，按钮仍然是“继续获取”，不要清空已显示内容。
• 用户主动停止：状态保持 stopped，新请求由用户明确点击“重新生成”触发。

常见问题

为什么 response.body 读完了还不能算成功？

流读完只说明连接结束，不代表业务事件完整。没有 done 或等价的最终事件时，仍可能缺少收尾信息，应保留为可恢复状态。

TextDecoder 为什么要复用同一个实例？

字符可能跨越两个字节片段。复用实例并在最后一次读取时正确处理残余字节，才能避免中文或表情被拆成乱码。

主动停止后还能直接点继续获取吗？

不建议。主动停止和网络断线的语义不同；前者没有待处理的失败，通常应由用户重新生成，后者才适合按游标恢复。

把“收尾”当作协议的一部分

流式回答的稳定性不靠某个按钮补救，而靠协议和页面状态对齐：文本事件负责增量、结束事件负责完成、游标负责去重、AbortController 负责主动取消。联调时分别覆盖正常结束、末尾无换行、主动停止、网络断开后恢复和重复事件五组场景，半截回答就能从偶发体验问题变成可检查的状态分支。