ECharts智慧交通大屏源码实战：从数据模型到性能优化

简介：数据可视化是智能业务系统升级的重要基础，当信息需要承载到指挥中心大屏上时，多图表协同、秒级感知和数据稳定就成了关键。大屏不同于普通报表，它要求前端工程在有限屏幕内高效呈现车流趋势、区域拥堵与状态指标。ECharts作为Apache开源生态中的主流可视化引擎，以声明式配置和丰富地图能力成为这类工程的首选，其option结构让图表与数据源解耦。它支撑了LED拼接屏自适应、自动轮播等高利用率场景，同时帮助工程师简化了渲染层的维护成本，尤其适合智慧交通指挥中心等面向运维监控与调度决策的场景。本文围绕一套基于ECharts的智慧交通数据可视化大屏源码，拆解工程结构、option参数、定时刷新、数据归一化、性能体检等核心环节，为快速搭建同类可视化项目提供可复用的实践路径。

1. 基于ECharts智慧交通数据可视化大屏源码：先看懂它解决什么问题

交通指挥中心的大屏，和普通网页报表是两种东西：报表给人查，大屏给人扫。巡屏的人要在几秒内看出早晚高峰走向、哪条路堵了、有没有突发事故——这就是“基于ECharts智慧交通数据可视化大屏源码”这类工程要解决的：把车流量、拥堵指数、事件信息以分钟级刷新稳定压进一块高分辨率屏幕。它的技术栈很朴素，HTML加CSS加JavaScript加ECharts，不依赖前端框架，对后端转前端的开发者也友好。适合正在做智慧交通、园区监控、指挥中心可视化的人，也适合手头缺实战作品的前端求职者。我建议拿到源码先读数据模型，再抠图表配置，顺序反了容易翻车。下面就把这条路完整走一遍。

2. 从源码到大屏：数据模型、适配基线、加载顺序缺一不可

很多人在拿到这类大屏工程之后，第一件事就是直奔 charts 目录看 option。我的习惯相反，先按住不急着看图表，把 index.html 从头到尾读一遍，再把 data 目录的数据结构理清楚。原因很简单：大屏是多个图表同时在跑，任何一张图迟两秒渲染都看不太出来，但数据字段取错了，整个页面都会出现“有框没数”的尴尬状态。这一章先把工程骨架和数据流讲清楚。

2.1 技术选型：为什么 ECharts 能成为企业级数据可视化的默认答案

先回答一个绕不开的问题：图表库那么多，D3、AntV G2、Highcharts，为什么交通大屏普遍选 ECharts？

第一个理由是维护成本。ECharts 是 Apache 基金会下的开源项目，国内社区积累深，从 echarts 柱状图设置渐变色到 echarts 饼图中间的文字样式，遇到问题搜一下基本就有答案。做企业级数据可视化项目，最怕的不是功能不够，而是查不到坑在哪，ECharts 在这方面的文档和社区积淀目前还是最厚的。

第二个理由是声明式配置。ECharts 的 option 是一个纯 JSON 对象，图表结构、数据、样式全部由配置驱动。这意味着后端返回的数据只需要换算成 option 里的 series.data，不用去操作 DOM、不用管 Canvas 的绘制细节。大屏上同时挂十几个图表实例，每张图维护一份 option，逻辑非常直白，新人接手也能在半天内改明白。

第三个理由是地图生态。交通场景离不开“空间”这个概念：哪条路堵、哪个片区流量高、事故发生在哪个路口，都需要地图承载。ECharts 配合 GeoJSON 可以直接渲染省、市、区县地图，再叠加散点、热力、飞线，基本覆盖了智慧交通可视化大屏所有的空间可视化诉求。相比之下，D3 自由度高但上手和调试成本都偏高；AntV 系列在统计图表和关系图上很擅长，但通用地图这块的周边方案没有 ECharts 多。

当然，选型不是绝对的。如果项目对动画有极致要求，比如要做粒子车流、大范围飞线特效，那得自己写 Canvas；如果团队已经全面 Vue3 加 TypeScript，用 vue-echarts 封装会更顺手。但在“基于 ECharts 智慧交通数据可视化大屏源码”这种以稳定、快速交付为首要目标的项目里，ECharts 就是风险最低的默认答案。

