1. 选题视角:为什么新能源汽车数据分析是毕业设计的稳牌又到了毕业设计选题的旺季,后台私信里被问得最多的问题之一,就是基于 djangopython 的新能源汽车数据分析系统到底怎么做、怎么做才不会被答辩老师挑毛病。这个题目老实说确实值得选:数据源公开、业务场景真实、技术链完整,而且新能源汽车本身就是评委们愿意听、也听得懂的话题。但真正拉开分数差距的,不是用了什么框架,而是你怎么定义需求边界、怎么把数据分析的价值讲清楚。1.1 行业数据红利期与学术价值新能源汽车这个领域的特殊性在于,它既有传统汽车行业的销量-渠道-价格逻辑,又有电池、充电、续航这些新维度。这意味着你的数据模型天然就比图书管理系统、学生选课系统这类经典毕设题目更丰富,能展示的技术点也更多。举个例子,你可以同时实现销量趋势分析、品牌市场份额对比、充电设施覆盖率统计、电池续航与温度关系挖掘,甚至塞进一个简单的销量预测模块。这些功能听起来很多,但核心都是围绕采集数据-清洗数据-计算指标-可视化展示这条主线在走。只要主线清晰,功能多不等于复杂度失控,反而能证明你对业务的理解深度。从学术角度看,这属于典型的数据驱动的行业应用研究,既有数据预处理的技术含量,又有业务分析的实际价值。对评阅老师来说,这类题目不会像纯算法题那样看得一头雾水,也不会像纯后台管理那样让人觉得没有技术深度,处在看得懂、有亮点、好提问的舒适区间,通过率自然高。1.2 用 MVP 思维给毕业设计定边界很多同学一上来就列了八九个模块:用户管理、爬虫采集、数据清洗、多维分析、地图可视化、预测模型、导出报告、权限管理……真做起来一个月都排不完。我的建议是,先用 MVP(最小可行产品)思维把核心链路定为数据导入 → 指标计算 → 图表展示 → 简单预测,其他功能全部往后放。核心链路上下游的优先级大概是这样的:必须有:新能源汽车销量/充电/电池数据的导入与管理、按时间与品牌的聚合统计、基于 ECharts 的趋势图和占比图、用户登录与数据权限隔离锦上添花:爬虫自动采集、销量预测、Excel 导出、地图散点展示答辩加分但非必需:定时任务自动更新、Celery 异步处理、Docker 部署不要小看这个排序,我见过太多人栽在功能列表过长、每个功能都是半成品上。毕设评分的逻辑是:核心功能完整且能演示 功能多但到处报错 功能少但五脏俱全。把 MVP 做到 80 分,比把十个模块都做到 40 分划算得多。另外要提醒一点:标题里出现的程序文档讲解定制是市面上常见的一套服务组合,确实有同学是买现成的。但我的态度一直很明确——你可以参考别人的代码结构、借鉴定制的思路,但每一个核心模块最好亲自动手敲一遍。原因很简单:答辩时老师随机问一个视图函数里的查询逻辑,你不是自己写的,三五句话就能被问穿;而你自己从头跟过一遍的代码,哪怕有瑕疵,也能理直气壮地讲清楚我是怎么想的,这是答辩成功与否的分水岭。2. 技术栈选型与系统架构设计:别盲目跟风最新版确定了业务边界之后,第二步就是选型。这个环节最常踩的坑是什么版本新就用什么,结果在环境配置上浪费了整整一周。记住一个原则:毕业设计用的不是生产系统,而是稳定、资料多、网上能搜到解决方案的组合。2.1 Python 版本、Django 版本与数据库选型我在这类项目里最推荐的一套组合是 Python 3.10 Django 4.2 LTS MySQL 8.0(开发环境用 SQLite 起步)。为什么不是 Python 3.13 或 Django 5.x?因为 4.2 是长支持版本,官方维护周期长,社区里的坑和解决方案沉淀得最充分;你搜django 聚合查询报错也好、时区问题也好,基本都能找到对应版本的处理办法。数据库选择这里要展开说。毕设场景下,很多同学的笔记本内存也就 8G 或 16G,本地再跑一个 MySQL 服务端,加上 Navicat、浏览器、开发工具,内存经常亮红灯。我的建议是:开发阶段先用 SQLite 把全部功能跑通,等核心逻辑稳定后再切换 MySQL,切换成本其实很低——Django 的 ORM 层把数据库差异基本抹平了,你只需要改 settings 里的数据库配置,再加 pip 安装 mysqlclient 或 pymysql 即可。关于 Python 环境安装,这里多嘴一句:很多新手在 Windows 上安装 Python 时,忘勾选Add Python to PATH,导致终端输入 python 提示不是内部或命令,瞬间心态崩掉。网上那些python 安装教程里强调的其实是这个最常见的坑,安装完务必在命令行里执行 python --version 确认一下。Linux 环境(比如腾讯云轻量服务器)上装 python3-venv 之后记得用 python3 -m venv venv 创建虚拟环境,别直接往系统环境里 pip install,不然依赖冲突会让人怀疑人生。2.2 分析靠 SQL 还是 pandas:两类任务的分界这是选型里最核心的一个判断。我的经验是:能交给数据库聚合的,交给 ORM 写聚合;数据库搞不定的复杂变换,拉出来用 pandas 处理。分界标准很简单——看数据量级和计算复杂度。如果只是对已经落库的明细表做求和、计数、均值、分组排名,直接用 Django ORM 的 aggregate 和 annotate,让 MySQL 自己算。好处是内存压力小、响应快,前端拿到的直接就是聚合后的 JSON。但如果要做的是多表关联后按时间窗口滑动的复杂清洗,或者要对原始数据做缺失值填充、类型转换、单位统一,那就在导入阶段用 pandas 处理完,再把干净的 DataFrame 写进数据库。我实际做的时候,是把数据库当作最终结果集,把 pandas 当作上游加工车间。举个数据导入的例子:原始 CSV 里的价格(万元)字段可能是字符串,还可能带万这个汉字;pandas 用 astype 加正则清洗一遍,再统一转成 float,写进数据库之后所有聚合查询就不会再出类型问题。这个分工讲给答辩老师听,他们会觉得你确实理解数据的处理流程。2.3 目录结构与核心模块划分项目目录不要随心所欲地建,直接按 Django 官方推荐的项目-应用两级结构来,后期写文档画架构图时也好说明。我这里给一个新手友好的参考结构:new_energy_analysis/ ├── manage.py ├── config/ # 项目配置(settings/urls/wsgi) ├── apps/ │ ├── users/ # 用户认证与权限 │ ├── vehicle/ # 车辆销量与车型管理 │ ├── charge/ # 充电桩与充电数据管理 │ ├── analysis/ # 聚合统计接口与预测模块 │ └── common/ # 公共工具类、分页、JSON编码器 ├── static/ # CSS/JS/ECharts ├── templates/ # 页面模板 ├── data/ # 原始数据与清洗脚本 └── docs/ # 数据库设计文档、需求分析应用拆分的逻辑是各司其职,别把全部模型和视图堆在一个 app 里。很多新手会把 models.py 写成一千多行,答辩时老师随口问销量表在哪个文件,你都翻半天,这就很尴尬。合理的模块划分本身就是代码质量的体现。3. 数据建模与分析口径:决定系统价值的核心环节技术栈确定后,整个系统真正的灵魂不是代码,而是数据模型和指标口径。这一步如果设计错了,后期返工成本非常高。我先讲清楚业务表怎么建,再讲分析指标怎么定。3.1 业务数据表设计:抓住销量、充电、电池三个维度新能源汽车的数据维度虽然多,但你的系统不需要贪多,抓住三条主线就够:车辆销量、充电设施、电池性能。下面是我实际用过的核心表结构,字段的取舍是我反复权衡过的,直接抄作业问题不大:销量明细表(sale_record)class SaleRecord(models.Model): province models.CharField(省份, max_length32) city models.CharField(城市, max_length32) brand models.CharField(品牌, max_length32) model_name models.CharField(车型, max_length64) price models.FloatField(价格(万元)) sale_date models.DateField(销售日期) category models.CharField(车辆类型, max_length16, choices[(纯电, 纯电), (插混, 插混)]) quantity models.IntegerField(销量)这套字段可以支撑的查询包括:按省份统计总销量、按品牌计算市场占有率、按车型类型比较纯电与插混的销量走势、按价格区间拆分消费结构。字段不多,但组合出来的分析维度非常丰富。充电桩表(charge_station)和电池表(battery_data)也建议按类似思路建:充电桩表保留省份、城市、运营商、充电类型(快充/慢充)、功率、投运日期;电池表保留车型、电池容量、续航里程、工况温度、循环次数、衰减率。这两张表的数据量不用太大,但足够支撑充电便利性和电池衰减两个分析主题。3.2 数据清洗与口径统一:分析结果差异的根源同样的数据分析,用不同口径处理,结果可能是天壤之别。比如新能源汽车销量,有的口径只算纯电,有的把插混也算进去,还有的包含商用车或出口数据。你的系统里如果不统一口径,前端的占比图和后端的汇总数字对不上,答辩现场一旦被追问,基本就崩了。我的做法是:在项目文档里专门写一节统计口径说明,明确以下规则——销量统计范围以交付上险数据为准,价格字段统一使用厂商指导价(万元),充电桩统计口径为公共充电桩,不含私人桩,电池衰减率定义为实际容量/标称容量-1。这些定义在数据清洗脚本里用注释标注,在文档里用文字描述,在答辩 PPT 里用一页图表说明。你会发现,把口径讲清楚本身就是说服力。3.3 ORM 聚合查询的写法与常用统计指标Django ORM 的聚合函数是后端接口的主力。以按品牌统计销售总额为例,核心代码很简单:from django.db.models import Sum, Count, Avg from apps.vehicle.models import SaleRecord # 品牌维度聚合 brand_stats SaleRecord.objects.values(brand) \ .annotate(total_qtySum(quantity)) \ .order_by(-total_qty) # 时间维度趋势:按月品牌聚合 monthly_stats SaleRecord.objects \ .values(brand, sale_date__year, sale_date__month) \ .annotate(totalSum(quantity))注意 sale_date__year 和 sale_date__month 这种跨表字段查找语法,它是 Django 官方推荐的时间分组方式,比你先取出全部记录再在 Python 里循环分组高效得多。聚合之后的结果是 QuerySet,里面每个元素是字典,后面接一个 list() 转成 JSON 就能给前端用。常用指标我总结成了下面这张表,做接口设计时直接对着挑就行:分析主题统计指标聚合方式销量走势月度总销量、环比增长率Sum 时间分组品牌格局市场份额、销量排名Sum values(brand)价格分布均价、价格区间销量占比Avg / Count 区间分组纯电与插混类型销量比、增长率差值Sum values(category)充电设施省市覆盖率、快慢充占比Count values(province)电池衰减平均衰减率、温度相关性Avg / 线性回归这些指标看上去多,但你会发现底层用的都是 Django ORM 的四个函数:Sum、Count、Avg,再加一个 order_by 排名。真正复杂的是组合方式,而不是代码本身。4. 从 CSV 数据到可视化看板:全流程实现拆解理论讲完,下面进入实操。我按数据导入 → 后端统计接口 → 前端 ECharts 渲染三个环节逐步拆解,每个环节给可以直接复用的代码和踩坑提醒。4.1 数据采集与导入:为什么推荐 CSV 而不是爬虫很多同学一听说数据分析系统,第一反应就是写爬虫。我的建议是,如果你没有特别强烈的学习意愿,第一步先别碰爬虫,直接用现成的公开数据集(比如乘联会的中汽协数据、国内新能源平台的开源统计文件)导出 CSV 再导入系统。原因很直接:爬虫本身是一个独立的复杂度,涉及反爬、请求频率、页面结构变化,一旦卡住,整个项目的进度就会被拖垮。但完全不提爬虫也不行,因为答辩老师很可能会问你的数据从哪来。我的处理方式是:项目里保留一个 daemon/scripts/fetch_data.py 的脚本,说明这是可选数据更新模块,核心数据已经通过 Excel/CSV 批量导入,这个脚本用于定期更新补充。这样既展示了你有数据获取的能力,又不让爬虫成为项目阻塞点。CSV 导入的数据,要用 pandas 清洗。下面是我实际用的导入脚本:import pandas as pd from django.core.management.base import BaseCommand from apps.vehicle.models import SaleRecord class Command(BaseCommand): def handle(self, *args, **options): df pd.read_csv(data/sale_record.csv) # 清洗:去掉价格字段的单位,统一转 float df[price] df[price].astype(str).str.replace(万, ).astype(float) # 清洗:销量缺失值填 0,日期统一格式 df[quantity] df[quantity].fillna(0).astype(int) df[sale_date] pd.to_datetime(df[sale_date]).dt.date # 用 bulk_create 批量创建,避免一条一条 save objs [ SaleRecord( provincerow.province, cityrow.city, brandrow.brand, model_namerow.model_name, pricerow.price, sale_daterow.sale_date, categoryrow.category, quantityrow.quantity, ) for row in df.itertuples() ] SaleRecord.objects.bulk_create(objs, batch_size1000)这段代码里最值得说的是 bulk_create:如果你用 for 循环逐条 save(),一万条数据导入可能要一分钟以上;而 bulk_create 一次批量写入,基本是毫秒级。这个细节在答辩现场可以作为你考虑过程序性能的实证,很加分。4.2 后端统计接口的设计:JSON 序列化必须做对后端接口的职责很简单:接收前端参数(时间范围、品牌、地区),用 ORM 聚合,返回 JSON。在这个环节,新手最容易栽在日期类型序列化上。Django 视图里查出来的日期格式是 datetime.date,直接 json.dumps 会报错,提示 Object of type date is not JSON serializable。解决办法是定义一个自定义 JSON 编码器,或者顺手把日期转成字符串。通用做法是在项目里放一个 encoder:import json from datetime import datetime, date class DateEncoder(json.JSONEncoder): def default(self, obj): if isinstance(obj, (datetime, date)): return obj.isoformat() return super().default(obj)视图层返回时用 json.dumps(data, clsDateEncoder, ensure_asciiFalse) 就可以了。另外,前端请求跨域的问题在这里也顺便提一句:如果你是同一个 Django 项目里做前后端页面,Django 模板渲染的页面去请求自己的接口,不存在跨域;但如果你把前端独立成 Vue 项目,就必须配 django-cors-headers 或者在响应头里手动加 Access-Control-Allow-Origin。毕业设计建议直接用 Django 模板加原生 JS,省掉跨域这一层麻烦。接口清单我建议划分为这样几类,方便前端逐一对表:/api/overview/ — 总销量、总品牌数、总车型数、环比增长率/api/trend/?months12 — 月度销量趋势/api/brand_share/ — 品牌市场份额饼图/api/category_trend/ — 纯电与插混对比/api/price_distribution/ — 价格区间分布/api/charge_map/ — 各省充电桩数量接口返回结构统一成 {code: 0, data: [...], msg: success},前端判断 code 是否为 0 再渲染。这个规范虽然简单,但让前后端联调省了很多事。4.3 ECharts 渲染看板与异步刷新前端我用的是 Bootstrap 5 布局加 ECharts 5 图表。Django 模板里引入 ECharts 用 CDN 就能跑,不需要额外 npm 打包。把每个图表封装成一个函数,页面加载时发起 fetch 请求,拿到数据后用 setOption 渲染,是最简单可靠的方式。下面是一个典型的品牌市场份额饼图的模板代码:div idbrandShare stylewidth: 100%;height:400px;/div script async function loadBrandShare() { const resp await fetch(/api/brand_share/); const result await resp.json(); if (result.code ! 0) return; const chart echarts.init(document.getElementById(brandShare)); chart.setOption({ tooltip: { trigger: item }, series: [{ type: pie, radius: [40%, 70%], data: result.data.map(item ({ name: item.brand, value: item.total_qty })) }] }); } loadBrandShare(); /script复杂一点的图表是按时间区间联动的折线图。我的做法是在页面顶部放一个日期选择器或品牌下拉框,点击后重新请求后端接口,然后调用 chart.setOption(option, true) 里的第二个参数 true,表示完全替换旧配置而非合并。这个小细节如果不注意,会出现旧系列数据残留、图表不更新等问题。图表整体加载慢的问题也提一下:后端聚合查询加上前端一次性请求多条接口,如果数据量大,首屏可能白屏两三秒。解决方案是后端加 Django cache(内置的 local memory cache 就行),把耗时超过 500ms 的聚合结果缓存 5 分钟,前端首屏加载明显变快。代码很简单,在视图函数上手动操作即可:from django.core.cache import cache def brand_share(request): data cache.get(brand_share_data) if data is None: # 聚合计算 data list(...) cache.set(brand_share_data, data, 300) return JsonResponse({code: 0, data: data})这个先查缓存、缓存没有再查库的模式是生产系统里非常常见的优化手段,写进论文的性能测试小节也是实打实的加分内容。5. 真实踩坑记录:四类问题的完整排查链路这段我把我这几年帮学生调试项目时遇到的高频问题整理出来,每一条都给出完整的定位思路,而不是直接甩结论。你在自己的项目里遇到类似现象时,可以沿着这个链路去排查。5.1 时区配置导致按月聚合错位现象:页面上的月度销量折线图,3 月的数据有一部分跑到了 2 月底,或者每天凌晨 0 点到 8 点的新增记录被算到了前一天。定位链路:先看 Django settings 里的 TIME_ZONE 和 USE_TZ。默认配置是 TIME_ZONE UTC, USE_TZ True。这会导致所有 datetime 字段按 UTC 存储和比较,而你本地是东八区,日期边界就会偏移 8 小时。如果你存的是 DateField(而不是 DateTimeField),一般不会有这个偏移;但如果明细表里存了 DateTimeField 并直接用 annotate 按日期分组,问题就会出现。解决方案:如果你的数据全部是中国大陆业务,最省事的做法是 settings 里设 TIME_ZONE Asia/Shanghai, USE_TZ False。这样 Django 存储和比较时间完全按本地时间,不会做 UTC 换算。如果非要用 USE_TZ True,那就必须在每个查询前用 timezone.localtime() 转换再分组,复杂度明显增加。我建议毕设直接用 USE_TZ False,并把这个决策写进论文的系统环境配置说明里,老师反而会觉得你考虑过时区问题。5.2 大数据量下 ORM 查询过慢与索引优化现象:数据导入到 10 万行级别之后,按品牌聚合的接口响应时间从 200ms 涨到了 5 秒。定位链路:先说清楚为什么变慢。values(brand).annotate(Sum(quantity)) 这条 SQL 本质上是对 sale_record 表做 brand 分组扫描,如果 brand 字段没有索引,数据库就要全表遍历。10 万行在本地 MySQL 上全表扫描其实也还能接受,真正让响应变慢的是你把聚合结果拼成了 JSON 再返回,且前端还反复请求同一接口没有缓存。解决方案分成两层:第一层在数据库层面,给高频分组的字段加索引,在 Django models 里写为 brand models.CharField(max_length32, db_indexTrue),或者干脆在 Meta 里设置 indexes [models.Index(fields[brand, sale_date])]。加了联合索引后,按时间和品牌分组查询的代价大幅下降。第二层是代码层面,把聚合结果套上 cache,也就是上面提到过的 cache.get/cache.set 模式。两层都做完,响应时间基本能压到 200ms 以内。5.3 ECharts 数据更新但图表不变化的陷阱现象:同一个 ECharts 实例,第一次 setOption 数据正常,第二次后端数据变了,再 setOption 图表却不更新,出现旧数据残留。定位链路:这个问题的根子在于 ECharts 的 setOption 默认是 merge 模式,新数据会与旧 series 合并,而不是覆盖。比如 series 里原本有 10 个数据点,新数据只有 8 个,merge 之后可能还保留旧的 2 个点。解决方案:调用 setOption 时传第二个参数 true,即 chart.setOption(option, true),强制完全替换;同时每次渲染前先调用 chart.clear() 清掉画布。还有一个隐蔽问题:如果图表对应的 DOM 容器被前端框架重新渲染过(比如页面做了局部刷新),旧的 echarts 实例会绑定在已被替换的 DOM 上,导致 init 失败。解决办法是在 init 之前判断一下,如果已有实例就 dispose 再重新 init。5.4 静态文件 404 与模板路径混乱现象:页面能打开,但所有 CSS/JS 全部 404,浏览器控制台一大片红色报错。定位链路:Django 在开发模式(DEBUGTrue)下,静态文件由 django.contrib.staticfiles 提供,默认会从每个 app 的 static/ 目录和 settings 里配置的 STATICFILES_DIRS 找。如果你的项目是项目根目录下的 static而不是某个 app 内,必须把路径加进 STATICFILES_DIRS,否则找不到。解决方案:# settings.py STATIC_URL /static/ STATICFILES_DIRS [ BASE_DIR / static, ]还有一个坑:如果模板文件放在 templates/base.html 里引用了 {% static js/echarts.min.js %},但实际文件放到了项目根目录的 static 之外,就会 404。建议把所有静态资源全部统一放进根目录 static 下,CSS、JS、images、echarts 分好子目录,路径一旦固定就不要乱动。部署到服务器时再跑 python manage.py collectstatic 把所有静态资源汇聚到 STATIC_ROOT,这个问题就彻底闭环了。6. 文档写作与答辩演示:让工作量被看见代码做完只算完成了一半,毕业设计的另一半是文档和答辩。很多技术能力很强的同学恰恰栽在这里:系统功能做了很多,但文档写得空洞,答辩 PPT 演示流程混乱,老师抓不住重点,最后分数反而不高。6.1 毕设文档结构:哪些图和表是必须的一套完整的新能源汽车数据分析系统论文/设计文档,我建议严格按这个结构走:摘要、绪论(研究背景与意义、国内外现状)、相关技术介绍(Python/Django/MySQL/ECharts)、需求分析(功能需求与非功能需求)、系统设计(架构设计、模块设计、数据库设计)、系统实现(关键功能界面与代码逻辑)、系统测试(功能测试与性能测试)、总结与展望、参考文献、致谢。在系统设计这一章,有四张图是必须有的:E-R 图(实体关系图,展示用户、销量表、充电桩表、电池表之间的关系)、系统功能结构图(用树状图说明各模块层级)、时序图(以用户查看月度销量趋势为例画完整流程)、用例图(管理员和数据浏览者的核心用例)。这四张图不一定非要画得多规范,但不能缺失,因为老师判断你有没有完整地走完软件工程流程,看图比看文字快得多。6.2 演示环节的设计:把分析价值讲出来答辩演示只有几分钟,不要从头到尾点一遍系统菜单,那毫无意义。我的建议是设计一条发现问题 → 分析问题 → 得出结论的演示主线。举个例子,你可以这样演示:先打开总览看板,展示近 12 个月总销量趋势,指出销量在 6 月出现了明显波谷;再切换到品牌份额图,发现头部品牌在 6 月集中降价促销,但最终销量反而下降;再通过纯电与插混的对比图,发现波谷主要由纯电车型贡献,插混车型保持稳定;最后结合充电桩数据,展示当月充电桩投运数量并没有明显变化,排除充电便利性不足导致销量下降的假设。这套演示的逻辑链条非常清晰,哪怕你的分析结论并不完全科学,但用数据交叉验证的思路已经展示出来了,老师会觉得你真正理解了数据分析的核心价值,而不是做了一堆图表摆样子。6.3 答辩常见追问与应答策略答辩环节不可控因素很多,但高频追问其实就那几个,提前准备答案就好:你的数据从哪来,准确吗?——明确说明数据来源和清洗规则,大方承认数据非官方口径,强调系统重点是分析框架而非数据权威性。为什么用 Django 不用 Flask?——Django 自带 ORM、Admin、认证体系,适合完整信息系统开发;Flask 更灵活但不适合快速构建 REST 风格的管理与分析项目。你这个预测模块的准确率怎么保证?——如果只做了移动平均或线性回归,直接说这是简化模型,用于展示趋势方向而非精确预判,并说明后续可升级 LSTM 或 ARIMA。缓存机制的原理是什么?——把 local memory cache 的工作方式讲清楚:首次查询计算并写入缓存,后续请求直接读缓存,设置超时时间淘汰。这些应答的底层逻辑是:承认局限性,但强调系统设计的合理性和可扩展性。千万不要为了显得厉害而虚构没实现的功能,一旦被追问到细节就穿帮了。7. 扩展方向:预测模型与实时数据更新的平滑接入最后聊聊这个系统的进阶玩法。很多同学做完 MVP 之后还剩下两三周时间,想再往上叠一些亮点,我推荐两个性价比最高的方向,一个是销量预测模型,一个是爬虫定时更新。7.1 销量预测模块:先从简单的线性回归做起预测功能是听起来高级、实现起来不复杂的典型代表。建议第一步用 statsmodels 或 scikit-learn 里的线性回归做月度销量预测,特征取上个月销量、去年同期销量、品牌本身的市场趋势值,预测未来 3 个月的销量。代码量控制在 50 行以内,Django 视图里调用训练好的模型,返回预测值和历史对比值给前端 ECharts 画历史预测的延展折线图,演示效果极佳。如果要更专业一点,可以对时间序列做 12 阶差分,然后预测差分值再还原,这样能在 PPT 里写基于时间序列分解的预测方法;但注意提前告诉答辩老师,毕设体量下重点是流程演示,不是追求预测精度。7.2 爬虫定时更新与消息推送数据更新这块,如果确实想上爬虫,用 requests BeautifulSoup 就够了,不需要引入 Scrapy 搞得那么重。抓取逻辑放在 Django management command 里,然后接一个 APScheduler 定时任务,每天凌晨跑一次,更新数据后刷新缓存。网页端可以加一个最近更新时间提示条,让看板看起来像活的。如果你还想加后台有数据变化前端就实时推送,那就要上 Django Channels 和 WebSocket。这个方向对新手门槛略高,要在 ASGI 配置、channel layer、前端 WebSocket 客户端三个方面同时改。我的建议是除非时间充裕,否则不要轻易尝试,因为任何一个环节卡住都可能拖垮进度。真要做的话,先做一个新导入数据到达后刷新页面提示的最小版本,让链路跑通后再考虑实时图表更新。就我个人这几年的实际操作体会来说,毕业设计最值钱的从来不是代码本身,而是你完整走完一遍业务理解 → 技术落地 → 问题排查 → 文档表达的过程。这套新能源汽车数据分析系统做完,你不仅会对 Django 的 ORM、聚合查询、缓存机制有真实的体感,还能在答辩时自信地讲出每个图表背后的数据和计算逻辑,这比任何花哨的框架版本都更有说服力。最后再分享一个小技巧:把你在项目中踩过的坑和解决方案单独整理到文档附录里,答辩老师翻到这一页的时候,会比看到一堆截图更眼前一亮。