Ru果你曾经在监控大盘里kan到那条几乎要把屏幕撑裂的折线，心里一定会冒出一个念头：这也太卡了！别急，本文把从后端到前端、从网络到内存的每一道拦路虎dou拆开来讲，帮助你把“亿级”变成“毫秒可视”。

不管是金融行情还是工业 IoT，一秒几万甚至几十万的新点dou会涌进来。直接塞进数组再喂给 ECharts，浏览器瞬间告罄——JS 堆爆炸、帧率跌到 1 FPS，这种体验谁受得了？

显示设备的像素有限：即便你拥有 4K 超高清屏，一条折线Zui多只Neng占据约 3840 个横向像素。

CPU 要逐点计算路径、光栅化、交互事件，点越多耗时越久。

内存占用呈线性增长，普通 Array 每个点大约 16 Byte，200 万点轻易冲破 30 MB。

实战经验：在我的项目里把原始 10 M 条记录抽到 150 k 左右，再交给 ECharts，页面响应时间从 7 s 降到不到 800 ms。

ECharts 本身不关心数据怎么来的，只要你给它一个数组就Neng画。但Ru果后端一次性返回 JSON，文件体积可Neng达到百兆，这不仅浪费带宽，还会让前端卡死在解析阶段。

SSE 天生支持文本流，每收到一行数据就触发一次回调。我们Ke以把后端查询结果切成若干块，每块只包含当前视窗所需的时间段，然后边收边画：

// 简化版 SSE 接收逻辑
const source = new EventSource;
let buffer = ;
source.addEventListener('message', e => {
    const points = JSON.parse; // 
    buffer.push;
    // 当缓冲区累计到一定数量或视窗变化时抽样并geng新图表
    if  {
        updateChart);
        buffer = ;
    }
});
source.addEventListener => source.close);

SSE 的好处是天然兼容浏览器，不需要额外握手；缺点是只Neng走文本协议，Ru果想省去 JSON 序列化成本，Ke以转向 WebSocket。

使用 ArrayBuffer / Float64Array 打包坐标对，一次发送几千个点只占几百 KB。后端直接把数据库游标转成二进制流推送过去：

const ws = new WebSocket;
ws.binaryType = 'arraybuffer';
ws.onmessage = ev => {
    const view = new Float64Array;
    const points = ;
    for  {
        points.push;
    }
    chart.appendData; // 增量渲染 API
};

技巧：配合 AbortController，当用户切换视窗或关闭页面时立即 abort，避免无用的数据继续占用带宽。

ECharts 从 v5 起提供了 progressiveRender:true/threshold:number 参数。当系列数据超过阈值时会分批绘制，每批只渲染一定数量的点，从而保持 UI 响应。

option = {
    series: 
};
chart.setOption;

对实时监控来说大多数曲线只在短时间内被查kan一次。我们Ke以把Yi经抽样好的结果写入 IndexedDB，下次打开同一时间段的页面时直接读取本地缓存：

// 写入
const store = db.transaction
                .objectStore;
store.put});
// 读取
const getReq = store.get;
getReq.onsuccess = e=> {
   const buf = e.target.result?.data;
   if  chart.setOption}]});
};

为什么推荐 Float64Array？因为它只是一层视图，底层存储在原生堆里不占用 JS 堆空间。相同数量的数据，用普通 Array 大约要消耗三倍以上的内存。

每日凌晨检查 IndexedDB 占用大小（)，超过阈值则删除Zui早的缓存。