为什么AI的“打字机”效果选SSE,不是WebSocket的不够强,而是...

别再用牛刀杀鸡了，选对技术让开发效率翻倍

用过ChatGPT、Kimi或者豆包的朋友，一定对那个“打字机”式的逐字输出效果印象深刻——你刚提完问题，答案就一个字一个字地往外蹦，仿佛AI在一边思考一边打字。这种体验流畅又自然，让人忍不住想多聊几句。

但你知道这背后用的是啥技术吗？答案是SSE（Server-Sent Events，服务器推送事件），而不是很多人以为的WebSocket。

今天这篇文章，我们就来聊聊：为什么AI流式输出选择了SSE，而不是功能更强大的WebSocket？

1、先看效果：什么是“打字机”式输出？

传统HTTP请求就像你去餐厅点餐——点完菜，后厨全部做好，服务员一次端上来。如果菜做得慢（比如AI生成一篇长文要几十秒），你就只能干等着，体验极差。

而流式输出（Streaming）则像是后厨边做边送——做好一个字就送一个字，用户一边看一边等，感知等待时间大幅缩短。

某主流语言模型在生成2000字回复时，SSE可将首字响应时间从800ms压缩至200ms以内。用户看到第一个字的时间缩短了75% ，这就是“打字机”效果的魔力所在。

2、SSE vs WebSocket：核心区别一张表看懂

我们通过一张直观的对比来查看其两种技术的不同点：

特性	SSE（Server-Sent Events）	WebSocket
通信方向	单向：服务器 → 客户端	全双工：客户端 ↔ 服务器
协议基础	标准HTTP协议	独立协议（需HTTP握手升级）
数据格式	仅文本（UTF-8）	文本 + 二进制
自动重连	✅ 浏览器原生支持	❌ 需手动实现
开发复杂度	低，EventSource API开箱即用	高，需处理握手、心跳、重连等
服务器资源	每个连接1-2KB内存	每个连接2-5KB内存
高并发成本	基准线	多消耗约40%服务器资源

3、为什么AI输出偏偏选中了SSE？

原因一：杀鸡不用牛刀——场景匹配是第一原则

AI对话的核心交互模式是：用户发一次请求，服务器持续推送生成的文字。这是一个典型的服务器到客户端的单向数据流。

WebSocket虽然功能强大，但它是一个“全双工”协议，支持两边同时说话。在AI流式输出这个场景里，WebSocket有一半的能力是闲置的——就像你明明只需要一个单向的麦克风，却搬来了一整套双向对讲设备。

有开发者一针见血地指出：“LLM的token流式传输本质是单向数据推送，使用双向通信协议属于技术方案错配。”

原因二：SSE天然适配HTTP生态，部署省心

SSE基于标准HTTP协议，这意味着它可以无缝通过反向代理、负载均衡器和防火墙，无需任何特殊配置。

而WebSocket需要专门的协议升级（HTTP 101 Switching Protocols），在Nginx等代理上需要额外配置，负载均衡还要开启粘性会话（Sticky Session）。

用SSE，开箱即用；用WebSocket，处处要改。

原因三：自动重连，省掉一半的坑

SSE的EventSource API是WHATWG的HTML标准的一部分。连接断了？浏览器自动帮你重连。服务器还能通过id字段实现断点续传——重连后从断开的地方接着收。

WebSocket呢？一切都要手动写：心跳保活、断线检测、重连逻辑、指数退避……有开发者统计，用WebSocket做LLM流式传输，光连接管理的代码就能多写几百行。

原因四：省钱——服务器资源消耗更低

某云厂商的测试数据显示：在10万并发场景下，WebSocket方案比SSE方案多消耗40%的服务器资源。

SSE每个连接仅占用1-2KB内存，WebSocket则需要2-5KB。对于需要处理海量并发请求的AI服务来说，这40%的成本差距，可能就是几台服务器的差别。

4、那WebSocket什么时候上场？

看到这里你可能要问：WebSocket这么“重”，是不是就没用了？

当然不是。WebSocket的“全双工”能力，在以下场景中无可替代

实时语音交互：需要双向音频流传输
在线协作编辑：多人同时编辑，需要实时双向同步操作
即时通讯/聊天室：双向消息传递
实时白板/绘图：双向操作同步
需要客户端中途发送指令：比如AI生成过程中用户要求修改、取消，或者进行工具调用（Tool Calls）

一句话总结：如果你的应用需要“两边同时说话”，选WebSocket；如果只是“服务器单方面推送”，SSE足矣。

5、实战：SSE到底怎么写？

后端（FastAPI）只需几行代码：

# python代码@app.get("/stream")asyncdefstream_response(prompt: str):asyncdefevent_stream():asyncfor token in token_generator(prompt):# SSE格式：data: 内容\n\nyieldf"data: {token}\n\n"return StreamingResponse(        event_stream(),         media_type="text/event-stream"    )

前端更简单，原生API直接搞定：

const eventSource = new EventSource('/api/stream-chat');eventSource.onmessage = (e) => {const data = JSON.parse(e.data);// 逐字追加到页面document.getElementById('output').innerText += data.chunk;};

6、总结：

技术选型没有绝对的“好”与“坏”，只有“合适”与“不合适”。AI流式输出选择SSE而不是WebSocket，不是因为SSE更先进，而是因为它更匹配这个场景的需求。

对于SSE使用场景：单向推送、HTTP原生兼容、自动重连、资源消耗低。

如果觉得这篇文章对你有帮助，欢迎点赞、在看、转发三连～