流式 AI 回复如何拼接完整答案：delta、done 与断线续传

聊天窗口出现“回答到一半就停了”，不一定是模型没有生成完。流式接口把答案拆成多条事件，前端如果把每条 delta 当成独立消息，或者在遇到空行时误清空缓冲区，就会留下半句话。稳定的做法是保留文本缓冲区，用 done 标记收尾，再把断线恢复当成独立状态处理。

先拼接有效的 delta，再确认 done；没有收到完成标记时，不要把当前屏幕内容当成最终答案。

半截回答暴露了哪一层的问题

先看浏览器表现：文字持续出现时一切正常，网络短暂抖动后页面停在“请将订单……”这样的半句。此时不要先调大超时时间，先确认最后收到的是内容事件、完成事件，还是连接本身已经关闭。

流式协议通常以文本事件承载增量字段。事件里可能有 delta，也可能只带 done；空行只是事件边界，不代表答案为空。把这三种情况混成一个分支，正是最常见的半截问题来源。

用一个缓冲区接住连续 delta

下面的解析函数只关心三件事：读取事件文本、解析可用的增量字段、在确认结束后返回完整文本。示例没有绑定某一家模型接口，实际项目只需要把字段映射到自己的事件格式。

async function readAnswer(response, onText) {
  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  let pending = '';
  let textBuffer = '';
  let finished = false;

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

    const frames = pending.split('\n\n');
    pending = frames.pop() || '';
    for (const frame of frames) {
      const line = frame.split('\n').find(item => item.startsWith('data:'));
      if (!line) continue;
      const event = JSON.parse(line.slice(5).trim());
      if (typeof event.delta === 'string' && event.delta.length > 0) {
        textBuffer += event.delta;
        onText(textBuffer);
      }
      if (event.done === true) finished = true;
    }
  }

  return { text: textBuffer, finished };
}

这里的 pending 用来保存跨网络分片的半个事件，textBuffer 才是给界面展示的完整累积文本。reader.read() 返回结束并不等于业务上的 done；服务端异常关闭时，返回值里的 finished 应保持为 false，让上层决定是否恢复或提示失败。

为什么不能看到一段文字就覆盖旧值

增量字段描述的是“新增了什么”，不是“当前完整答案是什么”。如果第二个事件是“库存”，直接赋值会把第一段“请将订单”抹掉。追加后再回调界面，才能保证渲染层只接收从头到当前点的文本。

done、断线和取消必须分开收口

正常结束、用户主动停止、网络断开是三个不同结果。正常结束拥有 done=true；主动停止可以由页面设置取消信号；网络断开则缺少完成标记。只要把“读取循环结束”一律当成功，监控和重试都会被误导。

断线续传的边界：先问服务端有没有游标

浏览器重新发起请求并不天然等于续传。只有服务端为每个事件提供稳定的 lastEventId，并且接受 resumeCursor，客户端才有机会从上次确认位置继续。否则重试得到的可能是一份全新答案，强行拼接会产生重复段落。

恢复流程应记录“最后一个已经追加并确认的事件”，而不是记录屏幕上最后几个字符。服务端若返回同一个游标，客户端可以丢弃重复事件；没有游标协议时，宁可把旧文本作为草稿并重新请求，也不要假装完成无缝续接。

取消请求时保留什么

取消只改变连接状态，不应删除用户已经看到的内容。可以把当前 textBuffer 存在会话草稿里，等用户点击“继续生成”时重新走明确的恢复或重试策略。

上线前的复查清单

• 网络分片把一个事件拆成两段时，pending 是否会保留未完成文本。
• 空 delta、缺少 data 和非法 JSON 是否有清晰的错误分支。
• 读取结束但没有 done 时，页面是否显示中断而不是成功。
• 恢复接口是否明确规定游标的生成、确认与重复事件处理。
• 用户取消后，已生成内容是否仍能复制、重试或保存。

相关问题

delta 为空时要不要刷新界面

通常不需要。空增量不改变答案，刷新只会增加渲染次数；可以记录事件数量，但不要把它当成完成信号。

ReadableStream 结束就代表回答成功吗

不代表。只有业务事件明确给出 done=true，或服务端定义了等价的正常结束标记，才可以把答案标记为完成。

没有 lastEventId 能不能自己截取文本续传

不建议。字符截取无法证明服务端从哪个生成状态继续，重试结果可能重复或语义改变，应按草稿重试处理。

把半截答案当成一种状态

流式输出的关键不是让文字更快出现在屏幕上，而是让每一段文字都有可解释的归属。pending 解决网络分片，textBuffer 负责累计内容，done 确认正常收尾，游标则决定断线后能不能真正接着原答案走。四个边界分开，前端才不会把“暂时没收到下一段”误报成“模型已经回答完”。