2.2 拆解工程结构：数据层、渲染层、适配层各自管什么

拿一套最常见的 ECharts 大屏工程目录来说，它的分区方式很能说明问题：

traffic-screen/ ├── index.html # 大屏唯一入口：标题栏、时间、图表容器 ├── css/ │ ├── base.css # 全局重置、rem 根字号、字体基线 │ └── screen.css # 面板栅格、边框、标题装饰 ├── js/ │ ├── data/ │ │ ├── traffic.js # 静态兜底数据：道路、流量、事件 │ │ └── mock.js # 随机生成器：模拟路段流量波动 │ ├── charts/ │ │ ├── line.js # 车流时序折线图 │ │ ├── map.js # 路网/辖区地图 │ │ └── gauge.js # 拥堵指数仪表盘 │ ├── adapter.js # 监听 resize，按比例缩放页面根字号 │ └── screen.js # 大屏初始化：实例管理、统一刷新、销毁 └── assets/ └── geo/ └── city.json # 区县 GeoJSON，地图渲染底图

这套结构的核心思想是分层。data 目录只负责提供数据，不管图表长什么样；charts 目录只负责把数据翻译成 ECharts 的 option，不关心数据从哪里来；screen.js 作为总控，统一管理实例的创建、刷新和销毁；adapter.js 独立出去，是因为大屏最常见的维护需求就是换分辨率，单独成文件便于在不同项目之间复用。

进入页面后的执行顺序我一般这样安排：先由 screen.js 读取 data 目录拿到初始数据，再按顺序初始化各图表实例，渲染完成之后启动一个全局定时器统一刷新。这里有个容易被忽略的点：刷新不是每一张图各自 setInterval，而是由 screen.js 统一把控。这样做的原因在第四章详细说，简单讲就是避免十几个定时器互相抢资源，也方便页面离开时统一清理。

2.3 数据归一化：后端字段、静态数据、随机数据共用一种结构

交通大屏的数据来源通常很杂：有信号灯系统的过车数据、有地图服务商的拥堵指数、有事件工单，还有大屏演示时用来模拟的随机数。这些数据的字段风格完全不一样，有的叫 roadName，有的叫 road_name，有的直接给 id 让你自己关联。如果让图表代码直接对接这些原始字段，每换一个数据源就要改一遍 option，这是大屏项目里最大的维护隐患。

常见做法是在 data 层加一个归一化函数，把各种来源统一成内部结构：

// js/data/normalize.js const TRAFFIC_STATUS = { smooth: '畅通', normal: '正常', slow: '缓行', congested: '拥堵' }; export function normalizeTraffic(raw) { // raw 可能是后端接口、本地静态 JSON 或 mock 生成器的返回值 return { updateTime: raw.timestamp || raw.updateTime || Date.now(), roads: (raw.roads || []).map((item) => ({ // 统一字段名：不同数据源的 roadName / road_name / name 都映射到 name name: item.roadName || item.road_name || item.name || '未知路段', flow: Number(item.flow ?? item.vehicleCount ?? 0), avgSpeed: Number(item.avgSpeed ?? item.speed ?? 0), // 状态统一用英文枚举，图表层再映射成中文显示文本 status: TRAFFIC_STATUS[item.status] ? item.status : 'normal' })), events: (raw.events || []).map((ev) => ({ type: ev.type || 'info', location: ev.location || ev.address || '', time: ev.time || ev.createTime || '' })) }; }

这段代码的关键点是“兜底”。每个字段都写了多个候选来源，并且用?? 0这种语法保证缺失时不会直接抛错。大屏项目里数据源变更非常频繁，归一化函数就是那层缓冲垫，让上游怎么改都不至于牵动图表渲染逻辑。

对应的 mock 生成器，本质上只是换了一个数据来源，但输出结构必须一致：

// js/data/mock.js export function generateMockTraffic() { const roads = ['解放路', '滨江大道', '人民南路', '环城快速']; return { timestamp: Date.now(), roads: roads.map((name, i) => ({ name: name, // 用正弦波动加随机偏移模拟早晚高峰的流量变化 flow: Math.round(1800 + 1400 * Math.sin(Date.now() / 3600000 + i)), avgSpeed: Math.round(25 + Math.random() * 35), status: Math.random() > 0.7 ? 'congested' : 'normal' })), events: [] }; }

