last-event-id 是浏览器在 sse 异常断连重连时自动携带的请求头，服务端据此恢复消息；需服务端持久化事件 id 与内容、客户端用 eventsource 并确保每条消息含 id 字段。
在 SSE（Server-Sent Events）中，Last-Event-ID 是客户端自动携带的请求头（如 headers: { 'Last-Event-ID': '123' }），服务端可据此判断客户端最后收到的事件 ID，并从该 ID 之后重新推送未接收的消息。但要注意：浏览器只在连接异常断开并自动重连时才发送 Last-Event-ID；手动关闭连接或首次连接不会带此头。因此恢复机制需服务端主动维护消息历史 + 客户端配合重连策略。
服务端需持久化事件 ID 和消息
SSE 本身无内置消息存储，要支持断线续传，必须在服务端记录已发出事件的 ID 及内容（至少保留最近若干条，或按时间窗口缓存）。常见做法：
- 用内存 Map / Redis 存储：key 为用户/连接标识（如 session ID 或 token），value 为按时间排序的事件队列，每条含
id、data、timestamp - 事件 ID 建议用单调递增数字或 ISO 时间戳（避免重复），例如
id: Date.now()或id: ++seq - 每次发送事件前，显式写入
id: xxx字段（否则浏览器不更新 Last-Event-ID）
解析 Last-Event-ID 并截取后续消息
Node.js（Express）示例逻辑：
app.get('/events', (req, res) => {
const lastId = req.headers['last-event-id'];
const clientId = req.query.token || generateClientId();
// 设置 SSE 必需响应头
res.writeHead(200, {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive',
});
// 若有 Last-Event-ID，从该 ID 后一条开始推送历史消息
if (lastId) {
const history = getMessagesAfterId(clientId, lastId); // 自定义函数：查出 id > lastId 的消息
history.forEach(msg => {
res.write(`id: ${msg.id}\n`);
res.write(`data: ${JSON.stringify(msg.data)}\n\n`);
});
}
// 后续新消息通过流式写入（如监听数据库变更、消息队列等）
const onNewMessage = (msg) => {
res.write(`id: ${msg.id}\n`);
res.write(`data: ${JSON.stringify(msg.data)}\n\n`);
};
subscribeToMessages(clientId, onNewMessage);
req.on('close', () => {
res.end();
});
});
客户端需启用自动重连并确保 ID 可靠
前端 JavaScript 要让浏览器触发 Last-Event-ID 行为，必须：
- 使用原生
EventSource（它会自动重连，默认 3s 间隔）；不要用 fetch + 手动读取流 - 确保每个事件都带
id:字段（哪怕只是数字序号），否则 Last-Event-ID 不会更新 - 避免调用
eventSource.close()后又立即新建 —— 这属于“主动断开”，浏览器不发 Last-Event-ID；应让连接自然断开或设置retry:字段 - 可选：在 onerror 中检查 readyState，区分网络错误和业务关闭
补充说明：ID 不是全局唯一，而是连接粒度
Last-Event-ID 是按单个 EventSource 实例维护的，不是跨页面/跨标签共享。如果用户打开多个标签页，每个都有独立的重连序列和 Last-Event-ID。若需多端同步，需额外设计：比如用用户 ID 替代连接 ID 做消息归属，或结合 WebSocket + SSE 混合方案做状态协调。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
