为何选 Fetch SSE 而非原生 SSE 或 WebSocket？

核心回答

如果请求需要 POST 请求体、自定义认证头和主动取消，同时响应主要是服务端向客户端推送文本事件，基于 Fetch 读取 SSE 更合适。这里的“Fetch SSE”是用 Fetch 消费 SSE 格式，并不是另一种传输协议。

原生 EventSource 接口简单，提供事件分帧和自动重连，但浏览器接口主要接受地址和凭证选项，不能像 Fetch 一样指定任意请求方法、请求体与自定义头。WebSocket 适合持续双向通信；仅需单向进度或生成文本时，额外引入双向通道未必值得。

怎样作出具体选择

提交复杂查询参数并持续接收结果时，可以用一次 POST 流式响应。若任务创建与订阅已分开，先 POST 创建任务，再用 EventSource 对任务地址发起 GET 订阅，也能避免把全部参数放进地址。这时应根据鉴权与恢复需求选择，而不是认为 EventSource 一定不能做。

需要客户端持续发送实时控制、双向协作或二进制消息时，再评估 WebSocket。取消一个后台任务也可以用独立 HTTP 请求表达，并不天然要求双向长连接。

Fetch 方案要自己补什么

fetch() 返回的响应流不会自动解析 SSE、重连或重放事件。需要检查状态码与 Content-Type，用流式解码和标准事件解析器读取，通过 AbortController 终止本地请求，并实现退避、最后事件序号及终态判断。

终止读取只是关闭客户端连接，不保证服务端任务已经取消；服务端仍须感知断连，或接受独立的取消命令。使用成熟库时也要核对其后台页面、自动重连与错误处理策略是否符合业务。

对应教程

参考资料