大屏轮播应通过WebSocket推送轻量指令而非原始数据，前端预加载缓存数据并增量更新图表，地图和桑基图需复用配置、禁用自动布局，轮播中断须双向同步暂停状态。
大屏轮播不是靠 setInterval 刷 setOption，而是靠 WebSocket 推送带时间戳的“轮播指令” + ECharts 异步加载数据后触发渲染。 直接轮询或定时强制重绘，会导致图表闪烁、内存泄漏、服务端压力陡增，且无法与真实业务节奏对齐。
WebSocket 怎么发轮播指令而不是原始数据？
轮播本质是“换场景”，不是“刷数字”。服务端不该推送一整套 option 配置，而应推送轻量指令，例如：
{"type": "switch-chart", "target": "sales-by-region", "duration": 5000}{"type": "scroll-data", "chartId": "hot-product-list", "offset": 1}{"type": "trigger-animation", "chartId": "radar-overview", "phase": "next"}
前端收到后，再按需调用 echarts.getInstanceByDom() 获取实例，执行 setOption() 或 dispatchAction()。这样既解耦了数据与视图逻辑，又避免了重复初始化图表实例。
ECharts 异步加载数据时怎么避免白屏或卡顿？
轮播过程中若等接口返回才渲染，必然出现空白或跳变。关键在预加载 + 缓存策略：
- 首次进入页面时，用
Promise.all([fetch('sales.json'), fetch('map.json'), fetch('radar.json')])并行拉取所有轮播页所需数据，存入window.__CACHE__或Map实例 - 每个图表组件内部封装
loadData(id)方法，优先读缓存；缓存未命中才发请求，并标记loading = true，显示骨架屏（非 loading 图标） - 使用
echarts.setOption(option, { notMerge: true, lazyUpdate: true })，配合chart.resize()防止窗口缩放时重绘冲突
注意：不要在 onmessage 回调里直接调 setOption 大量数据，先用 setTimeout(() => chart.setOption(...), 0) 让出主线程。
为什么轮播时地图（geo）和桑基图（sankey）容易卡死？
这两类图表初始化成本高，且依赖异步资源（如 GeoJSON、节点关系计算）。常见错误是每次轮播都重新 setOption 全量配置：
- 地图：把
geo配置抽离为全局复用项，series层只更新data；用chart.setOption({ series: [{ data }] }, { notMerge: false })替代全量替换 - 桑基图：预先计算好节点坐标与层级，存在缓存中；轮播时仅更新
links和nodes的 value 字段，禁用layout自动计算（设layout: 'none'） - 所有轮播图表启用
progressive: 500和progressiveThreshold: 3000，防止大数据量阻塞渲染
实测发现，未做优化的地图轮播，在 4K 大屏上单次 setOption 耗时可达 800ms；加缓存+增量更新后压至 60ms 内。
轮播中断（鼠标悬停/点击）怎么和 WebSocket 同步？
不能只在前端暂停 setInterval，否则服务端还在推指令，前端积压消息会导致恢复后连刷多页。必须双向同步：
- 前端发送
{"type": "pause-playback", "reason": "hover"}到 WebSocket，服务端记录该客户端状态，暂停向其推送轮播指令 - 恢复时发
{"type": "resume-playback"}，服务端从上次中断位置继续推送（需服务端维护 per-client 播放队列） - 若使用
socket.io，可用socket.join('playback-room')+io.in('playback-room').emit()实现分组广播，避免全量推送
这个环节最容易被忽略：很多项目只做了前端暂停，结果运维大屏多人同时操作时，一个鼠标悬停，其他人轮播全乱套。
