AI 对话流式输出怎么做停止按钮：AbortController、状态播报和断线收尾

AI 对话页面的「停止生成」按钮看起来只是个不起眼的小控件，实际落地最容易出问题的反而是收尾环节：用户点完按钮文字还在不停追加、按钮状态恢复得太早、键盘焦点莫名跳转、读屏用户收到一堆碎片化提示。把浏览器请求、中断信号和界面状态串成一条完整链路处理，停止动作的表现才会足够可靠。

先把用户操作对应的逻辑拆解开

用户点击发送之后，预期的交互路径是输入框自动进入忙碌状态、回复内容逐段流式输出、停止按钮立刻变成可点击状态。点击停止按钮之后，至少要同步完成三件事：不再读取后续的流分片、界面给出「已停止」的明确反馈、所有交互控件回到可以继续输入的正常状态。

很多已上线的页面只实现了第一件事。网络层面的读取确实被中断了，但之前触发的异步回调还在偷偷修改DOM，或是新一轮提问已经发起，旧请求残留的 finally 反而把刚置灰的新请求按钮提前恢复成可用状态。这里不用急着堆大量条件判断，只要给每轮独立请求绑定一个专属的状态持有者就能解决这类冲突。

为每轮生成保存独立的控制器

AbortController 通过它的 signal 直接对接 fetch。触发停止操作时主动调用 abort()，未完成的fetch请求、响应体读取或是流读取逻辑都会同步收到中止信号。一个signal一旦进入中止状态就不能再复用于下一轮请求，所以用户重新发送提问的时候必须新建全新的控制器实例。

let activeController = null;

async function sendPrompt(prompt) {
  const controller = new AbortController();
  activeController = controller;
  setUiState({ generating: true, status: "正在生成回复" });

  try {
    const response = await fetch("/api/chat/stream", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ prompt }),
      signal: controller.signal,
    });
    await readReplyStream(response.body, controller.signal);
    setUiState({ status: "回复已完成" });
  } catch (err) {
    if (err.name === "AbortError") {
      setUiState({ status: "已停止生成" });
    } else {
      setUiState({ status: "连接出现问题，请重试" });
    }
  } finally {
    if (activeController === controller) activeController = null;
    setUiState({ generating: false });
  }
}

function stopReply() {
  activeController?.abort("user stopped reply");
}

这段代码的核心逻辑不在可选链的写法，而在 activeController === controller 的判断机制。它能彻底阻止旧请求在晚到的 finally 回调里错误重置新请求的状态。手工测试的时候可以快速连续发两次提问，之后直接停止第二条请求，如果输入框和按钮的状态始终跟着第二轮操作正常变化，说明状态持有者的边界已经划分清楚。

读取分片时先确认停止边界

中止操作不只发生在 fetch 还没返回的阶段。就算响应头已经返回、代码正在逐段读取流内容的过程中触发停止，也会直接导致后续读取逻辑抛出异常。所以流读取函数要把signal作为入参传入，每次更新DOM之前先判断当前的signal有没有被标记成中止状态。

async function readReplyStream(body, signal) {
  const reader = body?.getReader();
  if (!reader) throw new Error("response body is unavailable");

  const decoder = new TextDecoder();
  while (true) {
    const { done, value } = await reader.read();
    if (done || signal.aborted) break;

    const chunk = decoder.decode(value, { stream: true });
    appendReplyText(chunk);
  }
}

这个前端中止逻辑不能替代后端的任务取消操作。浏览器侧停止读取之后，后端是否还会继续生成内容，完全取决于接口协议和服务端的连接处理逻辑。对成本敏感的场景，可以把同一轮请求的唯一ID传给后端，由后端检测到取消信号之后主动停止对应的生成任务，前端的停止按钮只需要保证把用户的中断意图及时传递出去即可。

让视觉状态和辅助技术状态完全同步

流式输出每出现几个字就触发一次读屏播报，会大幅拉高读屏用户的使用噪音。更合理的方案是：生成开始、主动停止、生成完成、生成失败这几个关键节点才推送独立的状态提示，正文内容的逐段追加保持普通DOM更新即可。role="status" 或是 aria-live="polite" 用来承载这类非紧急状态提示，而且这类逻辑绝对不能强行抢夺用户的焦点。

停止生成

生成流程启动的时候可以把 aria-busy 设为 true，触发停止或是生成完全结束之后再恢复成 false；专门的状态区域只更新完整短句，比如「正在生成回复」或是「已停止生成」。停止按钮本身要保留原生的键盘可达性，触发停止操作之后焦点应该留在停止按钮或是输入区域，不要用脚本强制把焦点跳到刚生成好的回复末尾打断用户操作路径。

把边界状态当成常规流程验证

这些边界场景的验证，比单纯能跑通流式展示更接近真实使用体验的质量要求。尤其是弱网环境和用户快速连续操作的场景，最容易暴露旧请求抢状态的隐性问题。先把停止流程打磨稳定，再去叠加打字机动画、代码高亮、复杂消息卡片这类增强特性，整体开发效率会高很多。

相关问题

停止按钮能保证服务端立刻停止生成任务吗？

不能保证。它优先停止的是浏览器侧的请求和流读取逻辑，服务端是否会终止对应的生成任务，需要后端依据连接断开事件、取消信号或是专属请求ID单独做处理。

为什么不能直接复用同一个AbortController实例？

已经触发过中止的signal会永久保持中止状态，后续所有复用这个signal的新请求都会直接抛出异常。每轮新的生成请求都必须新建独立的控制器实例。

把所有提示都放进aria-live区域可以吗？

不建议。逐段追加的正文内容会触发大量重复播报，严重干扰读屏用户体验。只需要把短状态提示放到实时播报区域，正文保持普通的内容更新逻辑就足够易用。

超时和用户主动停止要展示一样的文案吗？

最好做区分。用户主动停止可以直接提示「已停止生成」，超时或是网络异常的场景，要给出明确的重试说明，避免用户搞不清当前流程出了什么问题。

停止动作的核心价值是符合用户预期

AI对话的流式体验好坏从来不是靠光标动效这类花哨特性决定的。用户点击停止的瞬间，流读取循环、交互控件状态、键盘焦点、辅助技术提示全部同步按规则收尾，页面用起来才会足够顺手。先把这条完整链路做稳，之后再扩展多轮对话、复杂工作流功能，整体维护成本会低很多。