sse通过id字段和last-event-id实现断线重连增量恢复：服务端需发送单调有序的id，浏览器自动携带last-event-id，服务端据此推送后续事件，并配合兜底策略应对id丢失。
SSE（Server-Sent Events）本身支持通过 id 字段实现断线重连后的增量恢复，关键在于服务端正确发送带 id 的事件，并在客户端保存最后收到的 ID；重连时浏览器会自动在请求头带上 Last-Event-ID，服务端据此返回后续数据。
服务端必须按规范发送 id 字段
SSE 协议要求每条事件消息可选包含 id: 行，且该值必须是合法字符串（不能含换行），用于标识该事件的唯一序号。服务端应确保：
- 每个事件块（以空行分隔）中，
id:出现在data:、event:等字段之前或之后均可，但需独占一行 - ID 应具备单调递增或严格有序性（如时间戳、自增整数、有序 UUID），避免重复或乱序
- 示例响应片段：
event: message
data: {"content":"hello"}
id: 12346
event: message
data: {"content":"world"}
客户端无需手动读写 Last-Event-ID
浏览器内置机制会自动处理：只要 EventSource 实例曾成功接收过带 id 的事件，断线重连时就会在请求头中携带 Last-Event-ID。开发者无需手动设置请求头或保存 ID —— 这是浏览器原生行为。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 首次创建
new EventSource(url)时，请求不带Last-Event-ID - 若连接中断后重建实例（例如网络恢复），且此前已收到有效
id，新请求自动带上该 ID - 若页面刷新或实例被销毁，上次 ID 丢失，需服务端配合提供初始同步机制（见下一条）
服务端需根据 Last-Event-ID 做增量推送
服务端收到请求头中的 Last-Event-ID 后，应跳过已发送过的事件，只推送 ID 严格大于该值的新数据：
- Node.js（Express）示例：解析
req.headers['last-event-id']，查数据库或缓存中 > 该 ID 的记录 - 若 ID 不存在（如首次连接或 ID 过期），可返回历史最新 N 条作为兜底，或返回空并等待新事件
- 注意：ID 比较逻辑必须与服务端生成规则一致（如数值比较 or 字符串字典序）
补充：兜底策略应对 ID 丢失场景
页面刷新、强退或长时间离线会导致浏览器丢失最后 ID。此时可结合其他机制增强可靠性：
- 在 URL 中附加时间戳或游标参数（如
/events?since=1717023456），服务端优先用 URL 参数，其次 fallback 到Last-Event-ID - 客户端首次连接时，主动通过普通 HTTP 请求拉取一次最新快照（如最近 100 条），再建立 SSE 连接
- 服务端对 ID 设置 TTL，超过一定时间未见该 ID，则视为无效，返回全量或最近窗口数据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
