简介基于Python与Flask框架构建的轻量级数据可视化大屏展示系统面向企业数据监控和业务分析场景适合需要快速搭建可视化看板的开发人员与运维团队。系统支持多页面切换和实时数据渲染内置数据看板、空气质量监测、计算机性能指标等模块可覆盖经营总览、环境监测、IT基础设施运维等多种展示需求兼顾不同角色的关注重点。压缩包共24个文件以Python源码、前端HTML/CSS/JavaScript为核心辅以图表所需图片、字体、说明文档及附赠资源整体仅1.02MB结构紧凑、便于部署和二次开发。目前已有104人学习/下载。资源包含完整项目代码、目录说明、使用文档及前端工程化配套资源模块划分清晰既可作为学习Flask数据可视化开发的实战范例也能在此基础上扩展企业级看板功能实用性较强。1. 基于 Flask 的大屏系统为什么轻量级方案更适合企业数据监控做数据可视化大屏很多团队一上来就上重型方案要么是自研前端工程要么引入整套微前端架构结果项目还没跑起来人先被工程化的复杂度拖垮了。这个基于 Python 和 Flask 框架开发的轻量级数据可视化大屏系统恰恰走的是另一条路——用最小的依赖、最直接的模板渲染方式和清晰的路由结构把数据看板、空气质量监测、计算机性能指标这三类场景装进一个大屏框架里同时支持多页面切换和实时数据渲染适合企业数据监控和业务分析场景里那些“要能快速落地、可以改造、别太重”的需求。尤其对于做前端工程化实战项目的人来说这套系统的价值在于它把后端接口、数据推送、前端页面组织和部署串成了一条完整链路能直接当成一个练手甚至交付的底子。用什么不用什么取决于你要解决什么问题。这个项目的定位很明确——它不是要做一个大而全的可视化中台而是要提供一个能承载多页面、能接实时数据、部署时不折腾的轻量大屏容器。所以它的 Flask 选型、路由组织方式、实时数据渲染思路都是围绕“监控场景里数据要看得到、刷新要跟得上、页面要切得动”这三个核心诉求来的。下面从架构选型说起把这套系统的骨架和肉都拆开看一遍。2. 架构与选型Flask 做后端为什么实时渲染不用 WebSocket 也够用这个系统用 Flask 作为后端框架整体是一个典型的服务端渲染加前端模板工程化的结构。标题里明确写到了支持多页面切换和实时数据渲染这两个关键能力的实现方式决定了这个项目的形态和价值。2.1 Flask 的路由与页面组织多页面切换背后的工程化思维Flask 支持多个路由和视图函数这套系统把路由规划成几个明确的维度首页路由负责总览看板余下的路由按模块划分比如空气质量路由对应监测页面计算机性能路由对应指标页面。每一个路由返回一个独立的模板文件前端互相之间通过导航栏完成切换而不是做单页应用的客户端路由切换。这种组织方式的工程化意义在于第一页面之间天然隔离开如果某个页面渲染出错不会影响其他页面第二模板文件按功能模块拆分后续维护和扩展新页面时改动范围可控第三服务端渲染天然利于首次加载页面打开就是完整的数据结构不会出现客户端一帧一帧白屏的问题。常见的做法是使用 Flask 的 Blueprint 来管理模块路由这个项目如果按常规工程结构组织通常也会包含蓝图、模板、静态资源、数据文件四个主要目录。from flask import Flask, render_template from air_quality import air_bp from performance import perf_bp app Flask(__name__) app.register_blueprint(air_bp, url_prefix/air) app.register_blueprint(perf_bp, url_prefix/perf) app.route(/) def index(): # 首页数据看板汇总各模块关键指标 summary get_summary_data() return render_template(dashboard.html, datasummary) if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)这段代码体现了这个系统的一个核心设计通过蓝图的注册把不同模块的路由挂在不同的前缀下。这样做的直接好处是 URL 语义化/air开头的路由一定属于空气质量模块/perf开头的路由属于性能模块。新增一个模块时只需要写一个新的蓝图文件在app.py里注册进去不用改动已有模块的任何代码。url_prefix参数看起来只是个路径前缀实际上是把模块目录和路由绑定起来的工程手段多页面系统的扩展性就是靠这种结构撑起来的。模板侧采用 Flask 自带的 Jinja2 引擎。页面框架通过模板继承实现基础模板定义页面头部、侧边栏导航和 CSS/JS 的引入位置各页面模板只写自己特有的区块内容。!-- base.html 骨架 -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title{% block title %}数据大屏{% endblock %}/title link relstylesheet href{{ url_for(static, filenamecss/common.css) }} {% block head %}{% endblock %} /head body nav classsidebar ul lia href{{ url_for(index) }}总览看板/a/li lia href{{ url_for(air_quality.index) }}空气质量/a/li lia href{{ url_for(performance.index) }}性能监控/a/li /ul /nav main classcontent {% block content %}{% endblock %} /main {% block scripts %}{% endblock %} /body /html模板继承不是这个项目的花架子。在实际的数据大屏页面中多个页面都会有同样的侧边栏、同样的图表库引入、同意的公共样式。如果每个页面都把这一套重复写一遍改一个导航链接就要动所有页面模板。基础模板把公共部分固定住子模板只填写content区块和页面特有的scripts区块这相当于前端工程化里“公共组件抽取”的思路只是落点在 Jinja2 模板层。新手看这个项目时建议先理解block和extends的配合方式这是整个多页面系统的骨架理解了模板继承后面的页面切换、公共资源管理、个性化脚本注入就全通了。2.2 实时数据渲染的两条路径轮询与消息推送的取舍所谓实时数据渲染在这个项目里实际上有两种实现路径。第一种是前端定时轮询页面里的 JavaScript 每隔若干秒向后端接口请求一次最新数据拿到后更新图表和数字组件。第二种是后端主动推送通过 WebSocket 或 SSEServer-Sent Events把数据变化推送到前端前端被动接收并渲染。这套系统选择的是第一种即轮询方式原因很实际Flask 原生的开发服务器和大部分生产部署方案比如 Gunicorn对 WebSocket 的支持都不够直接要上 WebSocket 就得引入额外的事件循环库和部署层配置复杂度会明显上升。而轮询方式只需要后端暴露一个普通的 JSON 接口前端用setInterval定时拉取对部署环境没有任何特殊要求Apache 和 Nginx 都能直接代理不需要额外的连接升级协议。提示如果项目里出现的实时数据更新频率高于每秒一次或者数据量大到轮询会产生明显网络压力才需要考虑切到 WebSocket。大多数企业监控场景下刷新间隔在 2 到 15 秒之间轮询完全够用这也是这个项目在实时性上做取舍的基本逻辑。// 前端轮询读取空气质量数据 function loadAirQuality() { fetch(/api/air_quality) .then(response response.json()) .then(data { document.getElementById(aqi-value).innerText data.aqi; updateChart(aqi-trend, data.history); // 更新趋势图 }) .catch(err { console.warn(数据拉取失败保留上一次渲染结果, err); }); } // 每 5 秒拉取一次 setInterval(loadAirQuality, 5000); loadAirQuality(); // 页面打开立即拉取一次避免白屏等待这段代码的细节值得展开。setInterval(loadAirQuality, 5000)是核心它决定了数据更新的频率。页面打开时先手动调用一次loadAirQuality()是为了让页面第一时间拿到数据不用干等第一个 5 秒周期。catch分支里保留上一次渲染结果这是一个非常有经验的细节——监控页面最忌讳的是后端一次偶发超时前端就把图表清空变成空白这会让值班的人误以为系统出了故障。所以正常处理方式是数据拉取失败了先保留旧数据后端恢复后自然会把最新值覆盖上去。接口设计上后端要做的就是查数据、拼 JSON、返回给前端。这里有一个需要认真对待的点接口设计要考虑返回结构的一致性。from flask import jsonify import sqlite3, json, time def query_latest_and_history(table, minutes60): # 读取最近一条数据和最近 n 分钟的历史数据用于大屏数字和趋势图 conn sqlite3.connect(sensor_data.db) conn.row_factory sqlite3.Row latest conn.execute( fSELECT * FROM {table} ORDER BY timestamp DESC LIMIT 1 ).fetchone() history conn.execute( fSELECT timestamp, value FROM {table} WHERE timestamp ? ORDER BY timestamp ASC, (time.time() - minutes * 60,) ).fetchall() conn.close() return { latest: dict(latest), history: [{time: row[timestamp], value: row[value]} for row in history] } app.route(/api/air_quality) def api_air_quality(): # 返回结构化数据latest 给大屏数字history 给 ECharts 趋势图 return jsonify(query_latest_and_history(air_data))注意这里返回的结构分成了latest和history两部分这是做可视化大屏时很常见的做法。latest对应大屏顶部的当前数值history对应图表区域的历史趋势曲线。一次请求同时返回这两种数据前端就不用再发第二个请求了。如果只返回最新值趋势图就没法画如果只返回历史数据大屏上的大数字就没办法即时刷新。把两者合在一个接口里是数据大屏接口设计上少走弯路的关键习惯。2.3 图表渲染选型为什么大屏项目普遍采用 ECharts前端的图表渲染部分常规路径是引入 ECharts 这类成熟的图表库。在基于模板渲染的 Flask 项目里ECharts 以静态资源的方式引入模板页面对应位置先放一个指定高度和宽度的容器div在页面脚本中针对这个容器初始化图表实例然后调用setOption填入数据和样式配置。图表这种组件选型的核心不是功能多少而是文档熟不熟、社区案例多不多。ECharts 的优势在于配置项覆盖率高到离谱——折线图、柱状图、面积图、仪表盘、散点图、地图几乎大屏里的图表类型都能直接找到官方示例而且配置项的写法十几年没大变过。对于做实战项目的开发者来说这意味着踩坑时能搜到大量现成案例不需要从零摸索。!-- 空气质量页面折线图容器 -- div idaqiChart stylewidth:100%; height:400px;/div script src{{ url_for(static, filenamejs/echarts.min.js) }}/script script var chart echarts.init(document.getElementById(aqiChart)); function renderTrend(history) { chart.setOption({ tooltip: { trigger: axis }, xAxis: { type: category, data: history.map(p new Date(p.time * 1000).toLocaleTimeString()) }, yAxis: { type: value }, series: [{ type: line, smooth: true, data: history.map(p p.value) }] }); } /script这段代码有个值得留意的点history.map()做了两次一次把时间戳转成toLocaleTimeString()字符串作为 X 轴类别一次把数值取出来作为 Y 轴数据。这种处理方式避免了在前端循环里做复杂的数据变换。实际项目中如果后端返回的时间戳本身已经是格式化好的字符串这一步可以省掉。但保持前端数据的可变通性是个好习惯——后端数据格式你不一定能完全控制前端做轻量映射比改后端要快得多。到这里一个多页面、带实时数据刷新、有图表渲染能力的大屏系统主干逻辑已经通了。下面拆开具体看数据和业务模块的实现细节这部分才是这个项目真正有含金量的地方。3. 数据模块拆解空气质量与计算机性能指标的数据采集和展示逻辑从数据来源看这个系统涉及两类数据一类是空气质量的监测数据另一类是计算机的性能指标这两类数据的特性不同决定了它们在采集频率、存储方式、展示侧重上都有各自的套路。整个项目的数据组织方式相当于是“不同领域的数据用同一种架构承载”的示范。3.1 空气质量模块从数据采集到 AQI 展示的闭环空气质量监测的核心指标包括 PM2.5、PM10、二氧化硫、二氧化氮、臭氧、一氧化碳等。这个模块在数据层面做的事情是把这些指标采集到之后落库、聚合、展示。它既要有“当前这一刻的空气质素读数”又要有“过去一小时的变化趋势”。# air_quality/collector.py —— 模拟传感器数据生成器 import random import sqlite3 import time def generate_air_sample(): # 生成一组模拟空气质量数据正常情况下这里是从传感器硬件读取 return { pm25: round(random.uniform(5, 150), 1), pm10: round(random.uniform(10, 250), 1), so2: round(random.uniform(1, 50), 2), no2: round(random.uniform(5, 80), 2), o3: round(random.uniform(20, 180), 2), timestamp: time.time() } def insert_sample(db_path../data/sensor_data.db): conn sqlite3.connect(db_path) sample generate_air_sample() conn.execute( INSERT INTO air_data (pm25, pm10, so2, no2, o3, timestamp) VALUES (?, ?, ?, ?, ?, ?), (sample[pm25], sample[pm10], sample[so2], sample[no2], sample[o3], sample[timestamp]) ) conn.commit() conn.close() return sample这个模拟生成器的意义在于它让整个系统在没有真实传感器硬件的条件下也能完整跑起来。做前端工程化实战项目的人遇到的最大阻碍往往是“有页面没数据”演示时图框架空着什么效果都看不出来。有了模拟数据层大屏的展示逻辑、接口逻辑、刷新逻辑全部可以正常运转等接入真实传感器时只需要替换generate_air_sample函数内部的实现数据链路完全不用动。空气质量指数的换算系数是另一个值得说清楚的细节。AQI 的数值并不是原始浓度直接展示而是按照标准限值做分段线性插值换算出来的。PM2.5 浓度 35 微克对应 AQI 5075 微克对应 AQI 100超过 250 微克对应 AQI 300 以上。换算逻辑属于环境监测领域的标准算法项目里如果写到这一层通常是单独的一个换算函数不应该散落在页面代码中。# air_quality/aqi_calculator.py —— AQI 分段线性换算 def calc_aqi_pm25(concentration): # PM2.5 的 AQI 换算分段表浓度段与对应 AQI 段 breakpoints [(0, 35, 0, 50), (35, 75, 50, 100), (75, 115, 100, 150)] for c_low, c_high, aqi_low, aqi_high in breakpoints: if c_low concentration c_high: # 线性插值公式(实际浓度 - 浓度下限) / (浓度上限 - 浓度下限) * AQI区间跨度 AQI下限 return round((concentration - c_low) / (c_high - c_low) * (aqi_high - aqi_low) aqi_low) return 500 # 浓度超过上限直接判为重污染极值 def calc_aqi_overall(sample): # 多个污染物分别换算后取最大值为综合 AQI aqi_pm25 calc_aqi_pm25(sample[pm25]) # PM10、SO2、NO2、O3 同样计算…… return max(aqi_pm25, aqi_pm10, aqi_so2, aqi_no2, aqi_o3)大屏页面上展示的“当前 AQI 数字”就是这个综合计算函数的输出。这一段在实战项目里是最容易被忽略、但也是最值得完整实现的部分。很多人做空气质量大屏直接拿原始浓度值当 AQI 显示内行一看就不专业。如果是在面试或演示场景你把 AQI 换算函数完整写出来并且在页面标注清楚“当前 AQI 由五项污染物综合计算”说服力完全不一样。3.2 计算机性能指标模块CPU、内存、磁盘的实时监控实现性能监控模块采集的是计算机本机的 CPU 使用率、内存占用率、磁盘 I/O 情况。这一模块的实现逻辑和空气模块类似但数据源不同——空气数据可能是模拟的性能数据完全可以实际从操作系统读取这在实战项目中能取得更好的演示效果。# performance/metrics.py —— 读取本机真实性能指标 import psutil def read_perf_metrics(): # psutil 库读取系统级指标CPU、内存、磁盘 cpu_percent psutil.cpu_percent(interval1) memory psutil.virtual_memory() disk psutil.disk_usage(/) return { cpu_percent: cpu_percent, memory_percent: memory.percent, memory_used: round(memory.used / (1024 ** 3), 2), memory_total: round(memory.total / (1024 ** 3), 2), disk_percent: disk.percent, disk_used: round(disk.used / (1024 ** 3), 2), disk_total: round(disk.total / (1024 ** 3), 2), timestamp: time.time() }psutil是 Python 生态里最有名的系统监控库读取 CPU、内存、磁盘指标就是最简单的一层应用。这个项目的价值在于它把psutil读取到的系统指标接到了大屏页面上让“本机运行状态”变成可视化页面。对于没有硬件传感器的人来说打开这个模块就能看到真实的、持续变化的数据实时效果比任何模拟数据都直观。如果把计算机性能指标的采集频率调高到每秒一次再用带平滑曲线的折线图来展示就能看到一个非常像样的实时监控大屏。这里有个实操细节cpu_percent(interval1)里的interval1表示采样间隔 1 秒如果省略不写在部分系统上第一次调用会返回 0.0因为内核还没有采集到时间窗口内的差值。第一次读到的数据是 0 或偏小这是一个很典型的坑我在部署这类监控脚本时至少踩过两次。正确用法就是像上面这样显式指定采样间隔。性能模块和数据存储的设计上通常也是用 SQLite 做本地存储数据表单独一张perf_data表字段包含 cpu_percent、memory_percent、disk_percent、timestamp。这样设计完全不用额外部署数据库服务对轻量大屏项目来说SQLite 的读写能力完全覆盖这种监控数据量。3.3 数据存储与接口设计SQLite 的单文件优势与表结构约定数据层统一采用 SQLite这是轻量级方案里最常规的选择。SQLite 就一个.db文件不需要安装数据库服务端数据文件拷走就能带走整个数据状态。对监控频率在秒级、单个指标一天几万条的规模来说SQLite 的读写性能完全不是瓶颈。-- 初始化数据表结构 CREATE TABLE IF NOT EXISTS air_data ( id INTEGER PRIMARY KEY AUTOINCREMENT, pm25 REAL NOT NULL, pm10 REAL NOT NULL, so2 REAL NOT NULL, no2 REAL NOT NULL, o3 REAL NOT NULL, timestamp REAL NOT NULL ); CREATE TABLE IF NOT EXISTS perf_data ( id INTEGER PRIMARY KEY AUTOINCREMENT, cpu_percent REAL NOT NULL, memory_percent REAL NOT NULL, disk_percent REAL NOT NULL, timestamp REAL NOT NULL );两张表的字段结构都很直观。timestamp统一存 Unix 时间戳浮点数而不是存字符串这是我认为所有监控类项目都必须坚持的规范。用纯数字存时间排序、比较、截取时间段都走数学运算效率高且不会踩时区格式化的坑。展示层需要人类可读的时间时在接口层或前端做一个格式化就好存储层保持最纯净的数值形态。接口设计的约定上两个数据 API 统一返回latest和history的结构前端拿到之后一个填数字、一个填图表这是这个项目里值得带走的一个接口设计经验。接下来看一个真实场景下绕不开的问题多页面切换时图表状态怎么保住以及实时刷新带来的性能坑。4. 多页面切换与状态保持从模板继承到前端路由激活态多页面切换在大屏系统里看起来简单无非是点击不同的导航项跳转到不同路由。但实战中有一个常见问题页面切换后图表会重新加载如果图表是从历史数据重新渲染用户需要再等一次刷新周期才能看到完整曲线。尤其是带实时刷新的页面切走再切回来之前的图表状态没了给人感觉特别“卡”。4.1 模板继承如何简化多页面公共结构这个项目的模板继承结构是整个多页面切换的基础。基础模板base.html里定了导航、公共 CSS、公共脚本子页面只需要在content区块写自己页面特有的内容。切换页面时Flask 渲染新的模板导航高亮状态需要根据当前路由动态标记。nav classsidebar ul li class{% if active_page dashboard %}active{% endif %} a href{{ url_for(index) }}总览看板/a /li li class{% if active_page air %}active{% endif %} a href{{ url_for(air_quality.index) }}空气质量/a /li li class{% if active_page perf %}active{% endif %} a href{{ url_for(performance.index) }}性能监控/a /li /ul /nav# 视图函数传入 active_page 变量 def index(): return render_template(dashboard.html, active_pagedashboard)这里的关键是把active_page作为模板变量传入由基础模板根据它决定给哪个导航项加高亮class。如果不用这个机制就得在每个子模板里重写一遍导航栏代码不仅冗余还容易出现改一处忘一处的低级问题。在实战项目中导航高亮失效是页面切换功能“能跑但显得糙”的最典型表现把active_page的定义逻辑放到视图函数里统一处理干净利落。4.2 页面切换后图表状态保持的思路当用户从性能监控页切到空气质量页再切回来一种自然的期望是页面直接显示离开前的图表状态而不是重新从“加载中”开始。在纯服务端渲染的多页面系统里要做得彻底可以引入浏览器的sessionStorage或localStorage前端在保存图表数据时把最近一次数据快照写到本地页面重新加载时优先用本地快照渲染再通过网络请求覆盖为最新数据。// 页面加载时先检查本地有没有历史快照 const saved sessionStorage.getItem(perf_latest); if (saved) { renderDashboard(JSON.parse(saved)); // 先用本地数据渲染避免白屏 } // 再异步拉取最新数据覆盖 fetchLatestPerfData().then(data { sessionStorage.setItem(perf_latest, JSON.stringify(data)); renderDashboard(data); });这段代码把“先用旧数据渲染再用新数据覆盖”这个策略实现得很清楚。对于大屏系统来说用户体验的卡顿感往往不是来自数据刷新慢而是来自页面白屏等待。用本地快照垫底切换页面至少能看到上一次的数据结构视觉上保持连续这在演示和实战场景里都特别加分。sessionStorage和localStorage的区别在于前者在标签页关闭后清空后者持久保留。监控大屏场景我一般用sessionStorage因为每次打开页面时期望看到的是这次会话内的最新数据而不是几天前的旧数据。如果用localStorage表结构变了或者数据过期了前端还要做版本判断复杂度没必要。4.3 多页面切换的工程化组织路由前缀与模块文件夹当前端页面多了之后如果整个系统的路由、模板、静态文件都堆在一起维护就成问题。这个项目通过蓝图和文件夹分类把“大屏系统”拆成了“总览 业务模块”的组织结构。空气模块有自己的模板目录、静态目录和 Python 视图文件性能模块同结构。这样做的好处是模板文件的查找路径清晰JavaScript、CSS 文件按模块归属存放多人协作时每个人关注自己的模块目录就行。这种组织方式和现代前端工程化的“页面即模块”思路是对齐的只是实现载体从 Webpack/Vite 变回了 Flask 的目录约定。学习这个项目时建议认真看一下目录结构。理解了这个结构往里面加一个新的“网络流量监控”模块思路非常直接新建一个目录里面放视图文件、模板、静态资源注册蓝图导航加一个入口完事。整个多页面的扩展成本被压缩到最小这是轻量框架给的底气。5. 避坑与排查大屏系统部署和运行中的七个常见坑这个系统整体复杂度不算高但运行和二次开发过程中总有一些反复出现的坑。挑几个最典型的说一下每条都按“现象、原因、解决”的方式写清楚这些都是我自己在调试这类项目时遇到的真实情况照着排查能省不少时间。5.1 图表容器显示空白或高度为 0现象页面打开后图表区域是一块空白控制台没有任何报错或者报一个 width/height 为 0 的警告。原因ECharts初始化时需要容器有明确的宽度和高度。很多情况下容器没设置高度或者设置了百分比高度但父级元素没有实际高度导致echarts.init()时拿到的高度是 0。解决给图表容器设置固定像素高度而不是百分比。比如写成stylewidth:100%; height:400px;这是最稳妥的。如果需要响应式高度也至少要保证父级有确定的高度值。还有一种情况是容器元素在初始化时是隐藏的比如处于未选中的tab页这时候初始化拿不到正确尺寸。如果确实要在隐藏容器中初始化图表需要在切换到该页签后用chart.resize()指定宽高才会正确显示。5.2 后端接口正常前端轮询数据不更新现象浏览器单独访问接口地址能看到新数据但页面上的数值一直不变。原因前端轮询时请求被浏览器缓存了。一些网络环境和浏览器策略会缓存 GET 请求的响应如果后端返回响应头里没有禁用缓存浏览器就会拿旧响应给前端。解决在后端接口响应中加上禁用缓存的响应头。在 Flask 视图函数里可以这样处理app.route(/api/air_quality) def api_air_quality(): response jsonify(query_latest_and_history(air_data)) response.headers[Cache-Control] no-store, no-cache, must-revalidate, max-age0 response.headers[Pragma] no-cache return responseCache-Control里的no-store是最严格的一条告诉浏览器和中间代理不要保存这个响应的任何副本。no-cache意思是使用缓存前必须到服务端验证是否过期。两个头配合Pragma一起设置可以覆盖绝大部分浏览器和缓存服务器的行为。这个坑在开发环境不明显部署到 Nginx 后面或者用了 CDN 时才容易冒出来。5.3 图表切换页签后尺寸异常现象从别的页面切回图表页面图表撑满了整个容器或只有一部分显示坐标轴错位了。原因ECharts 实例在页面加载时初始化的尺寸和页面切换回来后容器的实际尺寸不一致但图表不会自己重新测量。浏览器窗口大小变化、侧边栏折叠等操作也会引发同样的问题。解决监听窗口尺寸变化调用chart.resize()。如果是在多页签场景中切回页签时需要重新 resize。代码可以统一写成window.addEventListener(resize, function () { if (chart) chart.resize(); });这一步加上之后图表的自适应能力会提升一大截。当大屏总览页在全屏和嵌入页面之间切换时这个resize处理就是保持图表不变形的底线操作。5.4 实时数据刷新导致图表闪烁现象页面上的图表每隔几秒就整体重绘一次看起来闪烁不断视觉上很不舒服。原因轮询拿到数据后每次都重新setOption而且没有关闭动画ECharts 会重新执行一次过渡动画。但如果传递给setOption的数据结构完整覆盖了旧配置在某些配置组合下整条曲线会从零开始重新绘制导致闪烁。解决setOption的第二个参数设为true可以关闭合并逻辑第三个参数设为true表示不触发动画重绘。常规的处理是把这两个参数显式写出来chart.setOption({ series: [{ data: newData }] }, true, true);第二个参数true表示不合并配置直接替换第三个参数true表示不启动动画。这样更新时曲线会平滑过渡不会整图闪烁。另外如果每次更新是整个 series 全量替换可以考虑用ECharts的dataset组件配合appendData做增量更新这样数据量大了也不会越来越卡。不过对于这种轻量项目setOption的优化已经完全够用dataset组件的复杂度不一定要上。5.5 页面切换后定时器没有清理现象从一个页面切到另一个页面旧页面的数据还在持续请求多个页面叠加导致后端压力增大甚至浏览器卡顿。原因setInterval在页面卸载时没有清除页面跳转后旧页面的定时器依然在跑。如果用的是单页应用框架这个坑更隐蔽在 Flask 这种多页面刷新模式下每次刷新页面定时器自然重建但如果是通过 JavaScript 做局部切换问题就会暴露。解决在beforeunload或页面隐藏事件中清除定时器。最简单的方式是保存定时器标识并显式清除let timer setInterval(loadAirQuality, 5000); // 页面卸载或切换时清除定时器 window.addEventListener(beforeunload, function () { clearInterval(timer); });在基于 Flask 模板的多页面模式下通常整页刷新会让定时器自然失效但如果页面上有 Ajax 局部加载的逻辑或使用了 Pjax 之类的无刷新跳转这个清理动作就是硬需求。我的习惯是凡是在 JavaScript 里开了setInterval就一定配套一个清理入口。5.6 数据库文件被锁定SQLite 在多进程下的写入冲突现象部署到生产环境用 Gunicorn 启动多个 Worker 后日志出现database is locked的报错。原因SQLite 在写入时会锁定整个数据库文件如果有多个进程同时执行写操作后到的写入请求就会拿不到锁。开发模式下使用 Flask 自带的开发服务器是单进程的问题不明显换成多 Worker 的生产部署方式写入并发就会放大。解决写入操作加上重试机制并且打开短事务。具体到写入函数里用try-except捕获锁异常并重试import time import sqlite3 def insert_with_retry(db_path, sql, params, retries3): for attempt in range(retries): try: conn sqlite3.connect(db_path, timeout3) conn.execute(BEGIN IMMEDIATE) conn.execute(sql, params) conn.commit() conn.close() return except sqlite3.OperationalError as e: if locked in str(e) and attempt retries - 1: time.sleep(0.2) # 稍等片刻再重试避免忙等 continue raise这里有两个关键设计。BEGIN IMMEDIATE是让 SQLite 在事务开始时就申请写锁而不是等到第一次写操作时才申请这样能减少死锁概率。timeout3是连接超时设置避免拿不到锁时无限等待配合重试机制形成一套完整的写入保护逻辑。数据采集进程如果写入频繁这个重试函数是必须要有的。5.7 时间戳显示时区错乱现象大屏上显示的历史数据折线图时间轴整体偏移了 8 小时或者现实时间和图表时间对不上。原因后端存的是 Unix 时间戳这是绝对时刻没有时区概念。前端new Date(timestamp)会按浏览器本地时区解析如果服务器和浏览器不在同一时区或者采集端的时间本身就不对图表的时间轴就会偏。解决统一在接口层返回 ISO 格式字符串或者让前端明确指定时区。最省事的方案是后端在接口返回时就用datetime.fromtimestamp()转成本地时间字符串前端直接用字符串不再做new Date()转换。要注意的一点是采集端服务器如果时区设置不正确所有数据都会偏移部署前在采集端校验一次date命令输出是比较重要的。这个坑不复杂但一旦出现排查起来会特别有迷惑性——数据和数值都是对的就是时间轴不对容易被当成图表库问题研究半天。6. 部署与验证从开发环境到生产环境的完整落地路径项目能跑通是一回事能稳定给业务用是另一回事。最后一章把部署和验证的关键操作理一遍同时给一个从这段经历里沉淀出来的操作习惯后面做任何大屏项目都能用得着。6.1 生产环境部署Gunicorn 加 Nginx 的常规组合开发环境中app.run()是单进程的调试服务器直接暴露到生产环境会有性能和稳定性问题。常规做法是用 Gunicorn 充当 WSGI 服务器Nginx 在它前面负责静态文件服务和反向代理。# 安装依赖 pip install gunicorn flask psutil # 启动 Gunicorn绑定本机 8000 端口4 个 Worker 进程 gunicorn -w 4 -b 127.0.0.1:8000 app:app-w 4是指定 4 个 Worker 进程生产环境一般按 CPU 核心数两倍左右设置。app:app表示从app.py导入名为app的 Flask 实例。这一步之后Nginx 配置里把/代理到 127.0.0.1:8000静态文件CSS、JS、图片直接让 Nginx 自己处理减轻 Python 进程的压力。要注意一点如果启用了多 Worker上一章提到的 SQLite 写入冲突问题就更可能出现。数据采集如果和 Web 服务在同一个程序里跑建议把采集逻辑独立成一个脚本用cron或系统服务去调度写数据库Web 层只做读取写入和读取分离后SQLite 的工作压力会小很多。这是我做了几个监控项目之后切到的最优结构。6.2 验证实时刷新是否正常三分钟快速检查法部署完成后的验证环节我习惯按下面三步走第一步直接请求接口地址确认 JSON 结构完整且latest和history字段存在。curl http://127.0.0.1:8000/api/air_quality | python3 -m json.toolpython3 -m json.tool会让 JSON 格式化后输出便于肉眼检查。重点看timestamp字段和最新一条数据是否匹配当前时间。第二步打开浏览器大屏页面停留在“空气质量”页面观察 30 秒内大数字是否自动变化。如果数据是模拟生成的PM2.5 等数值在几秒内应该有所变动。第三步切到“性能监控”页面观察 CPU 曲线是否持续更新。如果曲线完全不动大概率是采集脚本没有运行到数据库里查一下SELECT COUNT(*) FROM perf_data看是否会持续增长。如果在涨但页面不更新问题就回到了 5.2 的缓存坑。这套三分钟检查法能快速定位问题出在前端还是后端对监控大屏这种前后端串起来的项目尤其好使。6.3 给二次开发的人留一条可走的路拿到这个项目后不管要改造成什么场景最建议的操作是先把虚拟环境和依赖装好把项目原封不动跑一遍确认页面、接口、数据库全部正常再做改造。我当年第一次拆这类项目时上来就直接改代码改到一半发现原始功能都跑不通最后花了一晚上才搞清楚是数据库路径配置错了。从那以后每拆一个项目都强制自己先跑通原版再动手这个习惯帮我省掉了太多不必要的排查时间。希望帮到你。本文还有配套的精品资源点击获取