简介基于ECharts技术打造的可视化大屏数据展示页面源代码由pink老师规划制作适合前端开发者、数据分析人员以及想快速搭建大屏展示场景的学习者。源码围绕图表展示、地图联动、页面自适应和交互动效等核心功能进行组织以网页形式呈现可直接运行或在其基础上修改有效降低数据大屏从零开始的搭建成本。压缩包共包含29个文件整体大小仅1.81MB主要文件包括网页结构页面、样式表、脚本文件、图表依赖库、地图数据、图片素材、数字字体以及说明文档与开源许可文件。各类文件分工明确目录结构清楚便于按需求取用和学习。目前已有1513人学习下载。通过学习可以掌握大屏页面中屏幕自适应、数据图表渲染、地图与统计图联动的常见做法同时借助附带的装饰图片、特殊字体和多个演示性小页面能够直观理解可视化大屏从布局设计到效果实现的完整流程。资源适合用于课程设计、毕业设计也可作为企业数据展示项目的前期模板和灵感参考。1. 可视化大屏不是“一堆图表拼在一起”而是一套完整的工程方案很多人拿到“基于ECharts技术的可视化大屏数据展示HTML源码”这类标题时第一反应是“这不就是几张图表叠在一个页面上吗”。实际上一个能稳定跑在展厅大屏、运营监控中心甚至会议室投屏上的可视化大屏远比“图表堆砌”复杂得多。它至少包含三件事用ECharts把数据映射成图表只是最基础的一层更关键的是布局、适配、数据更新策略以及长时间运行时的内存与DOM生命周期管理。ECharts 5.x 的按需引入、dataset组件、graphic元素配合CSS Grid布局与setOption的增量更新机制才是一个生产可用大屏的完整拼图。这篇文章适合已经会在官方示例里改option的开发者目标是让你能独立从零搭出一个在任意分辨率下不变形、数据实时刷新不卡顿的HTML大屏页面。HTML、CSS、JavaScript基础即可跟上但我会把边界和坑都标出来让熟手也能有收获。2. ECharts实例挂载在DOM上的最小HTML骨架2.1 为什么“先有DOM后有图表”是ECharts大屏的第一条铁律ECharts图表是渲染在canvas或svg上的而它必须有一个宿主容器。很多人踩的第一个坑是在页面加载完成前就执行echarts.init()拿到undefined然后控制台报“dom is null”。这个容器必须有明确宽度和高度ECharts不会自己撑开一个没有尺寸的div。在大屏项目中我见过太多人把init写进head的脚本里结果document.getElementById(chart1)还在解析之前直接报错。正确顺序永远是HTML结构存在且容器尺寸可计算然后初始化图表实例。在后续章节里所有适配方案都建立在这个基础上——init的时机决定了图表能否拿到准确的容器尺寸而这又决定了ECharts内部的坐标系计算是否正确。官方文档里echarts.init(dom, theme?, opts?)的三个参数第一个参数的DOM必须满足offsetWidth 0 offsetHeight 0这是硬条件。2.2 用一个git级别的最小示例把ECharts 5.x 跑起来下面是可视化大屏最常见的入口文件形式。没有框架没有构建工具直接双击打开就能看到图表这是 “HTML源码”这个词在从业者语境里最常见的含义。!doctype html html langzh-cn head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title运营可视化大屏 - ECharts入口/title style #chart-main { width: 800px; height: 600px; border: 1px solid #1e2a3a; background: #0f1923; } /style /head body div idchart-main/div !-- 生产环境建议下载到本地内网大屏经常没有外网权限 -- script srchttps://cdn.jsdelivr.net/npm/echarts5.4.3/dist/echarts.min.js/script script // 1. 拿到容器DOM const dom document.getElementById(chart-main); // 2. 初始化图表实例 const chart echarts.init(dom, null, { renderer: canvas }); // 3. 配置option并渲染 const option { backgroundColor: transparent, grid: { left: 60, right: 20, top: 40, bottom: 40 }, tooltip: { trigger: axis }, xAxis: { type: category, data: [2024-01, 2024-02, 2024-03, 2024-04] }, yAxis: { type: value }, series: [{ name: 访问量, type: line, data: [820, 932, 901, 1290], smooth: true, lineStyle: { width: 3 } }] }; chart.setOption(option); /script /body /html逻辑说明echarts.init(dom, null, { renderer: canvas })中第二个参数传null表示使用默认主题第三个参数里renderer指定渲染器。大屏场景下当页面中图表数量超过20个时canvas 比 svg 有明显性能优势因为 svg 会用大量 DOM 节点承载图形在数据更新频繁时更容易引发布局抖动。setOption传入一个符合 ECharts option 结构的普通对象图表内部会自动合并默认值并触发一次渲染。参数说明grid里的left/right/top/bottom是坐标系与容器边缘的距离大屏可视区通常较宽left适当加大可以避免 y 轴文字贴边。tooltip.trigger设为axis适合折线/柱状图联动提示设为item适合饼图、地图这类离散数据。写大屏时我习惯给series.lineStyle.width调大到2~3因为大屏被缩放到远处观看时太细的线条会几乎看不见。2.3 按需引入与全量引入的取舍上面的示例是全量引入echarts.min.js体积约1MBgzip后大约340KB。这在纯HTML源码场景下是合理选择——按需引入需要import语法和打包工具失去了“双击即开”的意义。但如果你在Vue3或ReactTS项目里做同样的事必然要换成按需引入import * as echarts from echarts/core; import { LineChart, BarChart, PieChart } from echarts/charts; import { GridComponent, TooltipComponent, LegendComponent } from echarts/components; import { CanvasRenderer } from echarts/renderers; echarts.use([LineChart, BarChart, PieChart, GridComponent, TooltipComponent, LegendComponent, CanvasRenderer]);因为我用的 ECharts 5.x 从 5.0 开始支持了这种 tree-shaking 式按需加载全量引入时那些用不到的地图、3D图表都会进入包体。这套逻辑在纯 HTML 里跑不通但在“可视化大屏数据展示HTML源码”这个标题下纯HTML是第一层交付物构建工程化是第二层演进。本文后续所有示例都建立在全量引用的基础上只要你不用echarts-gl的3D场景全量引用足够覆盖大屏里的折线图、柱状图、饼图、中国地图、仪表盘等常见图型。3. 用CSS Grid把1920×1080大屏拆成可复用的图表网格3.1 为什么Flexbox不适合搭大屏骨架大屏的视觉特征是“满”——铺满整个屏幕四个边角都有内容中间是核心图。Flexbox 擅长一维排列但大屏是典型的二维布局顶部标题栏通栏下方左右各若干个图表卡片中间可能还有一个大尺寸的中国地图或者3D效果的数据中心拓扑。用Flexbox 强行实现这种结构需要写嵌套的flex-direction: row和flex-direction: column代码冗余且改一处容易牵动全局。CSS Grid 天然是二维布局模型。一句话说清区别Flexbox 告诉你的是“这条轴上的元素怎么排”Grid 告诉你的是“这块矩形区域怎么切分”。可视化大屏需要的是切分。同时Grid 的fr单位让列宽随容器等比例变化这为后续的适配方案降低了复杂度——比如把整屏切分为一个12列的网格侧边栏占3列中间核心区占6列列宽自动按百分比伸缩。3.2 一套适用于绝大多数大屏的Grid模板先把布局骨架写在 HTML 里然后给每个 grid 子项分配区域。style .screen { width: 100vw; height: 100vh; display: grid; grid-template-rows: 64px 1fr 1fr 48px; grid-template-columns: repeat(12, 1fr); gap: 12px; padding: 12px; box-sizing: border-box; background: #0a1128; } .screen-header { grid-column: 1 / -1; grid-row: 1 / 2; background: rgba(20, 40, 80, 0.6); } .chart-box { background: rgba(16, 32, 64, 0.5); border: 1px solid rgba(64, 128, 255, 0.2); border-radius: 4px; padding: 8px; } .chart-left-top { grid-column: 1 / 4; grid-row: 2 / 3; } .chart-center { grid-column: 4 / 10; grid-row: 2 / 4; } .chart-right-top { grid-column: 10 / 13; grid-row: 2 / 3; } .chart-left-bottom { grid-column: 1 / 4; grid-row: 3 / 4; } .chart-right-bottom { grid-column: 10 / 13; grid-row: 3 / 4; } .screen-footer { grid-column: 1 / -1; grid-row: 4 / 5; text-align: center; color: rgba(255,255,255,0.6); font-size: 13px; } /style逻辑说明grid-template-columns: repeat(12, 1fr)把宽度切为12等份左侧图表占用1~4列3个fr宽度中间核心区占用4~10列6个fr宽度右侧占用10~13列3个fr宽度。grid-row: 2 / 4让中间图表跨两行是“中间大图、四周小图”经典结构的地基。gap: 12px是大屏卡片之间常见的呼吸感间距如果去掉间距多个图表贴在一起视觉上会糊成一片。这里有个容易忽略的细节padding: 12px必须配合box-sizing: border-box否则容器实际占用的空间会超过100vw/100vh触发滚动条。在大屏项目里滚动条就是一个严重的适配事故——它说明页面宽度溢出而溢出的部分在投屏时恰恰是最容易被裁掉的。3.3 图表卡片的统一封装函数大屏上的每个图表卡片都需要一个标题栏、一个图表容器以及对应的resize监听。我一般会写一个createChartBox函数来统一处理这些重复工作function createChartBox(container, id, title) { const box document.createElement(div); box.className chart-box; box.innerHTML div classchart-title${title}/div div id${id} stylewidth:100%;height:calc(100% - 32px);/div ; container.appendChild(box); const chart echarts.init(document.getElementById(id)); return chart; // 返回实例后续setOption用 }这个函数里最重要的参数是容器高度calc(100% - 32px)表示图表高度填满卡片剩余空间。如果改成固定高度比如300px在分辨率变化时就会多出留白或者溢出破坏了Grid布局的自动伸缩能力。标题栏高度按32px预留是权衡了标题字体大小和整体密度的相对通用值你可以按自己UI风格调整但图表区域一定要用calc或百分比避免固定高度。4. ECharts大屏适配方案scale等比缩放与resize双轨机制4.1 大屏不适合直接用响应式布局响应式的思路是“不同分辨率下改排版”而大屏项目通常有一个唯一定稿的设计分辨率最常见的是1920×1080。运营方的投放屏幕可能是1366×768的老旧电视也可能是2560×1440的会议室大屏甚至可能是竖屏拼接墙。如果用媒体查询在1366px下重新排列图表开发成本极高而且视觉上无法保持与设计稿一致。所以可视化大屏的主流做法是按设计稿像素精确排布然后用transform把整个页面等比缩放到实际屏幕大小。这也是热词“可视化大屏适配”背后真正的含义。和“响应式布局”相比等比缩放的核心优势是省心你只需要保证设计稿在1920x1080下完美呈现其他尺寸交给数学计算。4.2 transform: scale 方案的手写实现代码层面是最经典的“整体缩放”算法放到window.onresize里持续生效const DESIGN_WIDTH 1920; const DESIGN_HEIGHT 1080; function adaptScreen() { const scaleX window.innerWidth / DESIGN_WIDTH; const scaleY window.innerHeight / DESIGN_HEIGHT; // 取最小值保证长边不溢出短边允许留黑边 const scale Math.min(scaleX, scaleY); const screen document.getElementById(screen); screen.style.transform scale(${scale}); screen.style.transformOrigin left top; // 可选通过margin-top防止缩放后底部出现空白占位 // 但更干净的做法是让父容器 overflow: hidden } window.addEventListener(resize, adaptScreen); adaptScreen();逻辑说明scaleX和scaleY分别表示当前屏幕宽度、高度相对于设计稿的倍率。取Math.min是因为如果取Math.max短边方向会溢出屏幕页面底部或右侧会被裁掉。transformOrigin: left top保证缩放的中心点在左上角否则缩放会围绕元素中心发生导致页面偏移出屏幕。上面这段代码隐藏了一个坑如果window.innerHeight小于1080 * scale比如浏览器窗口高度被开发者工具占用页面就会在垂直方向留出空白。这是 scale 方案的固有边界——它无法填满非设计稿比例的屏幕。实践中我会在#screen外层再包一层div设overflow: hidden并把背景色设为黑色这样留白区域就是两个黑边视觉上完全可以接受。下面是一张不同分辨率下 scale 指标对照表方便你估算部署环境的影响目标屏幕分辨率scaleXscaleY实际scale输出尺寸留白方向1366×7680.7110.7110.7111366×768无1920×10801.01.01.01920×1080无2560×14401.3331.3331.3332560×1440无1280×10240.6670.9480.6671280×720上下留黑边3840×21602.02.02.03840×2160无注意第三行如果目标屏幕比例与设计稿不一致scale 只能取短边长边相对“溢出”于是视觉上靠上下或左右的黑边来容纳。这是大屏项目必须接受的妥协优点是图表比例完全不变形缺点是黑边不算好看。想要真正填满屏幕就要靠下面第 4.3 的双轨方案补救。4.3 ECharts自身resize事件与scale方案的配合transform缩放只能解决整个大屏的尺寸问题但有一个细节它管不到屏幕尺寸变化时ECharts 内部的canvas绘图尺寸不会自动跟随。假设你初始化图表时容器宽1000px屏幕缩小后 transform 把它视觉缩到800px但canvas内部的像素宽度仍是1000px。这会导致图表文字和线条在缩放后被“压扁”或“拉伸”出现字体模糊、线条发虚的问题。这就是为什么必须同时监听resize并调用 ECharts 实例上的resize方法// 在创建完所有图表实例后统一维护一个数组 const chartInstances []; // 注册每个图表 chartInstances.push(echarts.init(document.getElementById(chart1))); // resize时统一处理 window.addEventListener(resize, () { chartInstances.forEach(chart chart.resize()); });chart.resize()会重新读取容器当前实际宽高并重绘canvas。在纯HTML项目里这个调用必须在adaptScreen()之后执行因为adaptScreen()修改的是 CSS transform而chart.resize()读取的是布局尺寸。在页面加载和窗口大小变化时都调一次以避免初始化时因容器尚未完成布局导致的尺寸错误。4.4 大屏轮播页的定时器适配很多大屏是多个页面轮播的常见的做法是在setInterval里切换图表数据或切换整个页面显示。这种情况下resize事件处理和 scale 方案的联动有一个容易忽略的顺序问题切换页面后新页面的图表实例需要重新init但旧页面的实例如果还在chartInstances数组里调用chart.resize()时它可能已经dispose了会抛异常。建议养成两个习惯一是每次setOption前检查图表实例是否被 dispose二是切换轮播页时把chartInstances数组里对应的旧实例移除。省得在大屏长时间运行后控制台报一堆zrender相关错误引发内存泄漏。在生产大屏项目里稳定运行3天以上不会崩是基本要求。5. ECharts大屏数据接入的几种常见场景与踩坑记录5.1 静态数据源起步把真实数据塞进option上面示例里的数据是写死在option里的。真实大屏的第一步往往是“用一段假数据把UI跑起来”然后把假的data数组换成从接口或本地存储读到的真实数据。这里最需要注意的地方是setOption的数据覆盖范围。setOption默认是“合并式”的如果你第一次传入了一个 line chart 的 option第二次只传入{ series: [{ data: newData }] }ECharts 会保留原来的 xAxis、yAxis 配置只更新 series 的 data。这不是bug而是 ECharts 的增量更新机制。在大屏场景下非常有用因为数据刷新时你只希望更新数值而不是把整个图表重建一遍——重建会闪烁这是大屏展示绝对无法接受的。// 假设每5秒从后端拉一次最新的数据实际往往是WebSocket推送 setInterval(async () { const res await fetch(/api/realtime-metrics); const data await res.json(); // 第三个参数不是true就是增量合并 chart.setOption({ series: [{ name: 访问量, data: data.visits }] }); }, 5000);这里必须留意一个对应关系series数组里的对象是通过name字段或数组下标与旧 option 里的 series 做匹配的。如果新旧name不一致ECharts 会认为你新增了一个系列旧的系列会被保留于是图形出现重复叠加。大屏上最常遇见的“图表叠加了双层数据”就是这么来的。5.2 接口返回字段与dataset的映射在数据展示类项目里后端返回的 JSON 通常不是前端想要的格式。比如接口返回一个对象数组字段名是create_time、pv、uv而 ECharts 折线图需要 x 轴是日期、y 轴是 pv。我一般用dataset组件完成从原始数据到图表结构的一次性映射const remoteData [ { create_time: 2024-01-01, pv: 120, uv: 89 }, { create_time: 2024-01-02, pv: 200, uv: 120 }, // ...更多 ]; const option { dataset: { dimensions: [create_time, pv, uv], source: remoteData }, xAxis: { type: category }, yAxis: { type: value }, series: [ { type: line, encode: { x: create_time, y: pv } }, { type: line, encode: { x: create_time, y: uv } } ] };dimensions声明字段顺序series.encode指定哪一列映射到 x、哪一列映射到 y。这样做的好处是后端改字段名时只需要改dimensions的声明和encode的映射不用重写每一个 series。在大屏项目里后端接口字段变更非常频繁这个映射层能帮你节省大量的联调时间。5.3 WebSocket 推送下的内存与渲染调度真实大屏最常见的数据接入是 WebSocket 推送。后端每秒钟推一条数据上来你把数据推进一个滑动窗口比如只保留最近1分钟的60个点然后更新图表。这里最容易触碰的性能瓶颈是setOption的频率。ECharts 自己做了requestAnimationFrame级的合并渲染但在数据变化远大于帧率比如每秒30条推送时仍然会出现明显的 CPU 占用和掉帧。我的做法是引入一个“tick 缓存”模式后端推送的数据我先写进一个 buffer然后固定每2秒读取一次 buffer 并刷新图表。const buffer []; socket.onmessage (event) { const point JSON.parse(event.data); buffer.push(point); // 防止内存无限增长只保留60个 if (buffer.length 60) buffer.shift(); }; setInterval(() { if (buffer.length 0) return; chart.setOption({ series: [{ data: buffer.map(p p.value) }] }); }, 2000);buffer数组只保留最近60个点数据满了以后shift()移除最旧的这样图表呈现的是滚动窗口。2秒一次的刷新频率在视觉上是连续的但 CPU 负载比每秒30次setOption低一个数量级。实际场景里如果你发现大屏长时间运行后内存缓慢增长优先检查是不是addEventListener或setInterval没有清理其次检查echarts.dispose()是否在setOption前被误调用了。5.4 一个低调但致命的坑容器被隐藏或 display:none 后图表尺寸错乱在大屏里标签页切换、轮播、弹窗遮罩都可能导致图表的容器在某段时间内display: none或者尺寸为0。ECharts 在容器不可见时init或resize会拿到宽高为0的尺寸于是图表画不出来或者canvas变成一张透明的小图。等容器重新显示时如果不手动触发resize这个错乱的尺寸会被保留。解法是在容器可见的时候显式调用chart.resize()。如果你用的是 scale 适配方案容器始终可见只是transform了这个问题相对少见但如果你在项目里加入了 Tab 切换或手风琴效果就必须在切换逻辑里补一下 resize。大屏项目里这个问题会以“切回来图表空白”的形式出现且不报错排查起来非常隐蔽。6. 用graphic组件做动态角标与刷新标志大屏不仅是“数据展示”更多是“让人一眼看出数据正在流动”。做到这一点最省力的方式是graphic组件——它允许你在图表上叠加自定义图形元素比如更新时间、闪烁的原点、动态边框。代码思路是先把graphic配置进 option然后在定时器里通过chart.setOption更新graphic的文本内容const option { graphic: { type: text, right: 20, bottom: 20, style: { text: , fill: #7ec8e3, fontSize: 12 }, // 关键用setOption更新时需要保留这个id id: update-time }, // ... 其他series配置 }; function refreshUpdateTime() { const now new Date(); const text 更新于 ${now.getHours()}:${now.getMinutes()}:${now.getSeconds()}; chart.setOption({ graphic: { id: update-time, style: { text } } }); }注意graphic里的id字段必须显式声明否则setOption每次都会新建一个 graphic 元素旧的不会被移除时间文字周围会叠出残影。加id后ECharts 会按 id 匹配并复用已有元素只更新style.text这是增量更新的另一种表现形式。大屏进入稳定运行期后我最后会做一次验证打开浏览器开发者工具的 Performance 面板录制30秒确认没有超过50毫秒的长期任务同时打开内存快照确认setInterval的 callback 没有持续增长。大屏项目真正难的不是画出一张好看的图而是让它年复一年地挂在墙上不崩、不糊、不闪。本文还有配套的精品资源点击获取