简介：本文系统讲解SSE（Server-Sent Events）的定义、技术原理、核心组成与典型使用场景。你将理解SSE为何被称为“HTTP协议上的单向实时推送方案”，它与长轮询、WebSocket的本质区别在哪里，以及在通知推送、日志流、AI逐字输出等场景中如何正确选型与落地。文章兼顾概念入门与工程细节，适合后端开发、前端工程师及技术选型人员阅读。
SSE，全称为Server-Sent Events，中文通常译为“服务器推送事件”。它是一种基于HTTP协议的服务器向客户端单向推送数据的技术机制。更准确地说，SSE并不是一个独立于HTTP的全新协议，而是对标准HTTP/1.1协议能力的一种约定化使用方式。
从技术视角看，SSE可以拆解为两层理解：
第一层：传输层。 SSE依赖HTTP协议本身的长连接能力。客户端通过一个普通的HTTP GET请求建立连接，服务器在响应中声明一个特殊的Content-Type，然后保持该连接不关闭，持续向客户端写入数据。
第二层：消息格式层。 SSE定义了一套基于纯文本的事件流格式。服务器按照该格式将消息分帧发送，客户端通过浏览器内置的EventSource接口自动解析这些帧，并将其转换为可被JavaScript消费的事件对象。
因此，SSE的本质可以概括为：
SSE = HTTP长连接 + 特定Content-Type + 纯文本事件流格式 + 浏览器原生EventSource解析能力
这个定义中有几个关键点值得反复强调：它构建在HTTP/1.1之上，不需要额外的协议升级握手；它是单向的，数据只能从服务器流向客户端；它使用纯文本格式，易于调试和观察；最重要的是，主流浏览器均提供了原生API支持，前端无需引入任何第三方库即可使用。
在SSE出现之前，如果服务器需要主动向浏览器推送数据，开发者面临的选择其实非常有限。
最朴素的做法是客户端轮询。前端通过定时器每隔几秒发起一次HTTP请求，询问服务器是否有新数据。这种方式实现简单，但存在明显缺陷：大部分请求可能返回空结果，造成带宽和服务器资源的浪费；实时性受限于轮询间隔，间隔过短则压力陡增，间隔过长则延迟明显。
在此基础上发展出了长轮询。客户端发起请求后，服务器不立即返回，而是持有该请求，直到有新数据时再响应。客户端收到响应后，立刻发起下一个请求。这种方式在一定程度上降低了空请求的频率，但实现复杂度上升，且服务器端需要维护大量挂起的连接，连接管理成本较高。
SSE的价值正在于此：它提供了一种标准化、低复杂度、原生浏览器支持的服务器推送方案。开发者不需要手写轮询逻辑，不需要处理协议的升级握手，也不需要担心消息分帧和断线重连的底层细节——这些工作由浏览器EventSource对象自动完成。
从工程价值角度归纳，SSE至少解决了以下几个核心问题：
要完整理解SSE，需要拆解它的几个核心组成部分。
浏览器端通过EventSource构造函数建立连接。其基本用法如下：
const source = new EventSource('/api/events');source.onopen = function(event) {console.log('连接已建立');};source.onmessage = function(event) {console.log('收到默认消息:', event.data);};source.addEventListener('custom-event', function(event) {console.log('收到自定义事件:', event.data);});source.onerror = function(event) {console.log('连接发生异常');};
EventSource对象封装了连接建立、消息解析、自动重连等能力。当连接意外断开时，浏览器会自动发起重连请求，无需开发者手动干预。这一特性对于需要持续推送的场景尤为重要。
服务器在收到SSE请求后，必须返回以下关键的HTTP响应头：
Content-Type: text/event-streamCache-Control: no-cacheConnection: keep-alive
Content-Type: text/event-stream是SSE的标识性响应头，客户端依靠它识别这是一条SSE流。Cache-Control: no-cache确保中间代理设备不会缓存事件流内容。Connection: keep-alive声明连接保持长连接状态。
SSE的消息格式是纯文本的，每条消息由若干字段组成，字段之间以换行符分隔，消息与消息之间以空行分隔。核心字段包括：
data: 消息数据体，一条消息可以包含多行data，最终会以换行符拼接。event: 自定义事件类型，客户端可根据此字段区分不同类型的消息。id: 消息标识符，客户端会记录最后一次收到的id，用于断线重连时通过Last-Event-ID请求头告知服务器从何处继续。retry: 建议的重连间隔时间（毫秒）。一个典型的SSE响应体示例如下：
event: notificationid: 1001data: {"title":"新消息","content":"您有1条未读通知"}event: logid: 1002data: 2025-01-15 10:23:45 INFO Task completeddata: 2025-01-15 10:23:46 INFO Cleaning up resources
第一条消息定义了事件类型为notification，带有id和JSON格式的数据。第二条消息定义了事件类型为log，包含两行data，客户端收到时会将两行数据以换行符连接后作为event.data的值。
SSE内置了断线重连机制。当连接因网络波动、服务器重启等原因中断时，浏览器EventSource会自动按照一定间隔重新发起请求。如果服务器在之前的消息中设置了id字段，客户端在重连请求中会自动携带Last-Event-ID请求头，服务器可以据此判断客户端消费到了哪条消息，从而决定是否需要进行数据补偿。这一机制为SSE提供了基本的可靠性保障。
将上述组成部分串联起来，可以描绘出一条完整的SSE通信链路。
第一阶段：连接建立。 客户端通过JavaScript代码创建EventSource对象，指定一个URL。浏览器向该URL发起一个标准的HTTP GET请求，并在请求头中自动携带Accept: text/event-stream。
第二阶段：服务器确认。 服务器收到请求后，判断这是一个SSE请求，返回HTTP 200状态码，并设置响应头Content-Type: text/event-stream以及相关的缓存控制头。此时连接保持打开状态，不会因响应结束而关闭。
第三阶段：持续推送。 服务器在有数据需要推送时，按照SSE消息格式将数据写入响应体。每次写入可以是一条消息，也可以是多条消息。由于连接是流式的，服务器可以在任意时间点写入数据，客户端会实时收到。
第四阶段：连接维护。 在长连接期间，客户端和服务器之间可能没有数据交互。为了检测连接是否仍然有效，服务器可以定期发送注释行（以冒号:开头的行）作为心跳。浏览器会忽略注释行，但连接的活动状态得以保持，中间代理设备也不会因为超时而关闭连接。
第五阶段：异常恢复。 如果连接中断，浏览器EventSource会自动进行重连。重连请求中会携带Last-Event-ID头（如果有），服务器可以根据该值恢复数据流。重连间隔由服务器的retry字段或浏览器默认值控制。
第六阶段：连接关闭。 客户端可以调用EventSource对象的close()方法主动关闭连接。服务器也可以通过在响应中返回非200状态码或直接断开TCP连接来终止SSE。
SSE的单向推送特性决定了它在一系列实时数据场景中具有天然适配性。
社交平台的新消息提醒、工单系统的状态变更通知、监控系统的告警推送等，都是典型的服务器到客户端的单向信息流。这类场景中，客户端不需要向服务器发送实时数据，SSE的简洁性体现得尤为突出。相比WebSocket的全双工通道，SSE省去了协议升级和心跳保活的复杂度，同时也更容易穿透常见的HTTP基础设施。
运营数据大屏、实时业务指标展示等场景中，后端需要将最新的统计数据推送到前端页面。SSE可以以固定频率或按事件触发的方式推送更新数据。由于数据流向是单向的，且前端主要承担展示职责，SSE是比WebSocket更为轻量且更容易实现的选择。
在运维平台或CI/CD系统中，实时展示构建日志、部署进度、任务执行状态是高频需求。服务器可以将日志行逐条包装为SSE消息推送到前端，前端在页面上实时渲染。配合id机制，页面刷新或断线重连后还能向服务器报告消费位置，实现断点续传。
生成式AI模型在生成回答时，通常采用流式输出的方式，将生成的文本片段逐个或逐批返回。这类场景中，用户输入指令是一次性的，而模型输出是持续的、单向的。SSE正好契合了这一交互模式：用户提交请求后建立SSE连接，服务器将模型生成的文本片段不断推送到前端，前端实时渲染成连续的对话内容。这也是当前大量AI对话类应用采用SSE作为流式传输方案的核心原因。
某些场景下，客户端需要订阅服务器上某个资源的状态变化。例如，一个文件处理任务的进度、一次数据导入任务的阶段状态、一个异步计算任务的结果通知。这类场景中，服务端状态是数据源，客户端是数据消费方，SSE可以提供简单有效的状态同步通道。
这是最常被问到的一对概念。
通信方向是本质区别。WebSocket提供全双工通信能力，客户端和服务器可以在同一条连接上双向发送数据。SSE是严格单向的，数据只能从服务器流向客户端。如果业务需要客户端频繁向服务器发送实时数据，WebSocket是更合适的选择；如果数据流向以服务器推送为主，SSE往往足够。
协议层级也不同。WebSocket通过HTTP协议升级握手后，切换为独立的WebSocket协议进行数据传输，拥有自己的帧格式。SSE始终运行在HTTP协议之上，使用的是标准的HTTP请求和响应机制。
基础设施兼容性方面，SSE具有天然优势。由于SSE本质上是普通的HTTP流量，它可以无缝穿过现有的负载均衡设备、反向代理和防火墙。WebSocket则需要基础设施对协议升级提供支持，在某些复杂的网络环境中可能遇到障碍。
数据格式上，SSE仅支持文本数据，二进制数据需要经过编码（如Base64）后传输。WebSocket原生支持二进制帧，更适合传输图片、音频等二进制内容。
长轮询是SSE出现之前常用的“准实时”推送方案。在长轮询模式下，客户端每次请求后，服务器持有连接直到有新数据或超时才响应，客户端收到响应后立即发起下一个请求。
两者的关键差异在于连接的持续性。长轮询中，每条消息的推送都伴随着一次请求-响应周期的结束和新连接的建立。SSE则维持一条持续的长连接，服务器可以多次写入数据而不需要重新建立连接。这意味着SSE在推送频繁、数据量大的场景下具有更低的协议开销和更好的实时性能。
HTTP/2引入了Server Push能力，允许服务器在响应客户端请求时主动推送相关资源。但HTTP/2 Server Push主要用于资源预加载（如CSS、JavaScript文件），其推送内容与原始请求存在关联，且不是为持续数据流设计的。SSE则是面向持续事件流的推送机制，两者解决的问题域不同。在HTTP/2环境下，SSE连接可以复用HTTP/2的多路复用能力，一个域名的多SSE连接可以共享同一条TCP连接，但这与HTTP/2 Server Push是两个独立的概念。
浏览器对同一域名的并发HTTP连接数有默认限制（通常为6个左右，HTTP/2下这一限制有所放宽）。虽然SSE使用长连接，但在多标签页场景下，每个标签页独立建立SSE连接会迅速消耗连接配额。工程实践中，可以考虑使用共享的SSE连接，或者通过本地广播机制在多个标签页之间共享数据流。
某些中间代理设备或反向代理服务器可能会对HTTP响应进行缓冲，导致SSE事件无法实时到达客户端。为了规避此问题，应确保SSE响应头中包含Cache-Control: no-cache，并考虑设置X-Accel-Buffering: no（适用于主流反向代理场景）来关闭缓冲。在部署环境中，应对代理配置进行验证，确保事件流的实时性不被破坏。
长连接在空闲状态下可能被网络中间设备主动断开。建议服务器在SSE连接上定期发送心跳注释行（以冒号开头的行），以维持连接活动状态。心跳间隔应根据网络环境和基础设施配置进行调整，通常设置在15秒到60秒之间。
虽然浏览器EventSource自动处理重连，但服务器端需要关注重连时的数据恢复策略。利用id字段和Last-Event-ID请求头，服务器可以实现断点续传。对于不需要从断点恢复的场景，也可以忽略Last-Event-ID，重新推送最新数据即可。客户端在设计上需要考虑消息的幂等性处理，避免因重连导致的数据重复消费问题。
SSE连接同样需要经过身份认证和授权校验。由于EventSource构造函数仅支持GET请求且不能自定义请求头，基于Token的认证通常需要将凭证放在URL查询参数中，这会带来凭证泄露风险。更安全的做法是结合Cookie-based会话认证，或者在建立SSE连接前先通过其他接口获取短期有效的访问令牌。此外，SSE流中的数据内容应避免包含敏感信息，或对敏感字段进行加密处理后再传输。
每条SSE连接在服务器端都会占用一个线程或协程资源。在高并发场景下，需要评估服务器的连接承载能力。对于大量低速推送的场景，可以考虑使用异步非阻塞的服务器模型来提升单机连接数。同时，应设置合理的连接超时策略，及时清理无效或长时间不活跃的连接。
回归定义本身，SSE是一种构建在标准HTTP协议之上的服务器单向推送技术。它的核心价值在于用极低的实现成本提供可靠的实时数据推送能力。它不是WebSocket的替代品，也不是轮询的简单升级，而是在特定约束条件下的一种优雅选择。
当你的业务满足以下特征时，SSE值得被优先考虑：数据流向以服务器到客户端为主、客户端不需要频繁发送实时数据、需要穿透现有HTTP基础设施、希望利用浏览器原生能力降低前端复杂度、传输内容为文本格式。
理解SSE的定义与边界，比掌握它的API细节更为重要。技术选型的本质是对约束条件的识别与权衡，而SSE正是在“实时性需求”与“实现复杂度”之间找到的一个平衡点。在生成式AI流式输出、实时日志展示、通知推送等场景中，SSE已经证明了自己是一个简单、可靠且被广泛支持的工程方案。