从这段能看到一个工程约定：真实接口的数据和演示用的 mock 数据，都必须经过 normalizeTraffic 洗一遍再交给图表层。这样图表代码从第一天起只需要认一种数据结构，后续接真实接口时不用改任何渲染逻辑。很多源码里把 mock 和正式数据混着写，最后删 mock 时误删了线上路径，这种低级问题就是没做归一化导致的。

3. 交通图表分工与 option 参数：折线、地图、仪表盘怎么各司其职

大屏上的图表不是越多越好，而是每一类图表都要对应一个明确的“信息任务”。在智慧交通场景里，我通常把图表分成三类：趋势类用折线和柱状图，负责“随时间变化”；空间类用地图加散点或热力，负责“在哪里”；状态类用仪表盘、饼图和进度条，负责“现在怎么样”。三类图表在 option 配置上的侧重点完全不同，下面逐个落地。

3.1 车流时序曲线：折线图的多 series 与渐变面积参数

先看最常见的 24 小时车流量曲线。这个图放在大屏中上方，作用是让巡屏的人一眼看出早高峰晚高峰出现过没有、峰值大致在几点。

// js/charts/line.js export function buildLineOption(seriesData) { // seriesData 是归一化后的 { hours: [...], flows: [...], speeds: [...] } return { backgroundColor: 'transparent', grid: { left: 40, right: 24, top: 40, bottom: 30 }, tooltip: { trigger: 'axis' }, legend: { top: 0, textStyle: { color: '#9fd8ff' } }, xAxis: { type: 'category', data: seriesData.hours, axisLine: { lineStyle: { color: '#3a5a7a' } }, axisLabel: { color: '#9fd8ff', fontSize: 12 } }, yAxis: [ { type: 'value', name: '车流量(辆/h)', splitLine: { lineStyle: { color: 'rgba(58, 90, 122, 0.3)' } }, axisLabel: { color: '#9fd8ff' } }, { type: 'value', name: '车速(km/h)', splitLine: { show: false }, axisLabel: { color: '#ffd166' } } ], series: [ { name: '车流量', type: 'line', smooth: true, showSymbol: false, lineStyle: { width: 2, color: '#00d4ff' }, // areaStyle 的线性渐变让曲线下方有层次，是大屏蓝调风格的常见处理 areaStyle: { color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [ { offset: 0, color: 'rgba(0, 212, 255, 0.35)' }, { offset: 1, color: 'rgba(0, 212, 255, 0.02)' } ]) }, data: seriesData.flows }, { name: '平均车速', type: 'line', yAxisIndex: 1, smooth: true, showSymbol: false, lineStyle: { width: 1.5, color: '#ffd166', type: 'dashed' }, data: seriesData.speeds } ] }; }

这里有几个参数值得专门说。smooth: true让折线变成曲线，避免早晚高峰的毛刺干扰判断；showSymbol: false是数据点密集时的关键配置，不然十几个小时刻度上每个点都画圆点，视觉上会很脏。areaStyle的渐变是很多精美大屏的视觉基础，浅色往下一收，能让曲线立刻有层次感，同样的写法也适用于 echarts 柱状图设置渐变色，只是方向通常从下往上。

双 y 轴的做法也很常见。车流量和平均车速量纲完全不同，挤在一根轴上总有一方被压平，所以第二根轴挂在 yAxisIndex: 1 上。左轴车流量、右轴车速，初版就这么定，后面再按实际数据分布微调刻度。还有一点容易漏：yAxis 数组形式声明后，series 里必须写 yAxisIndex，否则第二组数据会默认画在第一根轴上。

3.2 路网与辖区：GeoJSON 加载、visualMap 与 echarts 中国地图的边界

交通大屏几乎离不开地图。这里说的地图不一定是高德、百度这种带底图的 WebGIS，更多时候是 ECharts 配合 GeoJSON 绘制的“数据地图”——底图是行政区划边界，叠加车流量的视觉映射。echarts 中国地图的注册方式和区县地图完全一样，换的只是 GeoJSON 文件。

