WebSocket需心跳保活防代理断连，服务端应聚合推送数据，前端用setOption高效更新ECharts并校准时间戳。
WebSocket连接必须带心跳保活，否则Nginx默认60秒断连
生产环境里，90%的“连接突然中断”问题都出在代理层。Nginx、ALB、CDN等中间件默认对空闲长连接有超时限制（Nginx是proxy_read_timeout 60），而WebSocket握手后若无任何数据往来，连接会被静默关闭——前端onclose触发但无错误码，看起来就像“随机掉线”。
解决办法不是调大超时值，而是主动发心跳：
- 前端每30秒用
ws.send(JSON.stringify({type: "ping"}))发一次轻量心跳 - 服务端收到后立即回
{"type":"pong"}，不走业务逻辑链路 - 前端起一个定时器监控上次
pong时间，超45秒没响应就ws.close()并触发重连 - 避免在
onmessage里直接解析所有字段——先用if (data.type === "pong") return快速拦截
服务端推送前必须做聚合或节流，否则前端直接卡死
原始监控数据（如每毫秒上报一次CPU）如果原样推给前端，一个指标每秒可能产生1000条消息。浏览器来不及渲染，onmessage队列堆积，内存暴涨，最终页面无响应。
关键不是“推得快”，而是“推得准”：
- 服务端按指标维度+时间窗口聚合：例如
cpu_usage按500ms滑动窗口取均值，再推送 - 若用Spring Boot + Quartz，不要在
@Scheduled里直接broadcast()，改用ConcurrentLinkedQueue暂存，由单独线程按16ms节奏批量消费 - 前端收到消息后别急着更新DOM，先
queueMicrotask(() => render())或用requestAnimationFrame对齐刷新帧 - 对ECharts图表，优先调用
chart.setOption(option, {notMerge: false, lazyUpdate: true})，禁用动画（animation: false）
断线重连不能简单setTimeout(3000)，要指数退避
网络抖动时，如果所有客户端在同一时刻发起重连，会瞬间打爆服务端连接数和认证压力，形成“重连风暴”。你看到的WebSocket is already in CLOSING or CLOSED state错误，往往就是这个原因。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
真实可用的重连策略要带状态记忆：
- 记录已尝试次数：
let retryCount = 0 - 重连延迟 =
Math.min(1000 * Math.pow(2, retryCount), 30000)（上限30秒） - 每次重连失败后
retryCount++，成功则重置为0 - 加个随机偏移（±200ms）避免集群内客户端同步重连：
delay += Math.random() * 400 - 200 - 用户切到其他标签页时，暂停重连计时器（监听
document.hidden）
ECharts动态更新必须用setOption而非clear + setOption
很多人习惯在onmessage里写chart.clear(); chart.setOption(newOption)，这会导致图表闪烁、坐标轴重绘、动画重播——尤其在高频更新时，视觉干扰极大，且性能损耗翻倍。
正确做法是复用已有实例，只更新变化部分：
- 初始化时启用
renderer: 'canvas'（SVG在高刷下更耗CPU） - 用
chart.setOption({series: [{data: newData}]}, {notMerge: false})，让ECharts内部diff - 对折线图，用
chart.addData([[0, newValue]])追加单点，比全量替换高效得多 - 若数据源来自多个WebSocket连接，先在前端合并再统一
setOption，避免多次渲染触发
最易被忽略的一点：WebSocket消息里的timestamp字段必须和服务端系统时间严格对齐，否则ECharts的时间轴会错乱——建议服务端推送时附带server_time，前端用它校准本地时钟偏移。
