Flask+Vue+ECharts构建超市数据可视化大屏：全链路解析

做这类“大型超市数据处理 数据可视化大屏”的项目很多同学第一反应是“不就是做个图表页面吗”真正动手才发现最难的不是ECharts的配置而是数据从哪来、怎么洗干净、怎么通过后端接口稳定地吐给前端最后才是大屏怎么排版好看。我前前后后带过不少类似课题也自己完整做过这套Flask Vue ECharts的组合这里把整个系统的设计思路、关键代码、踩坑记录一次性讲透希望能帮你少走几周弯路。如果你手头的题目是“基于Python Flask的超市数据处理与可视化大屏分析系统”或者你已经确定了用Vue做前端、Flask做后端那这篇文章就是给你准备的。我会先讲整体怎么拆解需求再深入到数据库设计、接口开发、大屏适配最后聊聊我做过程中踩过的真实bug和排查套路。1. 项目拆解与技术选型逻辑1.1 核心需求到底是什么标题里有三个关键词数据处理、Flask、数据可视化大屏。很多人做这类系统时容易本末倒置——一上来就找炫酷的大屏模板结果数据接口全写死在前端后台的数据处理逻辑形同虚设。实际上这类系统的核心并不是“好看”而是让数据经过一条清晰的处理链路原始数据 → 清洗 → 聚合 → 接口 → 图表最终以直观方式呈现业务结论。我来帮你细化一下需求。典型的大型超市场景里数据源往往包含几类商品信息表商品ID、名称、品类、进价、售价、供应商。门店/仓库表门店ID、区域、面积、店长等。订单流水表订单号、商品ID、门店ID、销售数量、销售金额、订单时间、收银员ID。会员表会员ID、等级、注册时间、累计消费金额。所以“数据处理”至少包含三件事数据清洗去空、去重、纠正异常值、数据聚合按时间、品类、门店多维度汇总、数据建模计算同比、环比、占比、TopN等业务指标。可视化大屏则是这些处理结果的“出口”。通常一个大屏会放这些核心图表销售趋势折线图、品类销售占比饼图、门店销售额排行条形图、热销商品Top榜、客流/订单量指标卡以及一些辅助性的地图分布或雷达图。大屏不是把一堆图表拼在一起而是围绕“管理者一眼看出今天卖得好不好、哪个品类拖后腿、哪个门店该重点关注”来组织。1.2 为什么选Flask Vue而不是其他组合我在好几个项目里对比过几种前端后端的组合方案把结论放在表里组合方案优点缺点适用场景Flask Jinja2模板 原生JS结构简单、部署容易前端交互能力弱图表多时DOM操作混乱纯后端课设雏形Flask Vue前后端分离前后端解耦、大屏组件化开发效率高、ECharts封装方便需要处理跨域、打包部署比模板复杂本类可视化大屏项目推荐Django Vue自带Admin、ORM强大框架较重小项目配置繁琐有用户权限管理的大型系统Node Express Vue前后端都用JS语言统一后端生态不如Python做数据处理方便单纯Web应用而非数据分析系统为什么最终锁定Flask Vue核心原因是数据处理这部分。超市订单数据动辄几万条清洗聚合如果用SQL硬写也行但当规则复杂比如要剔除退货订单、要填充缺失的品类信息、要计算移动平均时用Python的Pandas会比SQL顺手得多。Flask的轻量让Pandas得到的DataFrame可以非常方便地转成JSON传给前端。而Vue则是目前大屏项目的主流选择——Vue的组件化用来封装每一个图表卡片非常合适加上Vue Router管理大屏和多页面的跳转也很顺手。组合在一起会形成一条很顺畅的数据链路原始CSV/Excel → Pandas清洗聚合 → Flask JSON API → Axios → Vue组件 → ECharts渲染1.3 整体架构模块化是毕设答辩的加分项不要把所有代码塞到一两个文件里。一个合理的Flask后端目录结构能让你后期维护和写论文时都舒服很多分享一个我个人比较常用的结构supermarket_project/ ├── backend/ │ ├── app.py # 应用入口注册蓝图 │ ├── config.py # 配置信息数据库、密钥等 │ ├── models/ │ │ ├── __init__.py │ │ ├── base.py # 数据库基类 │ │ ├── order.py # 订单模型 │ │ ├── product.py # 商品模型 │ │ └── member.py # 会员模型 │ ├── services/ │ │ ├── data_cleaner.py # Pandas数据处理服务 │ │ ├── stats_service.py # 指标计算服务 │ │ └── recommend.py # 智能推荐/预警模块 │ ├── api/ │ │ ├── dashboard_api.py # 大屏数据接口蓝图 │ │ ├── product_api.py # 商品管理接口 │ │ └── order_api.py # 订单管理接口 │ └── utils/ │ └── response.py # 统一响应格式封装 ├── frontend/ │ ├── public/ │ ├── src/ │ │ ├── views/ │ │ │ ├── Dashboard.vue # 大屏页 │ │ │ ├── ProductList.vue │ │ │ └── OrderList.vue │ │ ├── components/ │ │ │ ├── charts/ │ │ │ │ ├── TrendChart.vue │ │ │ │ ├── CategoryPie.vue │ │ │ │ └── StoreBar.vue │ │ │ ├── BorderBox.vue # 大屏装饰边框 │ │ │ └── NumberCard.vue # 指标卡片 │ │ ├── router/index.js │ │ ├── api/axios.js # Axios封装 │ │ └── main.js │ └── package.json ├── data/ │ ├── raw/ # 原始模拟数据 │ └── processed/ # 清洗后的数据 └── README.md用蓝图Blueprint把接口分开用Vue Router把页面路由分开答辩时老师问你“系统架构如何设计”你把这套目录结构一画条理清晰第一印象分就有了。2. 数据库设计与数据处理管道2.1 超市业务数据建模从业务到表单如果需要自己造数据或者做毕设演示数据建模千万别偷懒。建议至少设计5张核心表商品表、门店表、订单流水表、订单明细表、会员表。订单流水和订单明细为什么要分开因为一个订单可能包含多个商品如果把商品和订单塞进同一张表冗余度会爆炸后续统计销售额、数量时会非常难受。一个相对标准的MySQL建表语句参考CREATE TABLE products ( product_id INT PRIMARY KEY, product_name VARCHAR(100) NOT NULL, category VARCHAR(50), purchase_price DECIMAL(10,2), selling_price DECIMAL(10,2), supplier VARCHAR(80) ); CREATE TABLE stores ( store_id INT PRIMARY KEY, store_name VARCHAR(50), region VARCHAR(30), area_sqm DECIMAL(10,2) ); CREATE TABLE orders ( order_id VARCHAR(30) PRIMARY KEY, store_id INT, member_id INT, order_time DATETIME, total_amount DECIMAL(10,2), FOREIGN KEY (store_id) REFERENCES stores(store_id) ); CREATE TABLE order_items ( item_id INT AUTO_INCREMENT PRIMARY KEY, order_id VARCHAR(30), product_id INT, quantity INT, amount DECIMAL(10,2), FOREIGN KEY (order_id) REFERENCES orders(order_id), FOREIGN KEY (product_id) REFERENCES products(product_id) );这里踩过的坑是订单总额跟明细金额对不上。比如订单表记录了total_amount128.00但明细表里两条数据加起来是128.50。这是因为有的商品有折扣有的退了货。所以我在清洗阶段专门加了一步“一致性校验”如果金额差异超过0.01元就标记异常。这步校验在写论文时能作为“数据质量控制”的亮点写进去实用性也强。2.2 数据清洗实操Pandas处理脏数据的5个关键步骤真实业务里原始导出数据通常是Excel或CSV问题多得很日期格式不统一、金额含有带货币符号的文本、某些品类字段为空、订单号重复、负数金额……写个数据清洗服务是我在做这类项目时最费时间也是最有价值的一步。用Pandas大致会走这几步第一步读取并预览import pandas as pd df pd.read_csv(data/raw/orders.csv, encodingutf-8) print(df.info()) print(df.head(10)) print(df.isnull().sum())第二步类型转换与字段修正# 把金额文本转换成浮点数比如 ¥128.00 变成 128.00 df[total_amount] df[total_amount].astype(str).str.replace(¥, ).astype(float) # 日期列统一成标准格式 df[order_time] pd.to_datetime(df[order_time], errorscoerce)errorscoerce是处理脏日期时的关键参数非法日期变成NaT后面统一处理。如果直接to_datetime遇到脏数据会整个崩溃。第三步去重与空值处理# 按订单号去重保留第一次出现的 df df.drop_duplicates(subset[order_id], keepfirst) # 空值填充策略需要分字段讨论不能一刀切 df[category].fillna(未知品类, inplaceTrue) df[member_id].fillna(0, inplaceTrue) # 0表示非会员第四步异常值过滤# 销售金额不可能为负数量不可能大于1000超市单笔订单 df df[(df[total_amount] 0) (df[quantity] 1000)]这里有个需要注意的逻辑如果遇到负金额究竟是直接删除还是转为退款单单纯删除会让销售总额虚高。我在系统里单独分出一个“退款流水”这样统计净销售额时口径更严谨。第五步保存处理结果df.to_csv(data/processed/orders_clean.csv, indexFalse)处理完的数据再导入MySQL或者直接用Pandas做聚合分析都行。小数据量几万条以内我建议直接读CSV进Pandas处理省掉MySQL维护成本但如果你答辩时被问“数据库在哪里”至少要把MySQL表结构建好把CSV导入MySQL中逻辑上才完整。2.3 聚合宽表给前端“喂饭吃”的关键设计前端ECharts要的数据格式通常很简单[2024-01, 2024-02, 2024-03]对应[128000, 145000, 132000]。如果每次请求都在后端现场写复杂SQL再做Pandas二次处理性能不好代码也乱。我推荐的做法是维护一张聚合宽表dashboard_summary把大屏需要的核心指标提前算好。聚合表大致长这样CREATE TABLE dashboard_summary ( stat_date DATE, category VARCHAR(50), store_id INT, sales_amount DECIMAL(12,2), order_count INT, member_count INT, PRIMARY KEY (stat_date, category, store_id) );每天晚上或者每次启动系统时跑一段Python脚本用Pandas的groupby把订单数据聚合到这个宽表summary df.groupby( [df[order_time].dt.date, category, store_id] ).agg( sales_amount(total_amount, sum), order_count(order_id, count), member_count(member_id, nunique) ).reset_index() summary.to_sql(dashboard_summary, engine, if_existsreplace, indexFalse)前端再要“今天各品类销量”“本月各门店排名”这些数据时后端接口只需要对这个宽表做简单的过滤和求和响应时间从几百毫秒降到几十毫秒。这也是大屏项目性能优化的一个核心手段——用空间换时间提前聚合。这招在写“系统设计”章节时可以重点展开。3. 后端API设计从数据到接口的最后一公里3.1 Flask蓝图划分与统一响应格式Flask开发大屏项目时最容易犯的错是把所有路由堆在app.py里看起来杂乱无章也不方便团队协作。用蓝图做模块化隔离是标准做法。我来演示一下dashboard_api.py怎么设计from flask import Blueprint, jsonify, request from services.stats_service import StatsService dashboard_api Blueprint(dashboard_api, __name__) dashboard_api.route(/api/dashboard/overview, methods[GET]) def get_overview(): 获取大屏顶部核心指标总销售额、订单量、客单价、会员数 date_range request.args.get(range, today) data StatsService.get_overview(date_range) return jsonify({code: 0, data: data, msg: success}) dashboard_api.route(/api/dashboard/trend, methods[GET]) def get_trend(): 获取销售额趋势支持按hour/day/month三种粒度 granularity request.args.get(granularity, day) data StatsService.get_sales_trend(granularity) return jsonify({code: 0, data: data, msg: success})统一响应格式这里很重要。我见过很多项目一个接口返回{code: 0, data: ...}格式另一个返回{status: true, result: ...}格式前端Axios拦截器就很难统一处理。建议全后端统一用code0表示成功非0表示业务失败前端拿到非0直接弹错误提示。3.2 核心接口实现销售额趋势、品类占比、门店排行以销售额趋势为例后端聚合逻辑大致如下class StatsService: staticmethod def get_sales_trend(granularityday): # 从聚合宽表读取 df pd.read_sql(SELECT stat_date, sales_amount FROM dashboard_summary, engine) df[stat_date] pd.to_datetime(df[stat_date]) # 按粒度重采样 if granularity day: series df.set_index(stat_date)[sales_amount].resample(D).sum() elif granularity month: series df.set_index(stat_date)[sales_amount].resample(M).sum() else: series df.set_index(stat_date)[sales_amount].resample(H).sum() return { dates: series.index.strftime(%Y-%m-%d).tolist(), values: [round(v, 2) for v in series.values.tolist()] }品类占比的接口本质上是一个groupby后算百分比的过程category_stats df.groupby(category)[sales_amount].sum().sort_values(ascendingFalse) total category_stats.sum() data [ {name: idx, value: round(val / total * 100, 2)} for idx, val in category_stats.items() ]门店排行类似加一个head(10)即可。这些接口写完后最好用Postman或者直接在浏览器访问/api/dashboard/trend?granularityday测试一遍JSON格式是否符合ECharts数据结构要求。3.3 缓存与跨域老生常谈但必须处理的性能问题大屏页面通常需要每隔几秒刷新数据。如果每次刷新都全量查表数据库压力不小。我用Flask-Caching做了三级缓存策略from flask_caching import Cache cache Cache(app, config{CACHE_TYPE: simple, CACHE_DEFAULT_TIMEOUT: 300}) dashboard_api.route(/api/dashboard/overview) cache.cached(timeout60) # 核心指标1分钟缓存 def get_overview(): ...至于跨域开发环境下Vue跑在localhost:5173Flask跑在localhost:5000端口不同必然产生CORS跨域问题。简单配置方式是用flask-corsfrom flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})生产环境下前后端通常部署在同一域名我是把Vue打包后的dist目录直接挂到Flask的static文件夹里这样既避免跨域部署也简单。这一步完成后再启动Flask访问http://localhost:5000就能看到大屏页面。4. 数据可视化大屏Vue ECharts实战4.1 大屏布局169栅格系统与自适应方案大屏设计稿一般是1920×1080如果用px写死一到别人电脑上就乱套。我采用flex grid栅格方案来实现自适应布局。大屏顶部是标题和核心指标卡中间是销售额趋势大图左右两侧分别是品类占比和门店排行底部放热销商品和会员增长。用Grid布局示意如下template div classdashboard header classheader h1某某超市数据可视化分析系统/h1 /header div classmain div classleft CategoryPie / MemberCard / /div div classcenter TrendChart / NumberCards / /div div classright StoreBar / HotProducts / /div /div /div /template style scoped .dashboard { width: 100vw; height: 100vh; background: #0a1628; color: #fff; display: flex; flex-direction: column; } .main { flex: 1; display: grid; grid-template-columns: 1fr 2fr 1fr; gap: 20px; padding: 20px; } media screen and (max-width: 1400px) { .main { grid-template-columns: 1fr 1fr; } } /style这里有个容易忽略的细节大屏通常部署在展厅的大电视或投影仪上这些设备分辨率可能是1366×768或者2560×1440所以自适应方案必须做。我在做的时候还加了transform: scale()缩放方案作为兜底根容器按1920设计稿固定宽度然后用JS动态计算缩放比例。两种方案按需选择即可。4.2 ECharts核心配置让图表会说话每个图表组件封装成单独的Vue组件是这套系统最值得做的设计。以TrendChart.vue的折线图为例核心配置我来拆解一下import * as echarts from echarts export default { props: { trendData: Object }, mounted() { this.chart echarts.init(this.$refs.chartRef) this.renderChart() window.addEventListener(resize, this.resizeHandler) }, methods: { renderChart() { const option { backgroundColor: transparent, tooltip: { trigger: axis, axisPointer: { type: shadow } }, grid: { left: 10%, right: 5%, top: 15%, bottom: 15%, containLabel: true }, xAxis: { type: category, data: this.trendData.dates, axisLine: { lineStyle: { color: #4a5a7a } }, axisLabel: { color: #aac3e0 } }, yAxis: { type: value, name: 销售额万元, scale: true, axisLabel: { formatter: (value) (value / 10000).toFixed(1) 万 } }, series: [{ name: 销售额, type: line, data: this.trendData.values, smooth: true, symbol: circle, symbolSize: 6, lineStyle: { width: 3, color: #3399ff }, areaStyle: { color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [ { offset: 0, color: rgba(51,153,255,0.4) }, { offset: 1, color: rgba(51,153,255,0) } ]) } }] } this.chart.setOption(option) } } }这段配置里的细节值得说说areaStyle渐变填充让折线图更有“高级感”很多模板大屏恰是因为缺了这层渐变显得愣头愣脑。yAxis的formatter把冗长的金额转成“23.5万”这种可读性强的格式避免大屏上出现满屏的0。smooth: true配合symbolSize让线条平滑且节点明显数据点多了不至于糊成一片。4.3 指标卡和地图容易被忽略的小细节大屏顶部通常有几个核心指标卡今日销售总额、订单总量、客单价、会员总数。做这个组件时我建议直接用CSS动画加数字滚动效果。后端返回目标数值后用requestAnimationFrame把数字从0滚动到目标值视觉冲击力会强很多给人感觉系统非常“活”。代码如下animateNumber(target) { const duration 1000 const start 0 const startTime performance.now() const update (currentTime) { const progress Math.min((currentTime - startTime) / duration, 1) const current start (target - start) * progress this.displayValue Math.floor(current).toLocaleString() if (progress 1) requestAnimationFrame(update) } requestAnimationFrame(update) }地图方面如果要用中国地图展示门店分布ECharts的china.js地图数据需要在项目中单独引入新版ECharts不再内置地图数据。注意去下载对应GeoJSON并注册否则地图会白屏import chinaJSON from ../assets/china.json echarts.registerMap(china, chinaJSON)这里建议重点确认你用的ECharts版本不同地图数据加载方式也不同。ECharts 5以上是需要手动引入GeoJSON的容易踩坑。如果业务里不强调地域维度可以用柱状图替代避免为了地图而地图。4.4 大屏“看着专业”的三个加分细节很多人的大屏做出来总感觉“有点土”其实问题往往不在图表数据而在视觉框架。我总结出三个见效特别快的细节一是装饰边框。大屏的每个图表块加一个半透明的科技感边框可以用CSS实现也可以用图片或边框素材库整体质感立刻提升。我在BorderBox.vue里用四角装饰加边框渐变类似电视节目的字幕框视觉上会显得专业很多。二是统一字体与配色。大屏配色尽量控制在一种主色比如蓝色系或青色系加一种强调色橙色或紫色。字体方面数字部分用DIN或Roboto Mono这类等宽字体会明显提升数据页面的高级感。三是轮询刷新而不是手动刷新。大屏要给人“实时”的感觉前端用setInterval每10秒重新拉一次接口setInterval(() { this.fetchData() }, 10000)注意组件销毁前要清除定时器否则页面切走之后还在不断请求接口容易产生内存泄漏。5. 智能分析模块让“数据处理”更有含量5.1 用移动平均做销售趋势预测单纯的折线图只能展示历史数据缺少“预判”能力。为了提高系统的分析深度我加了一个基于移动平均的销售预测模块。原理不复杂对最近N天的销售额做滑动平均用来平滑短期波动然后预测未来几天的趋势方向。def moving_average_forecast(df, window7, forecast_days3): df df.sort_values(stat_date) df[ma] df[sales_amount].rolling(windowwindow).mean() # 简单线性外推预测 recent_avg df[ma].iloc[-1] trend (df[ma].iloc[-1] - df[ma].iloc[-window]) / window future [recent_avg trend * i for i in range(1, forecast_days 1)] return future这个预测模型足够简单但答辩时能体现出你对“数据处理”有深度理解不是只会展示历史数据。还可以在预测值的折线上用虚线显示既直观又有区分度。5.2 库存预警规则引擎控制台大型超市的核心痛点除了卖货就是库存。我给系统加了一个库存预警模块规则是商品库存低于安全库存阈值 → 触发“补货预警”。商品连续7天销量为0且库存大于0 → 触发“滞销预警”。商品库存天数库存/日均销量小于3天 → 触发“紧急补货”。后端的实现不算复杂查商品表、订单表做聚合再用规则判断def check_stock_status(): # 每个商品的日均销量 daily_sales (df.groupby(product_id)[quantity].sum() / df[order_time].nunique()) stock_df pd.read_sql(SELECT * FROM inventory, engine) stock_df[daily_sales] stock_df[product_id].map(daily_sales) stock_df[stock_days] stock_df[stock_quantity] / stock_df[daily_sales] warnings [] for _, row in stock_df.iterrows(): if row[stock_quantity] row[safe_stock]: warnings.append({type: 补货预警, product_id: row[product_id]}) if row[stock_days] 3: warnings.append({type: 紧急补货, product_id: row[product_id]}) return warnings这一步能让系统从“图表展示工具”升级成“辅助决策工具”在功能设计上是很加分的。5.3 会员RFM分析给大屏加一个“人群洞察”如果数据里有会员消费记录可以考虑做一个简化版RFM分析不用真把这套复杂模型全量实现挑重点即可。我的实现思路是RRecency最近一次消费距今多少天。FFrequency近30天消费次数。MMonetary近30天累计消费金额。给每个维度打分1-5分然后用“重要保持客户、重要发展客户、一般客户、流失客户”四分类展示在大屏的一个“会员画像”板块里。这比单纯一个“会员总数”指标卡要有说服力得多。打分逻辑用Pandas的qcut分位数分割即可df[R_score] pd.qcut(df[recency], 5, labels[5, 4, 3, 2, 1]) df[F_score] pd.qcut(df[frequency], 5, labels[1, 2, 3, 4, 5]) df[M_score] pd.qcut(df[monetary], 5, labels[1, 2, 3, 4, 5])再按客户类型聚合人数用扇形图或环形图展示。这套模块做完你论文里的“系统创新点”至少能多写两页。6. 常见问题与排查技巧实录6.1 跨域请求失败与前端数据渲染异常这大概是大屏项目里出现频率最高的一类问题。Vue的开发服务器默认端口是5173Flask是5000两者之间axios请求必然跨域。处理办法前面提过用flask-cors是最简单的。如果你在Flask端配置了CORS(app)依然请求失败先检查一下请求路径是否正确再看是否有自定义中间件把OPTIONS预检请求拦截了。还有一个常见问题前端明明拿到了JSON数据但图表就是空白。我遇到过几次原因基本是数据格式不匹配比如后端返回的字段名是dates前端读取的是date。建议在axios拿到响应后先console.log(res.data)打印出来跟ECharts的option逐字段核对。6.2 大数据量渲染卡顿分页与数据抽样如果后端一次性返回一整年的销售数据比如365天折线图倒还好但如果是散点图或地图浏览器会很卡。优化手段通常是两个方向一是后端抽样/聚合。按天聚合完再按周采样例如把粒度从“天”升级到“周”视觉差异不大性能提升明显。二是前端开启取样。ECharts的sampling: lttb算法能在保留趋势的前提下自动减少绘制点series: [{ type: line, sampling: lttb, data: largeData }]我在处理几万条点位数据时开启这个配置后渲染帧数从十几帧直接提升到满帧值得一试。6.3 Flask热更新与Pandas类型转换的坑开发时用app.run(debugTrue)做热更新但如果你的数据处理代码里有面向对象缓存比如服务类里存了DataFrame修改代码后可能不会自动刷新需要手动重启Flask进程。这个问题在PyCharm里很坑我建议开发时用--debug模式下的use_reloaderFalse写一句快速重启脚本比反复等热更新更省心。另外Pandas的dtype转换是另一个容易出问题的地方。当某列全是整数时astype(int)没问题但一旦有缺失值变成NaN后再astype(int)就会直接报错。我在清洗流程里统一用df[sales_amount] pd.to_numeric(df[sales_amount], errorscoerce).fillna(0)能省下很多莫名其妙的崩溃。6.4 传统问题速查表现象原因解决思路前端请求接口404蓝图URL前缀与请求路径不匹配检查Blueprint(x, __name__, url_prefix/api/...)定义中文乱码Flask返回JSON没有指定UTF-8编码或者前端meta未设置配置app.config[JSON_AS_ASCII] False大屏刷新后图表闪烁component销毁/重建时没有调用dispose()beforeDestroy钩子中调用this.chart.dispose()数据库连接超时长时间运行的Pandas操作占用连接用完engine后调用engine.dispose()图表宽度为0容器未渲染完成就初始化ECharts在this.$nextTick(() { this.initChart() })中调用6.5 部署与演示阶段的最后建议毕设答辩演示时最怕的不是项目功能不够而是现场环境问题。我建议提前做三件事把关键数据预加载到本地演示时不要依赖网络下载地图或字体。准备一个全屏大屏快捷键比如按F11让页面瞬间铺满整个屏幕观感会好很多。把Flask的host设置成0.0.0.0这样同一局域网内的设备都能访问。演示时如果有两台设备一台笔记本控制一台投屏效果非常加分。部署到服务器时不必急着上Docker先把Vue打包后的dist放到Flask的static目录然后启动Flask即可。用Gunicorn跑生产模式也行但对这种课设/毕设规模的项目直接python app.py已经足够稳定。这个系统做到最后你会发现真正花时间的不是写代码而是梳理业务的来龙去脉——数据从哪里来、有哪些脏数据、哪个指标对管理者最重要、大屏上呈现什么信息最有决策价值。把这些想明白了Flask和Vue都只是工具。如果时间充裕还可以在这个基础上扩展把处理流程做成可配置的参数界面、接入模拟实时数据流比如用WebSocket推送给大屏、做移动端适配……但核心骨架就是这套“清洗-聚合-接口-大屏”的链路。按这个思路走无论是应付毕业设计还是往简历里写“数据可视化项目”都不会虚。