SSE断线重连带Last-Event-ID补发方法

本文深入解析了Server-Sent Events（SSE）断线重连与断点续推的核心实现机制，重点阐述如何通过服务端精准识别并响应Last-Event-ID请求头、为每个事件分配唯一有序的字符串ID，以及客户端EventSource自动携带该ID的协同逻辑；文章不仅强调ID设计（如用数据库主键或严格递增序列）、服务端容错校验与安全定位起始位置的关键细节，还揭示了开发者易忽略的隐性前提——如事件格式必须以\n\n结尾、避免非法字符干扰解析、不可手动破坏EventSource默认重连上下文等，真正帮你避开“看似支持断点实则失效”的常见陷阱，实现稳定可靠的实时数据续推。

关键在于服务端能识别并响应 Last-Event-ID，客户端能正确携带它，两者配合才能实现真正的“从断点续推”。浏览器 EventSource 会自动重连并带上这个头，但前提是服务端生成的每个事件都带 id，且逻辑上支持按 ID 查找后续数据。

服务端必须为每个事件分配唯一、有序的 ID

这是整个机制的前提。ID 不仅要存在，还要体现数据的全局顺序——比如数据库主键、时间戳毫秒值、或严格递增的整数序列。

• 用 ServerSentEvent(id=...) 显式设置，不能依赖默认行为
• ID 类型建议统一为字符串（SSE 规范要求），即使数值也转成 str，避免解析歧义
• 示例：yield ServerSentEvent(data=item, id=str(event_seq))，其中 event_seq 是服务端维护的连续序号

服务端主动读取并校验 Last-Event-ID 请求头

FastAPI 中通过 Header() 获取该字段，注意它可能为空或非法格式，需做容错处理。

• 声明参数：last_event_id: str | None = Header(default=None, alias="Last-Event-ID")
• 转换时加 try/except，失败则视为首次连接，从头开始
• 不要直接用 int(last_event_id)，先 strip() 再判断是否数字，再转类型

根据 ID 定位起始位置，跳过已发送项

不是简单地 “+1”，而是要确保跳过所有 ≤ 该 ID 的历史事件。尤其在数据源非严格单调时（如多线程写入、分库分表），需结合时间戳或版本号二次校验。

• 若用自增 ID：查询 WHERE id > last_event_id ORDER BY id LIMIT ...
• 若用时间戳：查 WHERE created_at > last_timestamp，并补上 id > last_id 防重复
• 推送前可先检查是否存在下一条，避免空流导致客户端再次断连

客户端无需额外编码，但要注意几个隐性前提

EventSource 默认就带 Last-Event-ID，但它的行为依赖服务端输出是否规范。

• 每个事件块结尾必须是两个换行符 \n\n，否则浏览器无法正确解析 id 字段
• 避免在 event 或 data 行中混入非法字符（如未转义的换行），会截断解析
• 不要禁用浏览器默认重连（如设置 eventSource.close() 后又手动 new），会丢失 ID 上下文

今天关于《SSE断线重连带Last-Event-ID补发方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！