实现断点续推需服务端识别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 上下文