// js/charts/map.js import cityGeo from '../../assets/geo/city.json'; export function buildMapOption(districtData) { // districtData: [{ name: '东城区', value: 326 }, { name: '西城区', value: 278 }] echarts.registerMap('city', cityGeo); return { tooltip: { trigger: 'item', formatter: (p) => `${p.name}<br/>车流量：${p.value || 0} 辆/h` }, visualMap: { min: 0, max: 500, left: 10, bottom: 10, text: ['高', '低'], calculable: true, inRange: { // 蓝到黄的色带更适合暗色大屏底 color: ['#0b3d6d', '#1e88e5', '#ffd166'] }, textStyle: { color: '#9fd8ff' } }, series: [ { name: '区域车流量', type: 'map', map: 'city', roam: false, emphasis: { label: { show: true, color: '#fff' }, itemStyle: { areaColor: '#ffd166', borderColor: '#fff' } }, itemStyle: { areaColor: 'rgba(30, 136, 229, 0.25)', borderColor: '#3a5a7a' }, data: districtData } ] }; }

registerMap只需要执行一次，应该放在 init 之前，否则每次 setOption 都重新注册地图会造成短暂的空白闪烁。visualMap的 min 和 max 不建议写死，最好根据当前数据的最大值动态计算，不然数据量级变化后整张地图要么一片深蓝要么一片黄，失去了可视化意义。roam: false是我在无人值守大屏上的习惯——如果允许拖拽缩放，巡屏的人不小心动一下鼠标，地图视角就偏了，遥控器又不在现场，只能等下次刷新恢复。

另外要提醒的是：如果只需要展示某个区县，GeoJSON 文件越小越好。网上下载的全国地图 JSON 动辄几 MB，塞进大屏页面会让首次加载明显变慢。常见做法是先做一次坐标抽稀，只保留当前项目涉及的区县边界，然后对比简化前后的边界形状，只要轮廓可辨识就行。地图在投影转换后也会出现边界偏移，这个只能拿真实坐标点验证，属于“调试几次就顺了”的活。

3.3 状态面板：饼图中间文字、仪表盘色带与柱状图渐变

除趋势和空间，第三类是状态面板。这一块在智慧交通里代表拥堵指数、事故等级统计、各类型事件占比。不少读者搜 echarts 饼图、搜饼图中间的字，多半就是卡在这一步。

// js/charts/gauge.js export function buildGaugeOption(index) { // index 是 0~100 的拥堵指数 return { series: [ { type: 'gauge', startAngle: 210, endAngle: -30, min: 0, max: 100, progress: { show: true, width: 14 }, axisLine: { lineStyle: { width: 14, color: [ [0.3, '#13d8a8'], // 畅通段 [0.7, '#ffd166'], // 缓行段 [1, '#ff6363'] // 拥堵段 ] } }, pointer: { length: '55%', width: 4 }, detail: { valueAnimation: true, formatter: (v) => v.toFixed(0), color: '#fff', fontSize: 28, offsetCenter: [0, '65%'] }, data: [{ value: index }] } ] }; }

仪表盘的axisLine.color是一个二维数组，每一段是一个 [阈值, 颜色] 的组合，这是控制红黄绿分段的核心。detail.valueAnimation: true会让数字跳动变化，大屏上这个动效成本很低但观感提升明显。类似的还有饼图，它的高端做法不是默认的圆饼，而是环形饼图加中心文字。常见做法是在 series 里设置radius: ['55%', '70%']留出圆心，再用 title 子组件把总车流量放在圆心，或者用 graphic 组件填文字；label 的 formatter 也要单独配，防止外部标签互相遮挡。

柱状图的渐变逻辑和折线是同一种写法，把 itemStyle.color 设成一个 LinearGradient 即可，区别只是方向通常从下往上。需要提醒的是：渐变、阴影这类视觉参数会推高渲染开销，在大屏上别滥用。一个页面控制在两三处重点渐变就足够，大面积使用反而会让信息层级混乱，显得花哨但不专业。

4. 动起来的大屏：定时刷新、自动轮播与拼接屏自适应的工程做法

静态的大屏只能叫“展板”，动态的大屏才叫“可视化大屏”。这一章是落地过程中最容易写出“能跑但不好用”的代码的部分，我把刷新、适配、轮播三条线分开讲。

