流式响应
Streaming Response
中级通用流式响应（Streaming Response）是服务端在一次请求中分批发送结果、客户端边收到边展示的方式。它解决了长时间生成内容时只能盯着空白页面等待的问题，例如让 AI 助手逐步显示回答，而不是写完后一次出现。
你可能会说：「我想让 AI 回答边生成边显示，别让用户一直等到整段写完才看到内容。」
读之前建议先了解
动手看看AI 助手逐字回答问题
1
用户在浏览器里提问，浏览器只发起一次请求。回答区暂时空着，等服务端生成内容。
要点流式响应是怎么让内容逐步出现的？
- 1
一次请求可以分批收到内容
你发起请求后，服务端不等完整结果生成，就陆续发送数据；前端每收到一部分，就更新界面。这里的关键是同一次请求的结果逐步到达，不是前端反复发起新请求。
- 2
先看到内容不等于更快完成
流式响应能缩短用户看到第一段内容的等待，但完整回答未必更快生成。做 AI 聊天界面时，你可以让文字逐步出现，同时保留“仍在生成”的状态。
- 3
中途失败要保留状态判断
因为内容可能只收到一半，连接中断时，前端不能把这段文字当作完整答案。我们通常会区分生成中、已完成和失败，让用户知道现有内容是否还能继续使用。
容易混淆的地方
流式响应说的是结果如何逐步送达，不等于模型一定按字或按词输出：服务端可能把内容合成较大的片段再发送。它也不等于 WebSocket；流式响应可以用于一次请求的持续输出，而 WebSocket 更适合双方持续互发消息。只显示旋转加载图标，也不算流式响应，因为用户还没收到结果内容。
什么时候用
适合用
- 做 AI 聊天工具时，回答需要几秒甚至更久才写完，让用户先读到已生成的部分。
- 后台生成较长报告时，希望页面逐步展示正文，并让用户看出任务仍在进行。
- 开发者工具执行耗时任务时，希望逐条展示服务端返回的日志或处理结果。
不适合用
- 接口只返回一个很小的开关状态时，直接返回完整结果更简单，分批发送没有价值。
- 用户要下载一份生成完才能使用的文件时，先展示任务进度，完成后再提供下载。
- 页面要持续接收多人操作并向服务端发送消息时，考虑 WebSocket，而不是把一次请求的流式响应当作双向通道。
练一练选一个答案，看看解释
你在做 AI 报告页，生成全文要十几秒。用户希望先读已完成的段落，也要知道报告是否完整。你会怎么设计？
让 AI 帮你做复制给 AI Agent 直接用
请把这个 AI 报告接口改为流式响应：服务端生成内容后分批发送，前端边接收边展示。界面区分生成中、已完成和中途失败；中断时保留已收到的文字，但明确标记它不是完整报告。