简介：本文系统定义SSE（Server-Sent Events）技术，阐明其基于HTTP的单向推送本质、核心工作原理与关键组成要素。读者将清晰理解SSE与轮询、WebSocket等技术的差异，掌握其在实时通知、AI流式输出、日志流等场景的适用边界，并获取选型与使用注意事项，为技术决策提供全面参考。
SSE，全称 Server-Sent Events（服务器发送事件），是一种基于 HTTP 协议的服务器单向推送技术。它允许服务端在建立连接后，主动、持续地向客户端发送数据流，而无需客户端反复发起请求。
从技术本质上看，SSE 并非一个全新的、独立的网络协议，而是构建在标准 HTTP/1.1（以及部分 HTTP/2 实现）之上的一种协议扩展与特定用法。它利用 HTTP 协议中已有的长连接能力和特定的响应头字段，实现了”服务器主动推、客户端被动收”的通信模式。
用一个直观的比喻来说明：如果传统的 HTTP 请求-响应模式像是”你问一句，我答一句”的对话，那么 SSE 就像是服务器打开了一条”单向数据管道”——数据可以从服务器端源源不断地流向客户端，客户端只需”倾听”即可。
从技术组成角度拆解，SSE 的核心公式可以概括为：
SSE = HTTP 扩展响应头字段 + Keep-Alive 长连接 + 文本事件流格式
其中，HTTP 扩展响应头（如 Content-Type: text/event-stream）告知客户端这是一个事件流；Keep-Alive 机制确保 TCP 连接不会因空闲而被关闭；事件流格式则定义了数据在传输过程中的结构化方式（以 data:、event:、id: 等字段组织）。
在 SSE 出现之前，实现”服务器主动推送数据”的常见方案主要有以下几种：
短轮询（Short Polling）：客户端每隔固定时间向服务器发起一次请求，询问是否有新数据。这种方式简单但效率低下，产生大量无用请求，浪费带宽和服务器资源。
长轮询（Long Polling）：客户端发起请求后，服务器保持连接不立即响应，直到有新数据才返回。虽然比短轮询高效，但实现复杂，且每个连接仍需独立管理，服务器并发压力较大。
自定义 TCP 长连接：需要额外开发协议栈，穿透防火墙和代理可能存在困难，维护成本高。
SSE 的出现正是为了解决上述问题。它基于标准 HTTP 协议，天然兼容现有的网络基础设施（如代理服务器、负载均衡器、防火墙），同时提供了一种比轮询更高效、比自定义协议更简单的实时推送方案。
特别值得一提的是，在当前 AI 大模型应用爆发的背景下，SSE 因为其天然支持”逐字流式输出”的能力，成为大模型对话接口的主流技术选择之一。用户在使用类似智能对话产品时看到的”打字机效果”，背后往往就是 SSE 在工作。
SSE 的通信基于以下几个核心要素：
Content-Type: text/event-stream：服务器在响应中设置此字段，明确告知客户端当前返回的是一个事件流，而非普通的 HTML 或 JSON。Cache-Control: no-cache：防止中间代理缓存事件流数据，确保数据实时到达。data: 承载实际数据内容（可多行）event: 指定事件类型（可选，用于区分不同类型的消息）id: 事件标识符（可选，用于客户端断线重连时的最后事件ID恢复）retry: 建议客户端断线后的重试间隔（可选）SSE 的典型工作流程如下：
客户端 服务器| ||--- HTTP GET 请求 ----------------->|| (Accept: text/event-stream) || ||<-- HTTP 200 响应 -----------------|| (Content-Type: text/event-stream)|| ||<-- data: {"message": "Hello"} ----| ← 第一条事件|<-- data: {"message": "World"} ----| ← 第二条事件| (连接持续保持，不断推送) ||-||--- [连接断开] -------------------->| ← 网络中断或客户端关闭|--- [自动重连，带 Last-Event-ID] -->| ← 客户端尝试恢复
核心要点在于：连接一旦建立，服务器可以在任意时刻、以任意频率向客户端推送数据，直到连接被主动关闭或因超时等原因中断。客户端通过浏览器原生的 EventSource API（或其他语言的对应实现）即可轻松接收这些事件。
需要特别强调的是，SSE 是严格的单向通信——数据只能从服务器流向客户端。如果客户端需要向服务器发送数据，必须另行发起独立的 HTTP 请求（如 POST）。这一特性既是 SSE 的限制，也是它保持简单、轻量的原因。
SSE 适用于服务器需要主动、持续向客户端推送数据的各类场景，主要包括：
这是当前最热门的 SSE 应用场景。大语言模型在生成回复时，通常需要逐 token 输出以降低用户等待感知。SSE 天然适合这种”服务器持续产生、客户端逐步接收”的模式，几乎所有主流 AI 对话接口都采用了 SSE 或类似的流式协议。
例如系统告警通知、订单状态更新、社交消息提醒等。服务器在事件发生时主动推送，客户端无需频繁轮询。
股票行情、IoT 传感器数据、运维监控指标等需要实时刷新的数据展示场景，SSE 可以以较低成本实现前端数据的持续更新。
在开发运维场景中，服务端可以将运行日志、操作审计记录等通过 SSE 实时推送到管理前端，便于实时查看。
文档协同、用户在线状态变更等场景，也可利用 SSE 实现轻量级的实时同步。
轮询需要客户端不断发起请求，效率低、开销大；SSE 建立一次连接后即可持续接收，资源消耗更低，实时性更强。
两者都支持全双工或持续通信，但有本质区别：
| 维度 | SSE | WebSocket |
|---|---|---|
| 通信方向 | 单向（服务器→客户端） | 双工（双向通信） |
| 协议基础 | HTTP | 独立协议（ws:///wss://） |
| 实现复杂度 | 低（原生浏览器支持） | 较高（需握手、状态管理） |
| 断线重连 | 浏览器自动处理 | 需手动实现 |
| 适用场景 | 单向推送、流式输出 | 双向交互、游戏、即时通信 |
简而言之：如果你只需要服务器向客户端推送数据，SSE 往往是更简单、更轻量的选择；如果需要双向实时交互，则应考虑 WebSocket。
HTTP/2 本身支持服务器推送能力，但该特性在实际浏览器和服务器实现中支持度有限，且灵活性不如 SSE。SSE 作为一种应用层约定，跨平台兼容性更好。
由于 SSE 是长连接，每个客户端都会占用一个连接。在高并发场景下，服务器需要合理配置连接数上限和超时策略，避免资源耗尽。
部分反向代理或负载均衡器默认会缓冲响应数据，导致 SSE 事件无法实时到达客户端。需要确认中间件支持流式转发（如关闭缓冲、设置合适的超时时间）。
虽然浏览器的 EventSource API 内置了自动重连机制，但开发者仍需设计合理的重连间隔和事件ID恢复逻辑，确保数据不丢失、不重复。
SSE 传输的是 UTF-8 编码的文本数据。如果需要传输二进制数据，通常需要进行 Base64 编码，这会增加约 33% 的数据量，需在性能敏感场景中权衡。
SSE 基于 HTTP，可以方便地使用 HTTPS 加密传输。但需注意：单向推送意味着客户端身份验证通常在初始建连请求中完成，后续推送过程中需确保连接不被劫持或篡改。
SSE（Server-Sent Events）是一种基于 HTTP 协议的轻量级、单向服务器推送技术。它通过标准的响应头字段和长连接机制，实现了服务器向客户端的持续数据流传输，无需客户端反复轮询。其核心优势在于实现简单、兼容性好（几乎所有主流浏览器原生支持）、天然适合流式输出场景。
在 AI 大模型应用蓬勃发展的今天，SSE 因其在逐字生成、实时反馈等场景中的天然适配性，成为开发者工具箱中不可或缺的技术方案之一。但它也有明确的适用边界——仅适合单向推送，不适合双向高频交互。
技术选型时，开发者应根据业务的通信方向、实时性要求、实现复杂度和基础设施兼容性综合判断。当需求是”服务器主动、持续地把数据推给客户端”时，SSE 往往是一个值得优先考虑的务实选择。百度智能云等主流云平台在构建 AI 应用和实时数据服务时，也广泛采用了 SSE 及相关流式技术能力，为开发者提供了稳定、高效的底层支撑。