4.1 定时刷新：setInterval 与 setOption 的正确组合方式

一艘大屏上几十张图表，如果每张都各自设置自己的刷新定时器，后果就是刷新不同步、图表之间数据对不上，而且页面离开时忘记清定时器的话，内存直接泄漏。常见做法是只建一个全局定时器，用 screen.js 统一管理。

// js/screen.js const charts = []; let timer = null; function refreshAll() { const data = normalizeTraffic(fetchData()); // 每张图只更新 series.data，而不是整个 option charts.forEach(({ instance, update }) => { update(instance, data); }); } export function startScreen() { refreshAll(); timer = setInterval(refreshAll, 5 * 60 * 1000); // 5 分钟一次 } export function destroyScreen() { if (timer) clearInterval(timer); charts.forEach(({ instance }) => instance.dispose()); charts.length = 0; }

这里最重要的习惯是：更新用 setOption，但别把整个 option 传进去。ECharts 的 setOption 默认是增量合并，你只需要传变化的 series.data、变化的数字即可。如果每次都从零构建完整 option，图表会对整个 Canvas 重新计算布局和动画，刷新时你会看到明显的闪烁，这就是很多大屏“每 5 分钟闪一下”的病根。

刷新间隔的取值，要根据数据源来定，不是越快越好。下面是这个场景常用的参考区间：

低于 10 秒的刷新，一是没有实际决策价值，二是频繁 setOption 会占用渲染线程，反而让页面交互变得迟滞。要是真的需要秒级推送，优先考虑 WebSocket 主动推送，而不是让 setInterval 去轮询。

4.2 拼接屏与 rem 布局：大屏字体怎么设置、resize 怎么兜底

大屏的分辨率五花八门：单块屏可能是 1920×1080，拼接屏可能是 5760×2160，还有竖向屏、异形屏。如果所有尺寸都用 px 写死，换一块屏就要改几十处样式。常规做法是用 rem 做单位，以设计稿宽度为基准动态设置 html 根字号。

// js/adapter.js const BASE_WIDTH = 1920; // 设计稿宽度 const MAX_WIDTH = 5760; // 拼接屏上限 function setRootFont() { const width = Math.min(document.documentElement.clientWidth, MAX_WIDTH); const scale = width / BASE_WIDTH; // 根字号限制在 40~160px 之间，避免极端屏字体过大或过小 const fontSize = Math.min(160, Math.max(40, 100 * scale)); document.documentElement.style.fontSize = fontSize + 'px'; } window.addEventListener('resize', setRootFont); window.addEventListener('load', setRootFont);

CSS 里所有面板的宽高、内边距、字号都用 rem 表达，比如：

/* css/base.css */ html { font-size: 100px; } /* 基准值，运行时由 adapter.js 覆盖 */ .screen-title { font-size: 0.32rem; } /* 32px 起步的主标题 */ .panel-title { font-size: 0.18rem; } /* 面板标题 */ .panel-body { padding: 0.2rem; }

以根字号 100px 为基准，0.32rem 就是 32px，这样大屏字体怎么设置的问题就变成了“在 CSS 里写 rem，让 adapter 统一缩放”。这里有个技术点：大屏的 resize 事件其实不是必须响应的——很多会议室大屏分辨率是固定的，但浏览器打开时菜单栏、工具栏占据窗口，首次 load 计算往往不准确，所以 load、resize 两个事件都挂上，并且用 Math.min 和 Math.max 夹住缩放范围，防止 4K 屏上字体飞到看不清楚。

ECharts 实例本身还需要单独处理：调用 chart.resize() 让它重算 Canvas 尺寸。常规做法是在 adapter 里统一遍历 charts 数组，而不是每张图单独监听 resize。拼接屏的另一种做法是固定设计宽高后做 scale 缩放，用 CSS transform 整体缩放页面，这种做法省事但文字会发虚，我一般不推荐。

4.3 自动轮播与 tooltip 联动：让大屏自己“说话”

无人值守的大屏，不能指望有人拿鼠标去 hover 看 tooltip。所以工程里常做两件事：自动轮播 tooltip，或者让某张核心图表定时高亮数据项。

