评估SSE与带可读流的Fetch时需注意的隐性及语义差异有哪些

针对你的只读实时事件流场景（峰值30-50次/秒），SSE相比流式Fetch有以下原生特性层面的固有优势：

• 开箱即用的事件协议封装：SSE是W3C标准化的单向服务器推送协议，原生定义了消息边界、事件类型、事件ID、重试超时等字段，不需要你自行设计消息格式、处理粘包/分包逻辑。前端可以直接监听不同类型的事件，不需要额外做消息解析，开发效率远高于流式Fetch。你提到的手动构建响应场景下，SSE的消息格式仅为data: {消息内容}\n\n，拼接成本和流式Fetch的自定义分块基本一致，没有额外实现难度。
• 原生自动重连+断点续推能力：浏览器的EventSource实现会在连接异常断开时自动发起重连，并且会自动在请求头中携带Last-Event-ID字段（值为最后一次收到的事件ID），后端只需要根据这个ID返回后续的事件即可实现断点续推，不需要自己编写心跳检测、断线重连、消息位点记录的冗余逻辑。流式Fetch的所有异常处理、重连逻辑都需要手动实现，维护成本更高。
• 前端API易用性更强：前端实现SSE消费仅需要实例化EventSource对象，通过addEventListener监听对应事件即可，代码量只有流式Fetch的1/3不到，也不需要手动处理ReadableStream的读取、二进制解码、消息拼接等底层逻辑，出错概率更低。
• 中间节点兼容性更好：SSE有标准化的响应头要求（Content-Type: text/event-stream、Cache-Control: no-cache等），绝大多数反向代理、CDN、防火墙都能正确识别这类长连接响应，不会随意缓存内容、截断连接。如果使用自定义格式的流式Fetch响应，很容易因为头配置不规范被中间节点异常处理，排查成本极高。
• 成熟的错误处理机制：当连接出现异常、后端返回非预期状态码时，EventSource会自动触发error事件，你可以直接根据状态判断是否终止重连，不需要手动解析响应状态、处理流异常中断的边界case。

内容的提问来源于stack exchange，提问作者i336_