Next.js AI 流式响应治理：取消、背压与连接清理

AI 聊天界面最容易制造一种可靠性错觉：文字正在逐个出现，所以系统看起来“一切正常”。实际上，用户可能已经点击停止、切换会话或关闭标签页，而模型上游仍在计费；服务端仍保存连接和缓冲区；React 仍按每个 token 触发一次渲染。流式传输的生产目标不是“能流”，而是让消费速度、取消意图和资源生命周期贯穿浏览器、Next.js Route Handler、模型客户端三层。

把取消定义成一条端到端协议

客户端应为每次生成创建独立的 AbortController，并把它与 runId 绑定，而不是放在所有会话共享的全局变量里。用户点击停止、发起新生成、离开当前会话或组件卸载时，都先中止对应请求。界面随即进入 canceling，收到流结束或服务端确认后再进入 canceled。如果点击按钮后只停止读取响应，却没有中止 fetch，浏览器不再显示新文本并不代表服务端停止工作。

Route Handler 需要监听 request.signal，并把中止继续传给模型 SDK、检索请求和工具调用。上游库若提供 signal 参数就直接使用；若只返回异步迭代器，则在流的 cancel(reason) 中调用其取消或 return() 方法。清理动作要幂等，因为客户端断开、超时器触发和业务停止按钮可能几乎同时到达。

一个可靠实现至少持有三类标识：面向 UI 的 runId、服务端追踪用的 traceId、上游供应商的请求 ID。取消日志应同时记录这些标识和原因，例如 user_stop、navigation、deadline、superseded，但不要把正常的用户停止计入服务错误率。

背压不是“给循环加一个 sleep”

ReadableStream 有内部队列和期望容量，但只有生产者按需拉取时，背压才会向上游传播。若代码先在后台高速读取整个模型流，再不断 enqueue，即使浏览器消费很慢，内存仍会增长。更稳妥的结构是在底层源的 pull(controller) 中只读取异步迭代器的下一块：消费者需要数据时才继续拉取；cancel 则中止上游并释放迭代器。

还要分清三种速度：模型产生 token 的速度、网络发送块的速度、React 提交视图的速度。浏览器网络流可以逐块读取，但 UI 没必要逐 token setState。客户端可把到达的文本先放入普通缓冲，每 30 到 80 毫秒或每累计一定字符提交一次；标点或段落结束时立即刷新。这样既保留“正在生成”的反馈，也避免长回答造成数千次协调和布局。

服务端不应把无限文本积在一个字符串中再返回。对事件协议设置单条事件上限和累计输出上限；超过上限时发送明确的 truncated 结束事件，而不是突然断开。若使用 SSE 或自定义数据帧，每个事件必须可完整解析，不能依赖一次网络 chunk 恰好对应一个 JSON 对象。关于传输协议差异可结合 LLM 流式输出协议 与 SSE 和 WebSocket 对比 一起评估。

状态机必须能区分停止与故障

最小状态集可以是 idle -> connecting -> streaming -> completed，并从活动状态分支到 canceling、canceled 或 failed。只有当前 runId 的事件可以修改当前回答；旧请求即使晚到一块数据，也必须被丢弃。这个约束能解决“快速点两次发送后，前一个回答写进新消息”的竞态。

停止后保留已经展示的文本通常比清空更友好，但要标注“已停止”，且不要把它当成完整答案参与后续上下文。重新生成应创建新消息版本，保留旧版本供比较，而不是在原文本末尾继续拼接。更完整的界面结构可参考 LLM 流式前端实现 和 RAG 流式 UI。

错误处理也要按阶段分类。建立连接前的 401、429 可以直接显示结构化错误；开始输出后的失败不能再改变 HTTP 状态码，应通过流内 error 事件表达，并携带可公开的错误码。供应商原始报错、提示词和密钥信息只能进入受控日志，不能原样写进客户端事件。

用断开实验验证资源真的释放

上线前不要只测完整生成。自动化测试应覆盖：首字节前取消、输出中取消、路由切换、慢速读取器、浏览器突然断网、上游超时、连续快速重试。每种情况都检查模型请求是否结束、活动连接计数是否回落、异步迭代器是否关闭、超时器与监听器是否移除。

生产指标至少包括首字节延迟、块间停顿、完成率、用户取消率、取消传播耗时、取消后仍产生的 token、单连接峰值缓冲和活动流数量。若“取消后 token”持续偏高，说明 UI 按钮虽然有效，成本链路却没有真正停止。只有这些证据闭环，流式体验才从动画效果变成可运营的传输系统。