// js/charts/autoPlay.js export function setupAutoTooltip(instance, total) { let index = 0; const timer = setInterval(() => { // dispatchAction 是高亮和 tooltip 联动的关键接口 instance.dispatchAction({ type: 'showTip', seriesIndex: 0, dataIndex: index }); index = (index + 1) % total; }, 3000); instance._autoTimer = timer; return timer; }

用 dispatchAction 触发 showTip，比手动调用 tooltip 显示方法更稳定，而且会自动跟随 ECharts 内部的动画状态。这里要记住的是把定时器挂到实例对象上，一旦图表销毁，定时器也要清掉，否则数据更新时旧高亮状态会残留。轮播间隔 3 秒比较合适，太短看不清，太长没有存在感。

大屏里累计车流量、平均拥堵指数这类数字文本的滚动动效，不需要动用图表，CSS 的 transform 加 transition 就够。真正容易翻车的反而是数字的“跳动”——如果直接改 innerHTML，每次刷新都会从 0 跳到新值，观感很差。常见做法是保留上一次数据，在刷新时做增量变化，或者用 requestAnimationFrame 做一个缓动过渡。这种细节往往被人忽略，但它是大屏有没有“企业级”质感的分界线。

5. 智慧交通大屏的 5 个常见问题与排查思路：从黑屏到地图越界

这一章是真正的血泪经验。大屏项目调试周期短、现场环境杂，问题经常不是出在代码逻辑上，而是出在加载顺序、分辨率、地图数据这些容易被忽略的角落。

5.1 刷新后白屏或整页空白

现象：大屏打开时正常，运行几小时后整页变白，或者只有背景没有图表。

原因：最常见的是某个 JS 在定时器里抛异常，导致后续渲染中断。另一个高频原因是图表实例在某个分支里被 dispose 了，但定时器还在调用 setOption，ECharts 会直接报错并中断脚本。

解决：在定时器回调外层统一包 try/catch，记录一次异常就停掉定时器而不是继续空转。另外全局监听 window.onerror，把错误堆栈输出到控制台独立面板，大屏现场排查时这是唯一的后悔药。

// js/screen.js function safeRefresh() { try { refreshAll(); } catch (err) { console.error('[screen] refresh failed', err); clearInterval(timer); } }

5.2 地图只有边界线没有填充色

现象：地图渲染了，但只看到边界线，区域全是透明，没有颜色。

原因：有两类。一类是 GeoJSON 中区域 name 和 data 中的 name 对不上，visualMap 匹配不到数据，所以颜色落不到区域上。另一类是从网上扒下来的 GeoJSON 坐标单位不对，或者坐标系不是 WGS84，导致区域形状被压扁甚至无法填充。

解决：把 GeoJSON 的 properties.name 和 data 的 name 逐个对比，先做一次 console 输出排查。名称不一致就在数据层增加一个别名映射表。坐标系问题则用转换工具统一处理。作为避坑习惯，我在任何地图组件上线前都会先打印前两个区域的 name，确认过后再继续开发。这个问题在 echarts 中国地图上尤其常见，因为全国地图文件里的省市区名称经常带“省”“市”后缀，而业务数据里不带。

5.3 图表文字在拼接屏上模糊错位

现象：页面整体缩放看起来还行，但标题、刻度文字发虚，切到 4K 屏后 label 错位。

原因：根字号设置得太小、被浏览器最小字号下限卡住，或者 rem 的字体渲染在缩放时出现半像素，导致模糊。另一个常见因素是 Canvas 在 devicePixelRatio 大于 1 时，没有正确设置画布分辨率。

解决：ECharts 5 默认开启 devicePixelRatio 自适应，但如果发现模糊，可在初始化时显式传入：

// js/charts/init.js const chart = echarts.init(dom, null, { devicePixelRatio: window.devicePixelRatio || 1 });

对于 rem 布局，把根字号下限设高一点，比如最小 40px，并给 Canvas 容器一个明确宽度高度，避免百分比在拼接屏下被浏览器踩成小数。字号方面，正文至少 14px 物理像素起步，大屏观看距离通常在 3 米开外，太小了真的看不清。

5.4 长时间挂机后页面越来越卡

