后端已分段发送 SSE，但前端一次性收到全部内容，如何排查？

先区分“数据到客户端晚了”与“客户端早已收到、界面却晚更新”。沿服务端生成、应用写出、代理转发、浏览器读取和界面渲染记录同一事件的序号与时间，逐层缩小范围。服务端日志显示多次写入，只能证明程序执行了写操作，不能证明字节已经送到浏览器。

最常见的问题包括应用或压缩缓冲、反向代理响应缓冲，以及前端使用 response.text() 等待整个响应完成。也要检查每条 SSE 事件是否以空行结束，否则解析器会一直等事件边界。

直连应用：使用 curl -N 观察带序号和时间戳的独立事件。若直连也成批到达，检查生成器是否真的逐步产出、框架是否支持流式写出、阻塞任务是否占住事件循环，以及压缩或中间件是否攒批。
经过代理再比较：若直连正常、域名访问成批到达，逐个排查 NGINX、网关、负载均衡和 CDN。NGINX 的 proxy_buffering off 控制上游响应缓冲；proxy_request_buffering 控制请求体，不能代替它。
观察浏览器读取：用 response.body.getReader() 或合格的事件流客户端逐批读取；若调用 response.json()、response.text() 或等全部字符串后再解析，界面只能在结束后看到结果。
最后检查渲染：记录每次读取与状态更新的时间。一次同步任务堵住主线程、频繁更新造成批处理，或只在终态提交状态，都可能造成“假流式”。

响应头 X-Accel-Buffering: no 可以请求 NGINX 关闭该响应的缓冲，但代理配置可能忽略它；不能认为加一个头就控制了所有中间层。压缩策略、空闲超时和心跳也要分别检查。HTTP/2 不是天然不支持流式，不应把降级为 HTTP/1.1 当成通用解法。

可以构造每隔一小段时间输出一个完整事件的诊断端点，分别测试直连和完整代理链。这个端点用于定位传输问题，不代表真实业务已经通过性能验收。

国内：阿里云：传统 HTTP 模式与 SSE：采用事件以空行结束的格式，解释应用已写字节但客户端还未派发事件的情况。
国内：阿里云百炼：流式输出：采用前端流式读取与关闭代理响应缓冲的要求，形成客户端和代理层的排查项。
国内：CloudWeGo：Hertz SSE：采用写流、关闭和客户端断连的运行约束，检查应用层是否真正持续发送。
国内：阿里云点金：Agent 事件数据模型：区分心跳、进度和终态事件，说明排查应对照同一事件而非只看任务完成时间。
国外：WHATWG：Server-sent events：核对块缓冲会推迟事件派发，以及事件边界、编码与HTTP版本没有一一对应关系。
国外：Microsoft：Fetch Event Source：采用检查响应对象和逐事件消费的方式，说明response.text()等待整个响应与实时读取不同。
国外：NGINX：ngx_http_proxy_module：核对响应缓冲、X-Accel-Buffering以及相邻两次读取之间的超时。

参考答案