关键在于前端接收、解析、缓存和渲染四环节的协同优化：节流缓冲+批量dom更新、结构化json传输、硬性限流丢弃、连接生命周期精准管控。
处理海量 SSE 消息，关键不是让浏览器“吞得下”，而是让它“不卡、不崩、不积压”。瓶颈不在连接本身，而在前端如何接收、解析、缓存和渲染——这四个环节一旦失控，哪怕每秒只推 20 条，页面也可能明显卡顿或内存持续上涨。
节流缓冲 + 批量更新 DOM
高频 message 事件直接触发 DOM 操作，会引发连续重排重绘。必须把“接收节奏”和“渲染节奏”分开：
- 用
setTimeout或requestIdleCallback聚合短时间内的消息（如 50–100ms），攒够再统一处理 - 渲染时优先用
textContent替代innerHTML，跳过 HTML 解析与安全校验开销 - 大量列表类内容（如日志流、告警列表）改用虚拟滚动，只渲染可视区域，避免节点无限追加
- 数值型指标（QPS、延迟、在线数）直接复用已有 DOM 元素，仅更新
textContent或dataset
结构化传输 + 避免重复解析
SSE 默认是文本流，每条 data: 行都要被 EventSource 拆解、拼接、触发事件。高频下这部分开销不可忽视：
- 后端统一推送标准 JSON 字符串：
data: {"id":123,"cpu":72,"ts":1723556100}，前端一次JSON.parse()即可 - 省略非必要字段：无断续需求就去掉
id:和event:；retry:若固定值，只在首响应写一次 - 前端不校验格式：信任服务端输出规范，避免在
onmessage里做line.startsWith('data:')这类判断
硬性限流 + 主动丢弃旧数据
不设上限的缓冲区等于给内存埋雷。尤其在弱网或 UI 响应滞后时，消息会越积越多：
- 设置最大未处理消息数（如 200 条），超出后自动丢弃最老消息，或触发降级提示
- 对纯日志类场景，可启用滚动窗口：只保留最近 N 条，老数据直接移出数组而非
shift() - 使用
WeakMap关联 EventSource 与组件实例，避免强引用阻碍 GC 回收
连接生命周期精准管控
海量消息场景下，无效连接比慢连接更危险——它持续收数据却无法渲染，白白吃内存和带宽：
- 监听
document.visibilitychange，页面隐藏时立刻eventSource.close() - 路由切换/组件卸载时，务必在清理函数中显式关闭（React useEffect return，Vue onBeforeUnmount）
- 服务端配合：收到客户端断连信号（
res.on('close')）后，立即终止上游数据源（如 Redis 订阅、数据库游标） - 避免全局单例 EventSource；按业务维度封装工厂函数，支持按路径或标识精准启停
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
