流式输出不逐字显示？检查 SSE、缓冲和事件解析

先分清两个时间#

首个有效输出时间反映用户什么时候开始看到内容；总完成时间反映整次请求多久结束。有的模型先进行内部推理，开始输出较晚；这和代理把已生成内容攒住再发不是同一个问题。

不要只看平均总耗时。比较相同任务时，记录首次有效输出、完成时间、输出数量和失败比例，才有可比性。

检查协议与解析方式#

1. 请求体确认使用了目标接口支持的 stream: true。
2. 读取响应的 Content-Type 和实际事件；不要对整个 SSE 响应直接执行 response.json()。
3. 使用对应协议的事件解析器。Chat、Responses 和 Messages 的事件类型不能混用。
4. 网络数据块不等于事件边界，也不等于一个字或一个完整 Token。解析器需要缓冲未完成的行与事件。

用 curl 排查时可加 -N 关闭本地输出缓冲，并保持其他参数与原请求一致。Bash 例子：

1
curl -N --fail-with-body 'https://hikariapi.xyz/v1/chat/completions' \
2
  -H "Authorization: Bearer $API_KEY" \
3
  -H 'Content-Type: application/json' \
4
  -d "{\"model\":\"$MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"用三句话说明什么是 API\"}],\"stream\":true}"

先在本机设置本站 Key 和支持该协议的精确模型 ID。该例子用于连通性检查，不保证所有模型产生相同分块节奏。

curl 正常而网页集中出现#

检查自建反代是否开启响应缓冲、应用是否先读完整个响应才返回，以及前端是否只在结束事件后更新状态。把流先转成完整字符串，再展示给页面，自然不会逐段显示。

如果只在某个网络环境发生，继续比较代理、VPN、网关和远程开发环境。不要直接调整主站配置，先定位自己能控制的那一层。

流中断怎么办#

记录最后收到的事件和错误，并核对主站用量。已经生成一部分内容的请求，不能把中断简单当作“完全没有执行”。涉及工具动作的应用还需要按业务 ID 防止重复执行。

参考：HiKaRi 文字 API 的流式说明。后续阅读：重试与幂等。