标准答案
- 一次性返回的状态简单，服务端可以在完整结果通过校验后返回，适合短文本、结构化抽取和需要原子结果的接口；缺点是用户要等待完整生成。
- 流式输出把结果拆成事件发送，用户更早看到内容，适合聊天、长文和工具过程展示。服务端必须发送明确的开始、增量、工具事件、错误和结束事件，并在结束事件中提供 usage 或请求 ID。
- 流式输出不能把已发送的内容撤回。敏感内容过滤、Markdown 结构校验和最终结果持久化要设计在事件流之前或允许部分展示的边界内；客户端断开时还要取消或回收下游任务。
题目解析
首字延迟、每个分片间隔、总耗时和完整性是不同指标。流式只是改善感知延迟，模型仍可能在后半段耗时很久，不能用首字很快推断系统整体性能好。
SSE 适合服务端单向推送且浏览器支持方便；WebSocket 适合双向事件和长连接协作；普通 HTTP 分块响应则依赖客户端和代理正确转发。选择要结合取消、代理超时、负载均衡和移动网络。
审计不能只保存最终文本。至少应保存事件序列的摘要、Prompt 版本、模型、工具调用和最终 usage；原文是否保存还要遵循隐私与保留策略。
客户端重连要避免重复展示。可以使用事件 ID、会话版本或服务端持久化的增量序号，让客户端从上次确认位置恢复。
常见误区
- 认为流式一定更省钱或更快完成。它主要改善首字体验，Token 成本通常仍由总输入输出决定。
- 只监听文本增量，不处理结束和错误事件。结果会出现加载状态不结束、半截回答被当成成功等问题。
- 把每个分片直接持久化为一条消息。应按会话事件或版本聚合，避免产生大量难以查询的碎片记录。