现象：大屏连续运行三四天，鼠标移动开始有迟滞，图表动画不流畅。

原因：基本就是内存泄漏。最常见的是 setInterval 没清、事件监听积压、ECharts 实例重复创建未 dispose。还有一类隐蔽的：每个刷新周期都在地图 series 里追加新的标记点，但没移除旧的，Canvas 上的图形节点越来越多。

解决：用 Performance 面板的 Memory 工具做两次 heap snapshot，相隔一小时，对比 dom node 数量和 JS heap 大小。如果 dom node 持续上涨，优先检查是否在某个地方偷偷 append 了节点。图表层在数据刷新时，优先使用 setOption 的 replaceMerge 来替换 series，不要每次 push 新的 series 项：

// 用 replaceMerge 让 ECharts 直接替换旧 series，而不是叠加 myChart.setOption( { series: [{ name: '车辆轨迹', type: 'scatter', data: newPoints }] }, { replaceMerge: ['scatter'] } );

这里replaceMerge是 ECharts 5 提供的能力，指定按 series 的 name 或 type 维度整体替换旧配置，能避免旧数据节点残留。不传第二参的 setOption 是增量合并，适合更新数值；但要替换整个 series 时，增量合并反而会变成叠加，这是地图点迹类图表的头号内存杀手。

5.5 tooltip 或 label 出了屏幕边界

现象：地图在左侧，鼠标移到最左侧区域时 tooltip 被屏幕裁掉一半，自动轮播高亮数据项时也一样。

原因：ECharts 默认 tooltip 跟随鼠标位置，但坐标计算只考虑了图表容器，没有考虑容器边缘距离。大屏很多图表靠近屏幕边缘，这个坑特别常见。

解决：给 tooltip 设置confine: true，让它在容器内被压缩而不是越界；再配合 position 函数手动修正基准坐标。对自动轮播的 showTip 场景，可以在 dispatchAction 之前判断当前 dataIndex 是否靠近容器边缘，是的话把 tooltip 的 position 改成另一侧。这个位置玄学我在两个项目里都踩过，最后统一用了 confine 加 position 函数双保险，再没有犯过同样的问题。

6. 上线前用 Performance 面板给大屏做一次体检：内存回落与渲染抖动的判断标准

开发机上看不出来的问题，往往要等到大屏连续跑几天才暴露。所以我现在养成了一个习惯：交付前不只看功能，还要用浏览器 Performance 面板做一轮体检，把大屏当成一个高可用的前台应用来验证。

体检步骤很简单。打开无痕窗口，进入大屏页面，Performance 面板里勾选 Memory 和 Rendering，录制 10 到 15 秒包含一次自动刷新的过程。录完先看三条线：FPS 是否稳定在 30 以上，CPU 占用在刷新后是否回落到低位，JS heap 是否有明显的锯齿状回落而不是一路爬升。如果 FPS 长期低于 30，优先排查是不是某张图表的动画帧数过高，或者 tooltip 的 trigger 设成了 axis 导致鼠标移动时频繁计算。如果 heap 只涨不落，基本可以断定有定时器或事件监听泄漏，回到第五章的 replaceMerge 思路检查。

另外一个验证点是断网场景。大屏现场网络不一定稳定，所以我都会把 data 层做成“先读本地缓存、再请求接口、接口失败用上一次数据兜底”的三级模式。验证方法是直接在 DevTools 里切到 Offline，观察定时刷新时页面是否保持上一次的数据而不是白屏。这个操作 5 分钟就能做完，但能避免交付当天因为现场网络抖动导致的大屏空窗。

最后一件事是建立回归基线。把第一次体检时的 FPS、内存数值截图存档，每次改动图表配置后重新跑一遍同样的录制流程，对比数值是否明显恶化。这个习惯救过我一次：某次只是给柱状图加了一层阴影，FPS 就从 55 掉到了 20，如果不上线前体检，现场跑两天必然被发现。ECharts 大屏的优化往往不是靠某一个大招，而是把阴影、渐变、动画这些视觉参数一个个压到合理范围。把自己当成那个要连续值守三天的人，很多问题在开发阶段就能避开。希望帮到你。

本文还有配套的精品资源，点击获取