什么是服务器发送事件？流、用途和限制

Scrapeless Agent Browser 在动态网站上运行浏览器自动化，这些页面可以通过服务器发送事件接收更新。

服务器发送事件是单向 HTTP 流

服务器发送事件（通常缩写为 SSE）允许服务器通过一个长连接的 HTTP 响应发送一系列文本事件。客户端打开连接，服务器在有更新时写入。仪表盘可以接收作业进度，页面可以显示增量输出，而无需在每次变化时再次请求整个资源。

该 HTML event-stream 规范 同时定义了事件格式和浏览器的 EventSource 接口。响应媒体类型是 text/event-stream, 且流是 UTF-8 文本。SSE 不要求使用 JSON 作为负载格式。应用可以在事件的数据中放入序列化的 JSON，但解析该 JSON 是事件分帧之后的一个独立步骤。

在应用消息层面，SSE 是单向的。浏览器仍然会发送打开流的 HTTP 请求，并且可以为用户操作发送单独的请求。事件流本身承载服务器到客户端的消息。这一区分使得 SSE 适用于通知和进度展示，同时将命令保留在具有自身鉴权和校验的普通应用端点上。

事件分帧如何将文本变成消息

一条 SSE 消息由以换行分隔的字段组成，并在空行处分派。 data 字段承载负载文本， event 字段可以命名事件类型，而 id 字段可以更新事件标识符。以冒号开头的行是注释。同一事件中的多行 data 会用换行符连接。

一次网络读取并不对应一个事件。一个传输数据块可能只包含一个字段的一部分、若干完整消息，或者一个消息的结尾加上另一个消息的开头。自定义使用方需要一个持久的文本解码器和分帧缓冲区。仅按换行分割每个到达的数据块而不保留不完整文本，可能会破坏字符解码和消息边界。

未命名事件会到达 EventSource 的通用 message 处理器，而具名事件则使用其对应的事件类型。应用开发者应当为这些名称及其负载结构编写文档。进度消息、条目更新和最终完成消息不应被混为一谈。流传输只负责投递事件，应用负责定义每个事件的含义。

EventSource 和 Fetch 暴露不同接口

EventSource 是为事件流设计的浏览器 API，而 Fetch 暴露的是更通用的请求与响应接口。EventSource 接受一个 URL 和一小部分选项，而不是任意请求配置。它不提供通用选项来设置自定义授权头或发送请求体。当某个 API 协议要求特定请求头或 POST 请求时，这一点很重要。

基于 Fetch 的使用方可以读取流式响应字节并自行实现事件解析。 web Streams API 提供流抽象，但不会自动将任意文本变成正确分帧的 SSE 消息。使用 Fetch 的使用方必须处理增量解码、消息边界、取消以及服务的应用层完成信号。

根据端点协议选择接口。被描述为“流式”的服务，可能发送换行分隔 JSON、自定义二进制格式，或普通响应文本，而不是 SSE。在选择解析器之前，请检查响应媒体类型和分帧方式。仅仅看到页面逐步更新也不足以判断：这些更新可能通过 SSE、WebSockets、轮询，或对已下载数据进行客户端渲染实现。

代理和缓冲如何改变体验

事件流在表面上看来缓慢时仍然可能是有效的，因为某个组件会在转发前缓冲响应。反向代理、应用服务器、中间件以及压缩层都可能影响字节何时到达客户端。当更新不是按预期节奏而是成大批出现时，应检查完整的传输路径。服务器端快速写出并不能证明浏览器立即收到了数据。

The SSE 事件投递指南 描述了可以保持连接活跃的消息格式和注释。运行时设置仍取决于部署的技术栈。请针对具体的服务器和代理配置检查空闲超时与响应缓冲行为，并在浏览器端观测到达时间，而不是只依赖后端时间戳。

