做毕设选这个方向基本等于把一个真实的电商业务问题搬进了校园——厨具作为典型的标准品消费品有清晰的品类划分、稳定的复购周期和明显的季节波动用机器学习去做销量分析与预测既有数据可挖又有业务逻辑可讲还能同时展示后端接口能力、前端可视化能力和算法落地能力。这几年我带过的毕业生里凡是选择这类“Django Vue 机器学习算法”组合的答辩效果普遍比纯CRUD管理系统好一截因为评委能看到的不是“又一个增删改查”而是一个能聊业务、能讲模型、能展示系统闭环的完整作品。这篇内容我会把整个项目从架构设计、数据处理、模型构建、系统实现到答辩准备完整拆开讲涵盖我实际做过的选型方案和踩坑经验希望能给正在做类似毕设或者想系统学习这套技术栈的同学一份能直接抄作业的参考。1. 项目整体设计与技术选型逻辑1.1 选题价值分析为什么是厨具用品销量分析与预测很多同学选毕设题目时容易犯一个错误为了“显得高级”硬上大厂架构或者冷门算法结果做完之后自己都讲不清楚业务价值。厨具用品销量预测这个题目的优势在于它属于典型的标准品电商场景业务逻辑好理解数据特征足够丰富又不会像服装、美妆那样受潮流影响导致预测难度失控。从业务角度看厨具品类的销售有非常明显的规律可循锅具在秋冬和年货节前后销量攀升刀具、砧板在装修季和开学季有需求波动餐具套装在节庆礼品场景下有明显峰值。这些规律性让机器学习模型有东西可学也让预测结果有业务解释空间。你不需要真的把预测做到多精准关键是能证明“模型捕捉到了数据中的规律”并且系统里能把这个过程完整呈现出来。这个题目的另一个优势是数据获取难度低。如果不想爬第三方平台数据完全可以用Python脚本按业务规则生成一份带明显季节趋势和周规律的模拟销售数据这部分我在后面会详细说。对毕设来说真实的业务闭环远比数据本身的真实性重要。1.2 技术选型Django Vue 机器学习算法的搭配逻辑技术栈的选择直接决定了开发的效率和答辩内容的呈现效果我最终确定的是这一套组合后端Django Django REST Framework MySQL前端Vue 2 Element UI ECharts Axios算法侧Python Pandas Scikit-learn XGBoost Statsmodels为什么用 Django 而不是 Spring Boot对毕设场景来说Django 最大的优势是和 Python 机器学习生态无缝衔接。你用 Pandas 处理好的数据、用 Scikit-learn 训练好的模型在 Django 里可以直接调用不需要额外写一层跨语言服务。Django 自带的 Admin 后台还能直接管理商品、订单等数据开发效率比 Spring Boot 高不少这对时间紧凑的毕设来说很关键。如果你将来走 Java 方向Spring Boot 当然更好但就这个题目而言Django 是性价比最高的选择。前端选 Vue 而不是 React主要考虑到 Vue 的中文生态对新手更友好Element UI 组件库能快速搭出后台管理界面ECharts 做数据可视化图表也非常顺手社区里能抄的代码多遇到问题找解决方案容易。这套组合本质上就是拿成熟框架的“确定性”去换开发效率毕设阶段不要追求框架的新鲜感要追求能稳定交付的熟悉度。算法层的选择同样考虑到了可解释性和实现成本。ARIMA 适合做单变量时间序列基线随机森林和 XGBoost 能充分利用多维度特征LSTM 作为深度学习代表可以体现技术层次。三个模型做对比实验用指标说话答辩的时候这就是实打实的内容。1.3 系统功能模块与数据流设计一个完整的厨具销量分析和预测系统功能上必须覆盖“数据管理、分析展示、销量预测、用户交互”四层。具体模块划分如下用户模块注册、登录JWT认证、个人信息管理商品模块厨具商品信息的CRUD包括品类、价格、库存等字段订单模块销售订单数据的导入、查询和统计分析数据可视化模块销售趋势折线图、品类分布饼图、地域销量柱状图、热销商品排名等销量预测模块选择模型和商品返回未来30天预测结果并可视化后台管理模块Django Admin 管理所有数据表数据流向是MySQL 中的订单数据 → Pandas 预处理和特征工程 → 训练好的模型文件.pkl/.joblib→ Django 视图读取模型并生成预测 → JSON 返回给 Vue 前端 → ECharts 渲染图表。这个设计里有一个关键点训练过程不应该出现在用户请求链路中。我实践下来的做法是离线训练好模型并保存为文件用户点击预测时直接加载模型文件推断结果这保证了接口响应速度毫秒级也回避了并发请求时模型同时训练的坑。2. 数据处理与机器学习模型构建2.1 数据准备从业务规则模拟到真实数据预处理数据是所有后续工作的地基。没有现成的厨具销售数据时我自己写了一个数据生成脚本核心思路是让模拟数据具备真实业务的基本统计特征季节性趋势10月到次年2月为销售旺季系数在1.2~1.5之间6到8月为淡季系数在0.7~0.9之间周规律周末和电商大促日销量高于工作日商品差异锅具类单价高销量低餐具类单价低销量高随机噪声加入高斯噪声模拟真实波动生成了2019年1月到2024年12月约10万条订单记录关联了80个厨具商品覆盖锅具、刀具、餐具、厨房小家电、收纳清洁五大类。这里要特别提醒如果后续能拿到真实数据预处理流程也基本一样。第一步处理缺失值销量和金额字段不能为空缺失的记录直接剔除或按品类均值补全第二步处理异常值我通常用 Z-Score 方法Z 值绝对值超过 3 的记录标记为异常比如单日销量突然变成平时100倍这类记录要么修正、要么剔除否则会严重干扰模型训练。数据质量在毕设答辩中很容易被评委问到你要能明确说出“我的数据经过哪几步处理每一步解决了什么问题”。只说一句“用Pandas清洗了数据”是远远不够的。2.2 特征工程让销量数据从“数字”变成“模型能学的规律”很多人在毕设里只拿“日期 历史销量”两个字段去训练模型结果预测效果很差然后归咎于算法不行。实际上问题往往出在特征工程上。我构建的特征主要分四类时间特征月份、星期几、是否月初/月末、是否节假日。这些特征能帮模型抓住季节性和周期性规律。比如“是否周末”这个0/1特征对餐具和厨房小家电的销量影响非常显著。商品特征品类、价格带、是否新品。厨具品类中锅具和刀具是刚需品销量波动相对小厨房小家电则更容易受促销和季节影响。把商品ID和品类做标签编码后直接作为特征输入模型能学到品类的差异性。历史统计特征过去7天、14天、30天销量的均值、最大值、标准差。这类特征本质上是让模型能“回头看”用近期的销量表现来推断未来趋势。滞后7天的销量lag_7往往是最重要的特征之一因为它直接对应了周周期。外部事件特征是否双11、是否年货节、是否618。厨具促销期的销量通常是平时的3到5倍如果模型不知道这个信息会把这些峰值当成异常点。我在实践中用 SHAP 值检查过特征重要性排名靠前的通常是 lag_7、lag_14、月份、是否节假日。这说明厨具销量确实存在强周期性和季节性业务逻辑和数据表现是吻合的。2.3 模型选型与对比实验ARIMA、随机森林、XGBoost 与 LSTM模型部分的思路是“从简单到复杂”做对比而不是只挑一个模型跑完就交差。这样做的好处有二一是能通过实验说明你为什么最终选择某个模型二是答辩时有对比图表可展示比单模型更有说服力。ARIMA作为统计基线模型。它的优势是可解释性强但只能处理单变量时间序列无法加入商品特征和节假日特征。我实现了月度粒度的 ARIMA(2,1,2) 预测作为最低参考线。随机森林基于树的集成方法天然支持多特征输入训练快不需要对特征做缩放也不容易过拟合。作为机器学习代表的典型模型是整套系统中的主力模型之一。XGBoostGBDT的进阶版加入了正则化项、列采样和并行化。在实际测试中XGBoost 通常比随机森林准确率高3%~5%尤其在有明显的周期规律和少量异常峰值的场景下。LSTM作为深度学习代表理论上能捕捉长时序依赖。但它的短板也很明显需要的数据量大、训练时间长、调参复杂。对于10万条订单级别的数据LSTM 的优势其实很难发挥出来最终效果通常不会比 XGBoost 好太多。训练时一个容易被忽略的重点是时间序列的数据划分不能随机打乱。我先把商品维度合并成整体日销量序列然后按时间顺序切分前80%作为训练集后20%作为验证集。如果像普通分类任务那样用 train_test_split 随机划分就会出现“用未来数据预测过去”的数据泄露结果虚高但没有实际意义。2.4 模型评估与选择标准评估指标我用了三个MAE平均绝对误差、RMSE均方根误差和MAPE平均绝对百分比误差。三个指标各有侧重MAE 反映平均偏差的绝对值RMSE 放大较大误差的惩罚力度MAPE 则是百分比指标方便向非技术背景的人解释“预测偏差大约几个百分点”。在我实际跑的实验中日销量级预测的结果大致是模型MAE件RMSE件MAPEARIMA48.267.515.6%随机森林36.853.112.3%XGBoost32.547.210.8%LSTM33.749.811.5%结论很明确XGBoost 在厨具销量预测场景下综合表现最好LSTM 在数据量级内没有显示出优势。你可以把这个结论写进论文然后解释原因厨具销量数据的周期性规律比较稳定树模型能很好地处理周期性特征和离散特征的组合而深度学习在更长时间序列、更复杂非线性模式的数据上才更容易发挥威力。2.5 模型落地训练到部署的正确姿势模型训练好之后我用 joblib 把 XGBoost 模型保存为 xgb_model.joblib 文件放在 Django 项目的 model_storage 目录下。Django 侧在预测接口中这样加载和调用import joblib import pandas as pd model joblib.load(model_storage/xgb_model.joblib) def predict_sales(request): # 从请求中获取商品ID和待预测天数 # 构造预测所需的特征DataFrame test_df pd.DataFrame([...]) prediction model.predict(test_df) return JsonResponse({prediction: prediction.tolist()})这个方案的好处是模型加载一次后可复用不用在每次请求时重新训练。实际部署时注意环境一致性训练环境和Django运行环境需要安装相同版本的 XGBoost 和 Pandas否则可能出现模型文件加载失败或者特征顺序不一致的问题。提示保存模型前务必将训练时用到的特征列顺序固定下来可以写一个 FEATURE_COLUMNS 常量训练和预测时都用这个顺序构建 DataFrame这是新手最容易踩的坑之一。3. Django 后端与 Vue 前端核心实现3.1 Django 数据库设计与 Model 实现系统核心表设计如下UserProfile用户扩展表关联 Django 自带的 User 表存昵称、头像Category商品分类表id、名称、优先级排序Product商品表id、分类外键、名称、描述、价格DecimalField、库存IntegerField、是否上架BooleanFieldOrder订单表id、订单编号、商品外键、销售数量、成交金额、销售日期、地区、支付方式PredictionRecord预测记录表id、商品外键、模型名称CharField存 xgboost/rf/lstm、预测起始日期、预测结果JSON格式存储、创建时间其中 Order 表是分析的主表销售日期字段建议用 DateField 而不是 DateTimeField因为日粒度分析是常态用 DateTimeField 反而会在聚合查询时因为时区问题出各种莫名其妙的偏差。Django Model 的写法大致是class Order(models.Model): order_no models.CharField(max_length64, uniqueTrue) product models.ForeignKey(Product, on_deletemodels.CASCADE) quantity models.IntegerField() amount models.DecimalField(max_digits10, decimal_places2) sale_date models.DateField() region models.CharField(max_length32)这里注意一点Order 表的数据量会达到十万级如果每次统计都用 ORM 遍历所有记录再在 Python 里聚合前端接口会慢到让你怀疑人生。正确的做法是在 ORM 层用 annotate 和 values 直接做 SQL 级聚合比如按月统计销量from django.db.models.functions import TruncMonth from django.db.models import Sum monthly_sales ( Order.objects .filter(sale_date__gtestart_date, sale_date__lteend_date) .annotate(monthTruncMonth(sale_date)) .values(month) .annotate(totalSum(quantity)) .order_by(month) )这段代码生成的 SQL 会在数据库层面完成分组求和比 Python 循环快几十倍。毕设阶段学会用 ORM 聚合不仅代码简洁答辩时提到“使用 ORM 自动生成优化后的 SQL 查询”也是一个加分点。3.2 Django REST Framework 接口设计与认证方案后端我采用 DRFDjango REST Framework设计接口遵循 RESTful 风格。主要接口如下方法路径功能说明POST/api/auth/register用户注册POST/api/auth/login用户登录返回 JWT tokenGET/api/products商品列表支持按分类筛选GET/api/sales/trend销售趋势支持按时段、品类聚合GET/api/sales/category-distribution品类占比统计GET/api/sales/hot-products热销商品排行POST/api/predict提交预测请求GET/api/predict/history获取当前用户的预测历史认证方案选了 djangorestframework-simplejwt登录返回 access token 和 refresh token。前端在 axios 请求头中携带Authorization: Bearer token。预测接口必须登录后才能调用但销售统计展示页可以匿名访问这样既保证了用户参与感又不影响评委快速浏览系统。DRF 的序列化器、权限类、视图集配置网上资料很多我不展开代码细节但要强调一个“接口设计规范”层面的建议返回结构的格式要统一。我在项目里定义了一个统一的响应格式{ code: 0, message: success, data: { } }这样前端处理异常时只需要判断code是否为 0不需要为每个接口单独写错误处理逻辑。3.3 Vue 前端架构与 ECharts 可视化方案Vue 端采用 Vue 2 Element UI 搭建创建方式直接用vue create或者 Vite 都行。目录结构上我把核心模块拆为views/Dashboard.vue数据概览大屏放核心 KPI 卡片和趋势图views/Analysis.vue多维分析页放品类分布、地域分析、热销排行views/Predict.vue销量预测页提供模型选择和预测展示views/Product.vue商品管理页store/Vuex 管理用户信息和 tokenapi/封装 axios 请求模块ECharts 是可视化的核心。我建议按需引入而不是全量引入这样能显著减少打包体积。在 Vue 组件中折线图初始化逻辑大概是import * as echarts from echarts; // 按需引入需要用到的图表和组件 echarts.use([LineChart, BarChart, PieChart, GridComponent, TooltipComponent, LegendComponent]); const chart echarts.init(this.$refs.chart); chart.setOption({ xAxis: { type: category, data: monthList }, yAxis: { type: value }, series: [{ type: line, data: salesData, smooth: true, areaStyle: { opacity: 0.3 } }] });有一个实践中的关键问题图表在页面切换或窗口缩放时可能不渲染或者错位。需要调用chart.resize()并设置防抖同时在组件beforeDestroy()时用chart.dispose()释放实例避免内存泄漏。另外如果 tab 页签切换时图表容器初始是隐藏的需要在nextTick后再初始化否则取的容器宽度是 0。3.4 前后端联调与部署易踩的坑前后端分离最大的坑就是跨域。Django 后端默认不允许前端域名调用接口需要在后端安装django-cors-headers# settings.py INSTALLED_APPS [ corsheaders, ... ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, http://localhost:8080, ]在开发阶段更省事的做法是设置CORS_ALLOW_ALL_ORIGINS True但这里要注意这只是本地开发调试用的部署到公网环境时一定要把这个选项关掉明确指定允许的源域名避免接口被任意跨域站点调用。部署方案看答辩环境灵活选择。如果答辩是在教室局域网内演示最简单的方式是 Django 跑在 8000 端口Vue 用npm run dev跑在 5173 端口两台设备在同一个网络下即可。如果要求打包为静态文件形式可以执行npm run build生成 dist 目录然后通过 Nginx 把 Vue 的静态页面和 Django 的 API 反向代理到同一个域名下。注意不管哪种部署方式数据库的字符集都是必须提前确认的点。MySQL 建库时使用utf8mb4字符集否则存储商品描述里的特殊符号、表情或者中文时可能出现乱码。4. 答辩准备、常见问题与踩坑实录4.1 项目亮点包装从“做完了”到“讲得好”做毕设和说毕设是两码事。很多同学系统做完以后答辩时只会说“我用 Django 写了后端用 Vue 写前端调了下模型”这等于把亮点全埋没了。我建议项目包装时突出以下几个点模型对比实验强调系统不是单模型演示而是对 ARIMA、随机森林、XGBoost、LSTM 做了系统的对比实验并通过 MAE、RMSE、MAPE 三个指标定量评估。这意味着你做了完整的实验设计而不只是调包。业务闭环从数据采集、清洗、特征工程、模型训练、模型部署到前端可视化全链路打通。很多毕设只做算法分析不出系统只做管理系统的又没算法你是两者融合这是项目的核心差异点。特征工程细节讲清楚数据从原始字段如何转换成模型输入特别要提“时间特征 历史统计特征 外部事件特征”的组合思路以及为什么不能只拿日期和历史销量做输入。模型可解释性如果用了 SHAP 或特征重要性排序答辩时说“我不仅知道模型预测结果还能解释哪些因素驱动了销量变化”这类内容是评委很看重的工程素养体现。4.2 答辩高频问题应答思路根据我带过的毕设答辩经验评委针对这个题目的提问高度集中在这几类Q1你的数据是哪来的如果模拟数据可信度怎么保证答先用业务经验构造数据生成规则让数据具备合理的季节性、周期性和噪声然后对生成结果做了统计分布校验必要时做敏感性分析。如果项目里能引入一段真实数据的对比验证说服力更强。Q2为什么选 XGBoost既然 LSTM 是深度学习为什么效果没有更好答厨具销量数据在日粒度上存在明显的周期和季节模式树模型对表格型特征组合的表达更直接而 LSTM 需要更大数据量和更长序列才能发挥优势。实验数据支持 XGBoost 在该数据集上用时更短、精度更高。Q3如果未来出现突发事件比如疫情、平台大促政策突变模型能应对吗答模型基于历史规律学习对未出现过的事件模式天然无法预测。可以讨论引入外部特征促销计划、节假日日期来缓解但任何模型都无法完全应对全新事件这是预测问题的本质边界。Q4系统的可扩展性怎么体现答预测模块以模型文件独立保存新增模型只需添加配置不用改代码数据层是标准 MySQL 表结构可以平滑扩容后端接口采用 RESTful 规范未来可以对接小程序、移动端。这些问题的回答思路不是死背答案而是体现你“想清楚了”。能逻辑自洽地给出解释比背出标准答案更能打动评委。4.3 实操过程中踩过的坑与解决实录这个项目我做了三版才彻底跑通最大的几个坑现在说出来希望大家避开时区问题导致日销量统计错乱。Order 表用 DateTimeField 存储时间Django 时区设置为 UTC直方图统计总是差 8 小时导致有些天的销量被算到前一天。后来也发现是 MySQL 连接时区没对齐解决方法是连接数据库时在 Django settings 中把TIME_ZONE Asia/Shanghai、USE_TZ False同时订单日期字段改用 DateField。这个事情告诉我所有的时间字段要统一时区口径否则统计结果就是歪的。训练集和测试集随机划分导致数据泄露。第一版用 train_test_split 随机切分数据MAPE 跑出 4.8%我当时还挺高兴。后来仔细一看每天的样本同时出现在训练集和测试集里模型相当于“看着答案考试”指标完全失真。改成按时间序列前 80% 训练、后 20% 验证之后MAPE 从 4.8% 变成了 10.8%这个教训比学会一个模型更宝贵。ECharts 在隐藏容器中初始化为宽度 0。Vue 的 tab 页签切换后图表不显示原因是el-tab-pane在懒加载模式下初始宽度为 0。解决方案是图表初始化放在$nextTick回调里并监听窗口 resize 事件调用chart.resize()。另外在切换 tab 时可以用v-if控制图表组件的渲染时机确保容器已挂载。XGBoost 模型文件在跨环境加载时出错。训练环境 Python 3.10 XGBoost 2.0运行环境 Python 3.9 XGBoost 1.7加载模型直接报版本不兼容错误。以后做的对策是训练和部署用同一 Docker 镜像或者把模型保存时用save_model而不是joblib.dumpXGBoost 自带的序列化格式跨版本兼容性会好一些。Django ORM 查询 N1 问题。展示销售排行时在 Python 循环里逐条查商品信息商品数量一多接口响应就要 3 秒以上。后面用select_related和prefetch_related优化关联查询加上数据库索引按sale_date和product_id建索引响应时间从 3 秒降到了 200ms 以内。接口性能优化是很多人忽略的技能答辩现场演示时直接关系演示是否流畅。4.4 给正在做类似毕设的同学几点额外建议如果你现在正在做或者准备做类似题目下面这副经验是我踩过坑后攒下来的第一不要一开始就写代码先把数据库表结构设计清楚。建表之前花两天时间把字段、类型、关联关系、索引规划好后面几乎不会返工。我见过太多同学代码写了半个月才发现表缺字段然后满项目地改非常痛苦。第二模型离线训练脚本和 Django 项目分开建目录管理。训练脚本放在ml_pipeline/目录下Django 项目在backend/目录下两个目录共用一套虚拟环境但互不干扰。训练脚本里定义特征工程的公共函数Django 预测接口中直接引入。这样模型训练的流程和数据加载过程是清晰的答辩时给评委展示代码结构也会加分。第三给前端页面做点“有细节”的设计。主流的管理系统模板都是左侧菜单 顶部栏 内容区但你可以加两个维度让系统看起来更完整一个是数据大屏概况页用几个数字卡片展示总销量、销售额、订单量、预测准确率从视觉上就有数据产品的味道一个是预测彩带图展示历史真实值和未来预测值的对比区域用浅色背景区分预测区间让评委一眼看懂系统在做什么。4.5 答辩演示流程设计建议答辩演示通常只有 10~15 分钟演示流程设计也很重要否则容易超时或者演示到一半出状况。建议按这个流程走业务背景1分钟一句话说清楚厨具用品销量分析和预测的价值系统架构1分钟用一张架构图说明四层结构数据分析和可视化演示2~3分钟展示销量趋势、品类分布、热销排行三个核心图表模型训练效果说明1~2分钟展示模型对比表格重点关注 MAPE 指标的改进预测功能演示2分钟现场选择商品并点击预测按钮展示 ECharts 生成的未来预测曲线创新点总结1分钟模型对比、特征工程、完整闭环流程演示里最需要提前彩排的是第 5 步。预测接口如果因为加载模型太慢或者内存不足卡住前面所有铺垫都白搭。我的做法是项目启动时就预加载模型到全局变量再在系统日志中记录模型加载时间现场演示时保证 200ms 内返回结果。万一现场网络有问题也建议准备一个截图的备选方案切到截图演示也能继续讲。5. 最后再说几句实在话厨具销量分析预测这个题难度上刚好卡在一个甜点区业务好讲、算法好落地、系统好展示。但真正把它做扎实靠的不是会几个框架的 API而是能不能把“业务理解、数据处理、模型实验、工程实现”这条链路串得通。我自己做完最大的感受是代码量大的项目不等于好项目能让每个环节都自洽、有说服力的项目才是真的好项目。希望这篇分享能帮你在做毕设的路上少走几个弯路祝答辩顺利。