实现断点续推需服务端识别last-event-id并为每个事件分配唯一有序字符串id，客户端eventsource自动携带该id；服务端校验请求头、容错处理，并按id精准定位后续数据起始位置。

关键在于服务端能识别并响应 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 上下文