1、概述
SSE 并不是和 HTTP 并列的协议：SSE 是跑在 HTTP 之上的一种单向长连接推送机制。 所以更合适的对比是：
- 普通 HTTP 请求-响应：一次请求，一次完整响应，响应完连接就结束。
- SSE：一次请求后，连接保持打开，服务器持续把数据分片推给客户端。
2、核心区别
| 维度 | 普通 HTTP 请求-响应 | SSE |
|---|---|---|
| 连接方式 | 短连接，响应即关闭 | HTTP 长连接，持续推送 |
| 通信方向 | 客户端请求 → 服务端响应 | 服务端单向推送客户端 |
| 数据返回 | 一次性返回完整结果 | 分片、流式返回 |
| 实时性 | 依赖轮询或等待完整响应 | 数据生成即可推送 |
| 实现复杂度 | 低 | 较低，仍基于 HTTP |
| 自动重连 | 不支持 | 浏览器内置支持 |
2.1 AI 对话框为什么常用 SSE
AI 对话里，用户提问是一次性动作，模型回答是持续生成过程。如果用普通 HTTP，用户要等到整段回答生成完才能看到结果，体验会比较差；用 SSE 就能把 token 一段段推出来，实现"打字机效果"。典型数据流是：
- 客户端通过普通 HTTP POST 发送问题；
- 服务端建立 SSE 流式连接；
- 模型每生成一小段文本，就推送给前端；
- 前端逐块拼接、实时渲染；
- 收到结束标识后关闭连接。
3、适用场景
3.1 SSE
- AI 对话流式输出；
- 实时通知、消息提醒；
- 股票行情、比分、日志监控；
- 服务端持续推送、客户端基本不需要回传数据的场景。
3.2 普通 HTTP
- 表单提交、列表查询、详情查询；
- 一次性返回完整结果；
- 不需要服务端主动推送；
- 对兼容性要求极高，或者客户端本身就能接受等待完整响应。
3.3 考虑 WebSocket
- 需要双向高频交互；
- 多人实时聊天；
- 在线协作编辑；
- 实时音视频控制；
- 客户端需要在非提问时刻频繁向服务端发消息。
3.4 总结
客户端只问一次、服务端持续推结果，用 SSE；客户端和服务端都要频繁互发数据，用 WebSocket；一次性拿完整结果，用普通 HTTP。