服务器发送事件：流式响应如何一步步到达屏幕

从一次请求认识持续返回的响应

1. 先建立一个简单的心智模型：客户端发出请求，服务器不必等完整答案生成后才返回，而是可以在同一个响应中持续发送事件。服务器发送事件通常简称 SSE，它提供的是服务器向客户端传递事件的方式。模型接口可以借此逐段返回生成结果，客户端再把这些片段呈现出来。它不是每出现一个字就重新请求一次，也不意味着每个事件都恰好对应一个字。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events?utm_source=openai))

在请求中明确开启流式返回

2. 从一个最小请求开始，只发送简短问题，并按接口要求设置 stream 为 true。以 OpenAI 的响应接口为例，这会启用基于 SSE 的流式返回。初次调试时，建议先打印收到的事件类型与内容，不急着连接复杂界面。这样可以先确认请求确实进入流式路径，再处理展示逻辑。这里的参数控制的是响应交付方式，不是要求模型把答案写得更短。([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses?utm_source=openai))

确认响应承载的是事件流

3. 接下来检查响应类型。SSE 使用 text/event-stream，而不是把整个响应当作一个普通 JSON 文档交付。事件可以包含 event、data、id 等字段，其中 data 承载事件数据，event 可以标识事件名称。实际模型接口可能把 JSON 放进 data 字段，因此应先识别完整事件，再按接口约定解析其中的数据，而不是直接对整个持续返回的响应执行一次 JSON 解析。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events?utm_source=openai))

等待完整事件再解析数据

4. 理解解析边界是最重要的一步。SSE 用空行分隔事件，但底层读取到的数据块不一定与事件对齐。一次读取可能只拿到半条事件，也可能同时拿到多条。手动处理时，应保留尚未完成的文本，找到完整事件后再解析，并把剩余部分留给下一轮。事件流采用 UTF-8 编码，因此解码也要保留跨数据块的状态。已有可靠解析器或软件开发工具包时，优先使用它们，不要把每次读取都当成完整消息。([html.spec.whatwg.org](https://html.spec.whatwg.org/dev/server-sent-events.html?utm_source=openai))

只把文本增量追加到回答区域

5. 事件解析成功后，还要判断它代表什么。以 OpenAI 的响应接口为例，response.output_text.delta 事件携带文本增量，可以追加到当前回答。其他事件可能表示创建响应、工具调用或生命周期变化，不能一律当作正文显示。建议把“事件处理”和“界面更新”分开：前者根据类型分发，后者只接收已经确认的可展示文本。这样既能保留完整事件记录，也便于定位正文缺失或重复的问题。([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses?utm_source=openai))

区分正常结束与意外断线

6. 不要把连接关闭直接等同于回答成功。应根据所用接口定义的完成、失败或未完成事件记录最终状态，并在异常中断时保留已收到的内容。不同接口的结束约定可能不同，不能假设所有流都使用同一种结束标记。浏览器原生 EventSource 虽有重连机制，但模型请求是否能续传，仍取决于服务端协议；重新发送一次生成请求，不应被默认视为无缝恢复。([developers.openai.com](https://developers.openai.com/api/reference/resources/responses/streaming-events?utm_source=openai))

通过统一接入验证完整流式链路

7. 最后，把同一个简短问题贯穿整个测试，依次确认请求开启流式、事件解析正确、正文持续追加、结束状态明确。需要尝试多个模型家族时，可以考虑按量付费的 Relay365 中转服务，减少反复配置不同接入入口的操作。例如，可以选择 Gemini 2.5 Flash 作为练习对象；实际事件结构仍应以所用接口的返回为准，而不是根据模型名称猜测。

如果统一接入适合你的工作流，可以创建一个 Relay365 账户，从一次小规模请求开始验证。排查时，始终沿着“请求参数、事件边界、事件类型、完成状态”这条顺序前进：先确认数据怎样到达，再决定界面怎样展示。