在做AI 对话产品时，很多人都会遇到一个问题：
为什么有的实现能像 ChatGPT 一样逐字输出，而有的只能“等半天一次性返回”？
问题的核心，往往不在模型，而在前后端的流式通信方式。
本文从实战出发，系统讲清楚SSE、fetch、axios 在 AI 流式对话中的本质区别与选型建议。
先给结论（重要）
AI 流式对话的正确打开方式：
- ✅ 首选：
fetch + ReadableStream- ✅ 可选：
SSE（EventSource）- ❌ 不推荐：
axios
如果你现在用的是 axios，还在纠结“为什么没有逐 token 输出”，可以直接往下看结论部分。
AI 流式对话的本质需求
在传统接口中，请求和响应通常是这样的：
请求 → 等待 → 返回完整结果但 AI 对话不是。
AI 流式对话的真实需求是：
- 模型逐 token 生成
- 前端边接收、边渲染
- 连接可持续数十秒
- 用户能感知“正在思考 / 正在输出”
这决定了：必须支持真正的 HTTP 流式响应
SSE、fetch、axios 的本质区别
在对比之前，先明确一个容易混淆的点：
1、SSE 是「协议能力」
SSE（Server-Sent Events）是一种基于 HTTP 的流式推送协议
Content-Type: text/event-stream- 服务端可以不断向客户端推送数据
- 浏览器原生支持
EventSource
它解决的是：“服务端如何持续推送数据”
2、fetch / axios 是「请求工具」
| 工具 | 本质 |
|---|---|
| fetch | 浏览器原生 HTTP API |
| axios | 对 XHR / fetch 的封装库 |
它们解决的是：“前端如何发请求、拿响应”
常用流式方案
SSE：最简单的流式方案
constes=newEventSource('/api/chat/stream')es.onmessage=(e)=>{console.log(e.data)}优点
- ✅ 原生支持流式
- ✅ 自动重连
- ✅ 心跳、事件类型清晰
- ✅ 非常适合AI 单向输出
缺点（关键）
- ❌ 只支持
GET - ❌ 不能自定义 Header（鉴权不友好）
- ❌ 只能服务端 → 客户端
适合场景：AI 回答输出、推理过程/日志流、实时通知类数据。
fetch + ReadableStream（推荐）
这是目前AI 产品中最主流、最灵活的方案。
constres=awaitfetch('/api/chat',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({prompt})})constreader=res.body.getReader()constdecoder=newTextDecoder()while(true){const{value,done}=awaitreader.read()if(done)breakconstchunk=decoder.decode(value)console.log(chunk)}为什么它是首选？
- ✅ 支持 POST（可传 prompt、上下文）
- ✅ 可自定义 Header（token、traceId）
- ✅ 真正的 chunk / token 级流式
- ✅ 与 OpenAI / Claude 接口完全一致
- ✅ Web / Node / Edge Runtime 通用
一句话总结：fetch + stream是目前AI 流式对话的标准
axios：为什么不适合 AI 流式？
这是很多人踩坑最多的地方。
常见误解
axios.post('/api/chat',data,{onDownloadProgress(e){console.log(e)}})看起来像“流式”，但实际上axios 的真实问题：
- 浏览器端基于 XHR
- 响应会被缓冲
onDownloadProgress不是 token 级回调- 延迟明显、体验差
结论：axios 在浏览器端不支持真正的流式响应
它更适合普通 REST API、表单提交、数据请求，但不适合 AI 流式输出。
总结
| 方案 | 真流式 | POST | Header | 推荐度 |
|---|---|---|---|---|
| SSE (EventSource) | ✅ | ❌ | ❌ | ⭐⭐⭐ |
| fetch + stream | ✅ | ✅ | ✅ | ⭐⭐⭐⭐⭐ |
| axios | ❌ | ✅ | ✅ | ⭐ |
- SSE 是流式协议
- fetch 是流式容器
- axios 是传统请求工具
如果你正在做 AI 产品，通信层选错，后面再怎么优化模型和前端体验，都会事倍功半。
