SSE、WebSocket、fetch 流怎么选？
先理解原理和示例，再练习完整口述与追问。
回答要点
SSE 是服务端向客户端推送事件的一种格式与机制；WebSocket 支持双向通信。fetch 可读取响应流，也能消费 SSE 格式；这三者不是完全并列的互斥选项。
原生 EventSource 通常用于 GET，不能直接设置任意请求头或 POST body；需要 POST 提交内容、携带自定义认证头时，可以由 fetch 读取流。选择还取决于协议、认证、重连及产品需求。MDN：SSE
原理拆解
EventSource 是浏览器消费 SSE 的专用 API，常用于 GET 订阅，有内置重连语义但自定义请求头等能力有限；fetch 流可发送 POST、带自定义头并读取流，但需要自己处理分帧、重连与状态；WebSocket 建立持续双向通道，适合频繁双向消息。选择依据是交互方向、鉴权、部署和恢复协议。
示例与推演
AI 单次提问可用 POST fetch 接收 SSE 格式流，后端代理模型并统一鉴权；行情订阅可能适合 EventSource；协同编辑或实时语音可考虑 WebSocket。SSE 经过反向代理时需确认未被缓冲、空闲超时和心跳；WebSocket 则要单独处理连接、心跳与重连后的会话状态。
易错点
使用 SSE 格式不等于必须使用 EventSource。重连若没有事件 ID 和去重，可能重复追加文本或重复执行任务。
参考回答可直接练习口述
如果主要是提交一次问题、持续接收答案，我可以用 HTTP 请求读取流，服务端事件格式可选 SSE；需要双向实时音频或持续互动时，再评估 WebSocket。SSE 是单向服务端事件流，fetch 是发请求和读取响应的 API，两者可以组合。原生 EventSource 主要用 GET，不能自由设置 POST body 和任意认证头；聊天 POST 加 Bearer 认证常用 fetch + ReadableStream。断线恢复、心跳、超时和代理配置需要显式设计。