简介：本文从Server-Sent Events（SSE）的定义、产生背景、核心组成、工作原理、典型应用场景及与其他实时通信技术的区别等方面展开系统讲解，帮助开发者全面理解SSE“是什么”“为什么用”“怎么用”以及“何时用”，并给出通用示例与选型建议。
Server-Sent Events，简称SSE，是一种基于HTTP协议的服务端推送技术。它允许服务端在建立连接后，持续、单向地向客户端发送数据流。客户端只需发起一次普通HTTP请求，连接建立后服务端即可不断“推”送新的数据，直到连接被关闭。
从协议本质上看，SSE并不是一个独立于HTTP的新协议，而是HTTP/1.1的一种标准化用法。它利用HTTP的长连接能力，通过特定的响应头与规范化的文本格式，将“一次请求一次响应”的传统HTTP模型扩展为“一次请求、多次响应”的流式模型。
可以这样理解：当客户端与服务端之间建立SSE连接时，服务端打开了一条单向数据管道。这条管道只允许服务端向客户端方向流动数据，客户端如果需要向服务端发送新指令，则需要另外发起普通HTTP请求。因此，SSE的通信模式可以概括为：
SSE = HTTP长连接 + 特定响应格式 + 单向流式推送
在Web应用的早期，服务端与客户端之间的数据同步主要依赖两种方式：一是客户端定时轮询，二是基于全双工连接的复杂推送协议。
轮询方式的缺陷十分明显：客户端需要每隔一段时间向服务端发起一次请求，询问是否有新数据。这种方式不仅浪费带宽和服务器资源，而且实时性受轮询间隔制约。轮询间隔过短会加剧资源消耗，间隔过长则响应延迟增大。
全双工协议虽然能解决实时性问题，但其实现复杂度较高。这类协议通常需要单独的握手升级流程、心跳维护机制、帧格式解析，且对代理、网关、负载均衡等中间网络设备的要求也更高。对于一些只需要服务端单向推送数据的场景，使用全双工协议反而显得过重。
SSE的出现填补了“简单轮询”与“复杂全双工协议”之间的空白。它基于HTTP实现，无需额外握手或协议升级，客户端使用标准的事件监听接口即可接收数据。对于服务端主动推送通知、大模型流式响应、实时日志输出、交易行情更新等单向数据流场景，SSE提供了一种轻量、直观且兼容性良好的方案。
从工程角度看，SSE的“简单”体现在三个方面：建立在普遍支持的HTTP协议之上；采用人类可读的纯文本格式传输数据；客户端API简洁，几乎不需要额外依赖。
SSE由三个核心层面构成，它们共同定义了这条单向推送通道的完整行为。
服务端在响应SSE连接请求时，首先需要通过响应头声明连接类型。最关键的响应头是：
Content-Type: text/event-stream
这一声明告诉客户端：当前响应体不是普通的一次性HTML或JSON数据，而是一个持续不断的事件流，客户端应按流式方式持续解析和处理。
此外，服务端还可以设置缓存控制头，建议中间代理不要缓冲响应数据，以保证事件能及时送达客户端。连接保持相关的HTTP语义也会影响SSE连接的存续时间，但在标准HTTP长连接机制下，只要服务端不主动关闭连接，这条流就可以持续存在。
SSE的响应体遵循一种简单而明确的文本格式。每个事件由若干字段组成，字段之间以换行符分隔，事件与事件之间以一个空行分隔。常见的字段包括：
data: 事件携带的数据内容，一个事件可以包含多行data字段，最终合并为一个完整数据块；event: 自定义事件类型，客户端可针对不同事件类型注册不同的处理逻辑；id: 事件的唯一标识，用于断线重连时的进度追踪；retry: 建议客户端在连接断开后等待多久再发起重连。一个最小化的SSE事件流示例：
data: 这是一条服务端推送的消息event: updatedata: {"status": "processing", "progress": 42}id: 1001data: 数据处理完成
在浏览器环境中，客户端通过标准的事件源接口建立连接并接收事件。开发者只需创建一个指向SSE服务端地址的连接对象，然后为默认消息事件、自定义事件以及连接状态变化事件注册回调函数即可。
客户端还内置了自动重连能力。当连接意外断开时，浏览器会根据服务端返回的retry值或默认间隔自动重新建立连接。如果服务端在事件中提供了id字段，客户端重连时还会携带最后接收到的id，使服务端可以据此决定从哪里继续推送。
SSE的完整生命周期可以分为连接建立、数据推送、连接维护和连接终止四个阶段。
连接建立阶段，客户端通过标准HTTP GET请求访问SSE服务端地址。服务端识别该请求后，返回Content-Type: text/event-stream响应头，并保持连接不关闭。此时，一条从服务端到客户端的逻辑通道正式建立。
数据推送阶段，服务端每当有新数据需要推送时，按照SSE的事件格式将数据写入响应体。客户端侧的事件源接口会持续解析响应流，一旦识别出一个完整事件，便触发相应的回调函数。服务端可以随时写出数据，无需等待客户端请求。
连接维护阶段，SSE连接依赖HTTP长连接机制保持活跃。在长时间无数据推送时，服务端可以发送注释行（以冒号开头的行）作为心跳，防止中间网络设备因超时断开空闲连接。客户端不需要对这些注释行做任何业务处理。
连接终止阶段，服务端主动关闭响应流即可结束SSE生命周期。客户端也可以在不再需要数据时主动断开连接。无论哪一方终止连接，服务端都应释放相关资源。
从代码层面看，一个通用的服务端伪代码结构如下：
处理SSE请求：设置响应头 Content-Type 为 text/event-stream设置缓存控制头 为 no-cache保持连接不关闭循环处理业务数据：当有新数据产生时：按格式写出 data 字段写出空行表示事件结束刷新响应缓冲区当业务结束或连接断开时：关闭响应流
客户端侧的核心逻辑可以描述为：
创建事件源连接对象，指定SSE地址注册默认消息处理函数注册自定义事件处理函数注册连接打开与关闭处理函数内部自动处理断线重连
SSE的单向推送特性决定了它最适合“服务端主动产生数据、客户端被动接收数据”的场景。以下是几类典型的应用方向。
大语言模型生成回答通常需要逐段产生内容。如果等待完整结果生成后再返回，用户会经历较长的等待。通过SSE，服务端可以随生成随推送，把每一个文本增量实时展示在界面上，让用户获得类似实时对话的体验。这是当前生成式AI产品中较常见的交互模式。
服务端需要向用户推送通知、告警或状态变更时，SSE提供了一种轻量的实现方式。用户登录后建立SSE连接，后续有新消息时服务端直接推送，无需客户端反复轮询。
在运维监控、构建部署、数据处理流水线等场景中，服务端会产生大量持续输出的日志信息。通过SSE将这些日志实时推送到管理界面，运维人员可以即时了解任务执行进度和系统状态。
对于需要持续更新数据的可视化看板、行情展示、实时统计等场景，SSE可以将变化的数值持续推送至客户端，由前端动态刷新展示内容。
传统轮询由客户端驱动，每隔固定时间主动请求一次数据，无论是否有新数据都会消耗一次请求。SSE由服务端驱动，只有在新数据产生时才推送，避免了大量无效请求。在实时性和资源利用率上，SSE都有明显优势。
全双工通信协议支持服务端与客户端双向实时通信，一条连接上两个方向的数据都可以自由流动。SSE则只支持服务端到客户端的单向推送。如果需要客户端高频地向服务端发送数据（如实时游戏操作、协作编辑），全双工协议更合适；如果服务端推送占绝对主导，SSE的实现成本更低。
一些服务端接口通过延长响应时间实现“准实时”推送，即服务端收到请求后不立即返回，而是等待有数据时才返回，客户端收到数据后立即发起下一个请求。这种方式本质上仍是多次请求的串联，每次数据推送都需要重新建立请求。SSE则在单条HTTP连接上持续传输多个事件，连接管理开销更小，推送延迟更低。
SSE连接保持期间，服务端需要为每个客户端维护对应的连接资源。当客户端数量较大时，需要评估服务端的并发连接承载能力，以及负载均衡、反向代理等中间层对长连接的支持情况。合理设置连接超时与空闲回收策略，避免僵尸连接占用资源。
客户端断线重连后，服务端可能需要根据事件id判断从何处继续推送，避免数据遗漏或重复。在设计事件流时，应为重要事件分配递增id，并在服务端保留一定的历史数据以支持断点续推。
SSE传输的是文本数据，二进制内容需要先做编码转换。事件数据中如果包含换行符，需要拆分为多行data字段。对于复杂结构数据，通常使用通用序列化格式（如JSON）组织内容，并确保服务端响应编码与客户端解析编码一致。
SSE连接同样需要经过认证与授权。虽然建立连接使用普通HTTP请求，但服务端仍需校验用户身份和访问权限，防止未授权用户接收敏感数据。在需要加密传输的场景中，应使用安全的传输层协议承载SSE流量。
某些代理或网关可能对长连接和流式响应有缓冲行为，导致事件不能及时到达客户端。服务端应设置合适的缓存控制响应头，网络架构设计中也应确认中间层对流式传输的兼容性。
SSE是一种构建在HTTP协议之上的服务端单向推送技术。它通过text/event-stream响应类型、标准化的文本事件格式以及客户端事件源接口，实现了“一次连接、持续推送”的通信模式。相比轮询，它显著降低了无效请求和延迟；相比全双工协议，它大幅降低了实现和部署复杂度。
SSE的核心价值在于为“服务端产生数据、客户端接收数据”的典型场景提供了一条最直接的路径。在生成式AI的流式响应、实时通知、日志推送、数据看板等方向，SSE都能以较低成本实现可靠的实时数据交付。理解SSE的定义、运行原理和适用边界，有助于开发者在面对实时通信需求时做出更合理的选型决策。