SSE本身不原生支持暂停与恢复，需通过客户端关闭/重建EventSource并传递lastEvent-id、服务端据此断点续传来模拟；关键在于ID同步、连接管理及keep-alive保活。
SSE（Server-Sent Events）本身不原生支持暂停与恢复，因为它是基于单向 HTTP 长连接的流式通信机制，一旦连接断开就需重建。但可以通过客户端控制连接生命周期 + 服务端配合，模拟出“暂停/恢复”的体验。
客户端手动控制连接开关
核心思路是：暂停时主动关闭 EventSource 实例，恢复时新建一个，并携带上次接收的事件 ID（用于服务端断点续传）。
- 创建 EventSource 时，用 withCredentials: true 和自定义 header（如
X-Last-Event-ID）不方便，所以推荐靠 URL 参数或lastEventId属性传递断点位置 - 调用
eventSource.close()即可立即终止连接，不会触发重连 - 恢复时 new EventSource(url + '?lastId=' + lastId)，服务端据此从指定位置继续推送
- 监听
onerror时注意区分网络错误和主动关闭——可通过标记位（如isManuallyClosed）避免误触发自动重连
服务端按 last-event-id 恢复推送
HTTP 响应头中的 Last-Event-ID 是浏览器自动携带的（只要上一次响应中含 id: 字段），服务端可直接读取并定位数据源。
- Node.js（Express）示例：从
req.headers['last-event-id']获取断点 ID，查数据库或缓存中该 ID 之后的数据 - 若无该 header，说明是首次连接，从最新数据开始推；若有，则跳过已发送部分
- 每次推送事件时务必写入
id:字段（如id: 12345\n），否则浏览器不会更新lastEventId属性 - 避免服务端无限挂起：设置合理的超时（如 30 秒无活动则 close response），但 SSE 要求至少每 30 秒发一次空注释（
: keep-alive\n\n）防连接中断
封装成可暂停的 EventSource 类
把连接管理、ID 跟踪、重连逻辑封装起来，使用更接近“播放器”语义。
立即学习“Java免费学习笔记（深入）”；
- 暴露
pause()和resume()方法，内部维护source实例和lastEventId -
resume()时检查lastEventId是否有效，无效则当作新连接处理 - 监听
onmessage时自动更新lastEventId（event.lastEventId可读） - 可加一个
buffered标志，暂停期间将新消息暂存在内存队列，恢复后批量 emit（适合低频、需保序场景）
替代方案：考虑 WebSocket 或分页轮询
如果业务需要频繁暂停/恢复、双向通信或强可靠性，SSE 就不是最优选。
- WebSocket 支持
socket.pause()/socket.resume()（底层 TCP 流控），且天然双工 - 对实时性要求不高时，用带游标（cursor）的定时轮询（如
GET /events?cursor=123）更可控、易调试 - 混合方案：用 SSE 推送“有新数据”通知，再用 fetch 拉取完整内容，暂停/恢复只作用于通知通道
不复杂但容易忽略：SSE 的暂停本质是连接生命周期管理，关键在 client 端状态同步和服务端断点识别。做好 id 传递和连接清理，就能实现平滑的启停体验。
