SSE（Server-Sent Events）—— 为什么 AI 能够一边思考一边回复？
前言
前面，我们已经学习了 Streaming（流式输出），知道 AI 并不是等全部回答生成完以后再一起返回，而是一边生成、一边输出内容。
例如，我们向 AI 提问：
请介绍一下 Python。
在 ChatGPT、DeepSeek 等 AI 产品中，我们看到的效果通常是：
P
↓
Py
↓
Pyth
↓
Python 是一种……
而不是等待十几秒后，一次性出现全部内容。
那么，一个新的问题来了：
AI 为什么能够不断把新的内容发送给浏览器？
浏览器又为什么能够持续接收这些数据？
答案就是今天要学习的内容：
SSE（Server-Sent Events）
它是实现 AI 流式输出的重要基础，也是现代 AI Chatbot 最常见的数据传输方式之一。
一、为什么需要 SSE？
如果不用流式传输，一次普通 HTTP 请求通常是这样的：
浏览器发送请求
│
▼
服务器开始生成回答
│
▼
等待全部完成
│
▼
一次性返回完整结果
例如：
用户发送：
请介绍 FastAPI。
服务器需要生成 1000 个字。
如果生成过程需要 15 秒，那么浏览器只能一直等待。
直到：
15 秒后
↓
收到完整回答
整个等待过程中,
页面没有任何变化。
用户不知道：
- AI 有没有开始工作；
- 程序是不是卡住了；
- 网络是不是断了。
用户体验非常差。
因此，需要一种新的通信方式：
服务器生成一点，就发送一点。
这就是 SSE 存在的意义。
二、什么是 SSE？
SSE（Server-Sent Events）全称：
Server-Sent Events（服务器发送事件）。
它是一种基于 HTTP 的服务器推送技术。
与普通请求最大的区别在于：
普通 HTTP：
请求
↓
等待
↓
一次返回
而 SSE：
请求
↓
服务器保持连接
↓
持续发送数据
↓
浏览器持续接收
也就是说
服务器不会立即关闭连接。
而是一直保持：
浏览器
│
│
│
服务器
不断发送新的内容。
因此：
SSE 本质上就是：建立一条持续存在的 HTTP 通道，让服务器能够不断向浏览器推送数据。
三、SSE 在 AI Chatbot 中是如何工作的？
假设我们向 AI 提问：
什么是 Python？
整个过程如下：
用户发送消息
│
▼
FastAPI
│
▼
DeepSeek API
│
▼
开始 Streaming
│
▼
SSE 持续发送数据
│
▼
浏览器不断接收
│
▼
页面持续更新
注意,这里真正持续发送数据的是：
服务器。
浏览器只是不断接收。
所以 SSE 又叫：
Server-Sent Events（服务器主动发送事件）。
四、SSE 发送的数据长什么样？
很多人第一次都会以为
服务器返回的是：
{
"message":"Hello"
}
实际上并不是。
SSE 返回的数据格式通常是：
data: Hello
data: How
data: are
data: you
或者：
data: {"choices":[…]}
data: {"choices":[…]}
data: {"choices":[…]}
可以看到, 服务器不是返回一个完整 JSON。
而是：
一行一行发送数据。
每一行 都是一次新的事件。
五、为什么浏览器能够一直收到数据？
这是很多初学者最容易疑惑的地方。
原因就在于：
普通 HTTP：
服务器返回
↓
连接关闭
而 SSE：
服务器返回一部分
↓
连接不关闭
↓
继续发送
↓
继续发送
↓
继续发送……
浏览器一直监听这条连接。
因此：
每收到一段新的数据，
页面就可以立即更新。
所以我们看到：
H
↓
He
↓
Hel
↓
Hell
↓
Hello
而不是：
Hello
一次性出现。
六、SSE 在 KK Chat 中的作用
结合自己的项目：
整个流程如下：
用户发送消息
│
▼
Fetch API
│
▼
FastAPI
│
▼
DeepSeek Streaming
│
▼
SSE
│
▼
浏览器持续接收数据
│
▼
Message Rendering
│
▼
Markdown Rendering
│
▼
Highlight.js
│
▼
Auto Scroll
│
▼
最终显示
可以看到,SSE 位于：
服务器与浏览器之间。
它负责：
不断把 AI 最新生成的数据发送给浏览器。
而真正负责显示数据的：
仍然是前端。
七、实践内容
今天主要学习了：
- 什么是 SSE；
- 为什么 AI Chatbot 需要 SSE；
- 普通 HTTP 与 SSE 的区别；
- SSE 的数据发送方式；
- SSE 在 Streaming 中的作用；
- SSE 在 KK Chat 中的位置。
整个 Streaming 数据流程进一步完善为：
DeepSeek
│
▼
Streaming
│
▼
SSE
│
▼
浏览器持续接收
│
▼
前端渲染
八、遇到的问题
1. Streaming 为什么不是 WebSocket？
原因：
很多人认为，只要需要实时通信，就一定要使用 WebSocket。
理解：
对于 AI Chatbot 而言，绝大多数场景的数据流向都是：
服务器持续向浏览器发送内容。
浏览器主要负责发起请求，而回复内容由服务器不断推送。
因此，像 OpenAI、DeepSeek 等接口通常采用基于 HTTP 的流式响应（常见形式就是 SSE），无需建立双向通信。
2. SSE 为什么还能使用 HTTP？
原因：
很多人认为 HTTP 一定是：
请求一次，
返回一次。
实际上：
HTTP 连接可以保持打开。
服务器可以在同一条连接中：
持续发送事件。
3. 浏览器为什么不会卡住？
原因：
SSE 属于异步数据流。
浏览器接收数据的同时：
页面仍然可以：
- 滚动；
- 点击按钮；
- 输入新的内容；
不会因为等待 AI 回复而阻塞整个页面。
九、今天的收获
今天最大的收获，是理解了：
Streaming 的核心，不只是 AI 一边生成内容，更重要的是服务器能够持续把这些内容发送给浏览器。
SSE 正是承担这一工作的关键技术。
它让浏览器无需反复轮询服务器，就可以持续接收新的数据，从而实现现代 AI Chatbot 常见的流式回复体验。
对于 KK Chat 来说，SSE 并不负责渲染页面，而是负责把服务器生成的数据稳定地传递给前端。
总结
今天学习了 SSE（Server-Sent Events），理解了现代 AI Chatbot 为什么能够实现"边生成、边回复"。
SSE 本质上是一种基于 HTTP 的服务器推送机制，它保持连接不断开，让服务器能够持续向浏览器发送数据，为 Streaming 提供了底层的数据传输能力。
通过今天的学习，我进一步理解了 Streaming 的整体工作流程，也为后续学习浏览器如何读取这些数据打下了基础。
KJ