资源占用同样重要。每一个打开的流都会在系统中的某处占用连接状态，即使当前没有发送事件。当用户离开相关视图或有界观察任务已经获得足够信息时，应关闭流。容量规划应分别考虑并发连接数和事件量；一个空闲连接与一个繁忙连接在处理成本上可能大不相同。

事件 ID 不等同于投递保证

事件标识符为应用提供了一种描述其在流中位置的方式。浏览器在建立后续事件流连接时可以携带上次事件 ID，但标识符并不要求服务器必须保留历史数据。服务器的保留与重放策略决定了是否能够提供先前遗漏的事件，以及如何处理已过期的位置。

“恰好一次”处理需要的不只是收到一个 ID。应用可能在接收到事件后、保存之前就关闭，也可能在记录处理位置之前就保存了事件。对于持久摄取，应定义事件身份并将存储行为显式化。去重应基于应用的事件契约，而不是假定负载中可见文本能唯一标识一个事件。

进度指示器往往不需要永久的事件历史。财务账本或审计日志则有不同需求，应该使用经过文档化的持久接口。应依据任务所需的记录保障来选择数据源。实时可视化流可以帮助人观察过程，但仍然不适合作为完整历史数据集的唯一来源。

认证、来源与敏感负载

SSE 端点必须执行与其他端点相同的资源授权要求。用户能够打开流，并不代表其被授权接收后端可以发布的全部事件。应基于调用方过滤消息，并在服务器订阅逻辑中保持租户边界。避免仅仅为了绕过 EventSource 有限的配置选项而把机密信息放进流的 URL 中。

跨源流同样受浏览器访问规则约束。 Fetch 来源与凭据模型 决定了 CORS 与凭据在浏览器请求中的交互方式。如果浏览器无法将响应暴露给调用页面，仅有成功的服务器响应仍然不够。在使用凭据时，应配置允许的来源与凭据处理方式，使之与实际客户端相匹配。

日志与浏览器抓包可能会保留事件负载。应避免在常规诊断中包含个人数据和凭据，并为抓取到的流内容设定合适的保留期限。在授权测试期间，当事件类型、已脱敏标识符和到达时间能够回答诊断问题时，记录这些字段。抓取整段私有事件历史应当需要实际任务需求与相应权限。

观测你真正需要的应用状态

浏览器自动化任务应在有意义的页面状态出现时停止，而不是等待所有网络活动结束。SSE 连接在页面生命周期内都可以保持打开。对于有界的数据采集，应事先定义相关的选择器、完成标签、记录标识或观察窗口。对于具有持久流的页面，网络空闲条件可能永远无法代表完成。

一个有用的假设性进度任务是：监视一个公开的作业页面直到其完成标签出现，然后读取可见的结果摘要。自动化只记录在观察窗口内是否出现了完成状态。它并不会推断每一个内部进度事件都已被存储。相关的 WebSocket 消息传递概念 解释了当应用需要频繁的双向交互时，为何单独的双向通道可能更合适。

判断 SSE 是否符合产品需求

SSE 适用于服务器有更新要下发、客户端以监听为主的接口。只要连接与缓冲行为与部署环境匹配，它就是状态流、通知和增量文本的实用选择。当应用需要持久的大批量导出、任意的双向消息传递，或需要一种所选 SSE 客户端无法表达的请求形态时，应优先考虑其他接口。

在采用 SSE 之前，应写下消息类型、授权范围、完成行为、保留预期以及资源清理策略。制定浏览器观测预算时，请单独查看 Scrapeless pricing 。一个良好的设计会衡量会话所产生的有效工作，并在这些工作完成后关闭连接，而不是把无限期打开的页面视作成功的采集。

结论

当页面需要由服务器发起的文本更新且应用程序能够定义这些更新的含义和生命周期时，请使用 SSE。在依赖数据流之前，先验证其分帧、来源规则、缓冲和传输预期。对于浏览器观测，在明确的边界内收集所需状态，并在该次观测完成后关闭会话。