Flask+ECharts数据可视化大屏：多页面切换与实时渲染实战

简介这是一套基于Python与Flask框架构建的轻量级数据可视化大屏展示系统面向企业数据监控、业务分析场景也适合作为前端工程化实战练手项目。系统支持多页面切换与实时数据渲染内置数据看板、空气质量监测、计算机性能指标等模块可满足不同层级用户的展示需求。压缩包共24个文件约1.02MB包含6个png与1个jpg图片、4个py后端脚本、3个js与1个css前端资源、2个html页面、1个ttf字体、1个gif动图以及说明文档、README、LICENSE等目录结构清晰便于按模块查阅。目前已有103人学习下载。读者可从中获取完整的Flask后端与前端页面代码、图表渲染逻辑、实时数据推送思路以及附赠的前端工程化配置与样式库资源快速搭建并定制企业级可视化大屏。1. 从一份 Flask 大屏源码说起多页面切换与实时渲染到底怎么落地很多做企业数据监控的团队都遇到过这种尴尬前端用 ECharts 拼了几张图页面一刷新数据就断多页面之间跳转还得重新拉一遍接口最后交付时只能截图糊弄。这份基于 Python 和 Flask 的轻量级数据可视化大屏系统解决的正是这个场景——它把数据看板、空气质量监测、计算机性能指标拆成独立模块用 Flask 做后端路由与数据接口前端负责多页面切换和实时数据渲染整套代码可以直接本地跑起来也能部署到内网服务器做业务分析。它适合两类人一类是想找一个能改、能扩的数据可视化大屏底座的前端或全栈工程师另一类是需要快速搭出企业数据监控原型、又不想从零写 WebSocket 和定时器的开发者。下面我按「资源是什么、怎么跑、坑在哪」的顺序把这份源码拆开讲一遍。2. Flask 后端与多页面路由接口怎么设计才不返工2.1 为什么用 Flask 而不是直接静态 HTML数据可视化大屏如果只做静态展示纯 HTML 加 ECharts 就够了。但这份资源的核心价值在于「实时数据渲染」和「多页面切换」这两件事都绕不开后端。Flask 在这里承担三个角色一是提供页面路由让数据看板、空气质量监测、计算机性能指标各自有独立 URL二是提供 JSON 数据接口前端定时或按需拉取三是作为后续接入真实数据源的入口比如把模拟数据换成数据库查询或第三方 API。常见做法是每个模块一个蓝图Blueprint这样路由不打架后期加模块也不用动主文件。我一般会把数据接口统一放在/api/前缀下页面路由放在根路径前端通过fetch或axios调用。这样做的好处是当你把模拟数据换成真实数据时只需要改接口内部实现前端一行都不用动。2.2 多页面切换的路由组织方式多页面切换有两种实现路径一种是 Flask 渲染多个模板每个模板一个独立页面跳转时整页刷新另一种是单页应用SPA思路Flask 只提供一个入口模板前端用 JavaScript 控制视图切换。这份资源更偏向第一种因为它的模块划分清晰每个模块的图表配置差异较大独立页面反而更好维护。下面是一个典型的 Flask 路由组织方式我按这份资源的模块结构做了简化# app.py from flask import Flask, render_template, jsonify import psutil import random from datetime import datetime app Flask(__name__) # 页面路由三个模块各自独立 app.route(/) def index(): return render_template(dashboard.html) # 数据看板 app.route(/air) def air(): return render_template(air_quality.html) # 空气质量监测 app.route(/performance) def performance(): return render_template(performance.html) # 计算机性能指标 # 数据接口统一 /api/ 前缀 app.route(/api/dashboard) def api_dashboard(): # 模拟业务数据实际项目替换为数据库查询 return jsonify({ sales: [120, 200, 150, 80, 70, 110], visits: [300, 420, 380, 500, 460, 390], timestamp: datetime.now().strftime(%H:%M:%S) }) app.route(/api/air) def api_air(): # 模拟空气质量数据 return jsonify({ pm25: random.randint(10, 80), pm10: random.randint(20, 120), co2: random.randint(400, 900), timestamp: datetime.now().strftime(%H:%M:%S) }) app.route(/api/performance) def api_performance(): # 用 psutil 读取真实计算机性能指标 return jsonify({ cpu: psutil.cpu_percent(interval0.5), memory: psutil.virtual_memory().percent, disk: psutil.disk_usage(/).percent, timestamp: datetime.now().strftime(%H:%M:%S) }) if __name__ __main__: app.run(debugTrue, host0.0.0.0, port5000)这段代码的逻辑很直白页面路由返回 HTML 模板数据接口返回 JSON。psutil是 Python 的系统信息库cpu_percent(interval0.5)表示采样 0.5 秒内的 CPU 使用率这个参数不能设太小否则第一次调用会返回 0.0这是新手最容易翻车的地方。host0.0.0.0让服务监听所有网卡方便内网其他机器访问如果只想本机调试改成127.0.0.1即可。debugTrue仅用于开发生产环境必须关掉否则会暴露调试器。2.3 前端如何消费接口并做实时刷新前端部分的核心是「定时拉取 图表更新」。ECharts 实例创建后通过setOption更新数据而不是销毁重建。下面是一个数据看板页面的简化实现// static/js/dashboard.js // 初始化 ECharts 实例 const salesChart echarts.init(document.getElementById(sales-chart)); const visitsChart echarts.init(document.getElementById(visits-chart)); // 首次渲染 function fetchDashboard() { fetch(/api/dashboard) .then(res res.json()) .then(data { salesChart.setOption({ xAxis: { data: [周一, 周二, 周三, 周四, 周五, 周六] }, series: [{ data: data.sales }] }); visitsChart.setOption({ xAxis: { data: [周一, 周二, 周三, 周四, 周五, 周六] }, series: [{ data: data.visits }] }); // 更新时间戳显示 document.getElementById(update-time).innerText data.timestamp; }) .catch(err console.error(数据拉取失败:, err)); } // 每 3 秒刷新一次 fetchDashboard(); setInterval(fetchDashboard, 3000); // 窗口大小变化时重绘避免图表变形 window.addEventListener(resize, () { salesChart.resize(); visitsChart.resize(); });这里有几个参数值得注意setInterval的 3000 毫秒是刷新间隔实际项目要根据数据更新频率调整太短会给后端压力太长实时性不够。resize()必须绑定否则浏览器窗口缩放后图表会错位这是大屏项目的高频问题。fetch的.catch不能省接口挂了至少能在控制台看到原因而不是页面一片空白。3. 实时数据渲染的三种方案轮询、SSE 和 WebSocket 怎么选3.1 轮询方案的适用边界这份资源默认用的是轮询也就是前端定时调接口。轮询的优点是实现简单、兼容性好、后端不需要维护长连接缺点是实时性受间隔限制且会产生大量无效请求。对于计算机性能指标这种每秒都在变的数据3 秒轮询其实已经够用但对于空气质量监测这种分钟级变化的数据轮询反而浪费资源。我一般会按数据变化频率来选变化慢的用轮询变化快的用 SSE 或 WebSocket。轮询的另一个坑是「请求堆积」——如果接口响应时间超过轮询间隔会出现请求叠加页面数据乱序。解决办法是用setTimeout递归代替setInterval确保上一次请求完成后再发起下一次// 用递归 setTimeout 避免请求堆积 function pollDashboard() { fetch(/api/dashboard) .then(res res.json()) .then(data { // 更新图表逻辑同上 updateCharts(data); }) .catch(err console.error(err)) .finally(() { setTimeout(pollDashboard, 3000); // 上一次完成后才排下一次 }); } pollDashboard();这个改动的关键在finally无论请求成功还是失败都在完成后才安排下一次这样就不会出现多个请求同时在飞的情况。3.2 SSE 做单向实时推送如果数据只需要服务端推给前端SSEServer-Sent Events比 WebSocket 更轻。Flask 实现 SSE 需要返回一个生成器并设置正确的 MIME 类型# SSE 接口示例 from flask import Response import time, json, random app.route(/api/stream/performance) def stream_performance(): def generate(): while True: data { cpu: psutil.cpu_percent(interval1), memory: psutil.virtual_memory().percent, timestamp: time.strftime(%H:%M:%S) } # SSE 格式data: 内容\n\n yield fdata: {json.dumps(data)}\n\n time.sleep(2) return Response(generate(), mimetypetext/event-stream)前端用EventSource接收const source new EventSource(/api/stream/performance); source.onmessage function(event) { const data JSON.parse(event.data); // 更新性能指标图表 updatePerformanceChart(data); }; source.onerror function() { console.error(SSE 连接断开浏览器会自动重连); };SSE 的坑在于Flask 开发服务器默认是单线程的一个 SSE 连接就会占住一个 worker多个页面同时打开会卡死。解决办法是用threadedTrue启动或者上生产级 WSGI 服务器。另外SSE 不支持跨域携带自定义头如果前后端分离部署需要在 Flask 侧加 CORS 头。3.3 WebSocket 与 Flask-SocketIO 的取舍WebSocket 是全双工适合需要前端向后端发指令的场景比如切换数据源、调整刷新频率。这份资源没有强制用 WebSocket但如果要扩展成「可交互大屏」Flask-SocketIO 是常见选择。它的坑在于版本兼容Flask-SocketIO 对 Flask 版本和前端 socket.io 客户端版本都有要求版本对不上会一直报 400 错误。我一般会锁定版本比如 Flask-SocketIO 5.x 配 socket.io 4.x不要混用。三种方案的对比方案实时性实现复杂度后端压力适用场景轮询取决于间隔低中数据变化慢、兼容性要求高SSE高中低单向推送、性能指标流WebSocket最高高低双向交互、多客户端同步选型建议如果只是展示轮询和 SSE 足够如果要交互再上 WebSocket。不要为了技术而技术大屏项目稳定比炫技重要。4. 避坑与排查这份源码跑不起来时先看这几条4.1 端口被占用导致启动失败现象运行python app.py后报OSError: [Errno 98] Address already in use。原因是 5000 端口被其他进程占用常见于之前启动的 Flask 实例没关干净或者系统里有其他服务在用。解决办法先查占用进程Linux 用lsof -i:5000Windows 用netstat -ano | findstr :5000找到 PID 后杀掉或者直接改端口app.run(port5001)。我一般会在开发时固定用一个不常用的端口避免和系统服务冲突。4.2 psutil 读取指标返回 0 或报权限错误现象计算机性能指标页面 CPU 一直是 0或者内存读取报AccessDenied。原因是psutil.cpu_percent()第一次调用如果没有传interval会返回 0.0因为它需要两次采样才能计算差值。解决办法要么传interval0.5要么在程序启动时先调一次「预热」。权限问题多出现在 Linux 上读取磁盘或网络信息时需要用有权限的用户运行或者只读取当前用户可访问的指标。4.3 前端图表不显示或显示错位现象页面打开了但 ECharts 图表区域一片空白或者图表挤在左上角。原因通常是容器没有设置宽高。ECharts 初始化时需要容器有明确的width和height如果父元素是display: none或者高度为 0图表就渲染不出来。解决办法给图表容器设固定高度比如styleheight: 400px;或者在切换页面后手动调用chart.resize()。另一个常见原因是 JS 文件路径不对Flask 的静态文件默认在static/目录模板里要用url_for(static, filenamejs/dashboard.js)引用不要写死相对路径。4.4 多页面切换后定时器重复创建现象在数据看板和空气质量页面之间来回切换几次后接口请求频率越来越高浏览器越来越卡。原因是每个页面加载时都执行了setInterval但页面跳转时没有清除旧的定时器。如果是整页刷新旧页面的定时器会随页面销毁但如果是 SPA 式切换定时器会一直留在内存里。解决办法在页面卸载或视图切换时调用clearInterval或者把定时器统一管理切换时先清后建。我一般会在beforeunload事件里做清理虽然整页刷新时浏览器会自动回收但养成习惯能避免很多玄学问题。4.5 部署到服务器后接口 404 或静态资源加载失败现象本地跑得好好的放到服务器上页面能打开但图表没数据控制台报 404。原因通常是反向代理配置问题比如 Nginx 把/api/路径转发到了错误的后端端口或者 Flask 的APPLICATION_ROOT没设置对。解决办法先确认 Flask 服务本身能通过curl http://127.0.0.1:5000/api/dashboard返回数据再检查 Nginx 的location配置。静态资源 404 多半是url_for生成的路径带了前缀而 Nginx 没做对应转发。这类问题没有后悔药只能一层层排查从后端到代理到浏览器控制台。5. 进阶技巧把模拟数据换成真实数据源并做接口缓存5.1 接入真实数据源的两种方式这份资源的默认数据是模拟的实际项目里数据来源无非两类数据库和外部 API。数据库场景下我一般用 SQLAlchemy 做 ORM把查询结果转成 JSON 返回。外部 API 场景下用requests拉取后做字段映射。无论哪种都建议在接口层加一层缓存避免每次请求都打数据库或外部服务。# 带缓存的接口示例 from flask import jsonify import requests import time _cache {data: None, expire: 0} app.route(/api/air/real) def api_air_real(): now time.time() # 缓存 30 秒 if _cache[data] and now _cache[expire]: return jsonify(_cache[data]) try: # 假设从某个环境监测 API 拉取 resp requests.get(https://api.example.com/air, timeout5) data resp.json() _cache[data] data _cache[expire] now 30 return jsonify(data) except requests.RequestException as e: # 外部接口挂了返回缓存旧数据或默认值 if _cache[data]: return jsonify(_cache[data]) return jsonify({error: str(e)}), 503这段代码的关键是「缓存 降级」30 秒内重复请求直接返回缓存外部接口超时或报错时返回上一次的数据而不是让页面空白。timeout5必须设否则外部接口卡住会拖死整个 Flask 进程。缓存时间根据数据更新频率调整空气质量这类数据 30 秒到 1 分钟都合理。5.2 用 Flask-Caching 做更规范的缓存手写字典缓存适合小项目模块多了会乱。Flask-Caching 是更规范的选择支持内存、Redis 等多种后端from flask_caching import Cache cache Cache(app, config{CACHE_TYPE: simple, CACHE_DEFAULT_TIMEOUT: 30}) app.route(/api/dashboard/cached) cache.cached(timeout30) def api_dashboard_cached(): # 耗时查询逻辑 return jsonify(query_database())CACHE_TYPEsimple是内存缓存适合单进程开发生产环境多 worker 时要用 Redis否则每个 worker 各存一份缓存命中率上不去。timeout参数和手写方案里的过期时间是一个意思按数据特性设。5.3 验证实时渲染是否真的生效改完代码后怎么确认实时渲染在工作我一般用三步验证第一步打开浏览器开发者工具的 Network 面板看接口是不是按设定间隔在请求第二步手动改一下后端返回的数据比如把 CPU 值写死成 99看页面是否在下一个刷新周期更新第三步用curl直接调接口确认返回的 JSON 结构和前端解析逻辑对得上。这三步走完基本能排除「看起来在动其实是静态图」的假象。从那以后我每次拿到一份大屏源码都强制先跑通「接口返回 → 前端渲染 → 定时刷新」这条链路再去看样式和布局。因为样式可以慢慢调数据链路断了整个项目就是一张会动的壁纸。希望帮到你。本文还有配套的精品资源点击获取