1. 项目全貌这套系统到底在做什么1.1 核心需求拆解先说清楚这个项目到底是个什么东西。如果你正在找毕业设计方向或者想了解全栈项目是怎么把推荐、可视化、数据处理这几个模块串起来的那这套“农产品推荐系统”是一个很典型的样本。它不是一个只写几个页面的展示项目而是一个能跑通完整业务闭环的系统后端负责业务逻辑和数据计算前端负责交互展示中间通过接口通信最后形成一套可演示、可扩展、可写进毕业论文的完整成果。项目标题里的三个关键词分别对应三个核心模块推荐系统根据用户的历史行为、偏好标签从农产品库中筛选出可能感兴趣的商品前端展示“猜你喜欢”之类的推荐列表。可视化把农产品价格、销量、产地分布等数据做成图表让人一眼看懂趋势和结构而不是面对一堆Excel数字发呆。大数据处理这里说的“大数据”不是几十台服务器跑Spark那种级别而是指系统要能处理足够量的真实或模拟数据通过合理的数据清洗、统计分析支撑推荐和可视化模块的运转。很多同学看到这种项目名会先被“大数据”三个字吓住实际上不用。毕业设计语境下的大数据核心是看你会不会把数据从原始状态变成有价值的信息。用Django做ORM模型、用Pandas做数据清洗、用ECharts做可视化已经完全够了。1.2 技术选型的真实考量为什么用DjangoVue.js这套组合我直接说结论它是目前全栈类毕业设计里“性价比最高”的搭配之一而且各部件角色非常清晰。Django是Python生态里最成熟的后端框架。它内置了ORM、Admin后台、认证系统、路由分发这意味着你不需要自己去实现用户登录、数据库建表、请求参数校验这些基础功能。对毕业设计来说省下来的时间可以全部投入推荐算法和业务逻辑而不是去造轮子。更重要的是Python本身就是做数据分析、推荐算法最顺手的语言你在写协同过滤、相似度计算时可以直接用Pandas和NumPy不需要跨语言做数据转换这一点比Java系框架顺手非常多。Vue.js负责的是前端展示层。它的核心优势是组件化开发页面上的推荐卡片、图表区域、搜索筛选区可以拆成独立的组件各自维护状态互不干扰。第一次接触前端的同学可能觉得Vue比传统模板渲染多了一层抽象但一旦你熟悉了数据绑定和生命周期开发效率会比写jQuery高一个量级。而且Vue对ECharts的支持非常友好图表初始化、数据更新、销毁都有对应的生命周期钩子不用像写原生JS那样手动去管理DOM。有人会问那为什么不选SpringBootVue或者纯Django模板渲染因为SpringBootNginx你大概率还得自己去处理数据库连接池和繁琐的配置纯Django模板又无法做出足够的交互感和现代感。毕业设计答辩时评委第一眼看到的是前端页面第二眼才看代码和文档。一个交互流畅、图表丰富的页面在第一印象上就已经赢了一半。1.3 整体架构与数据流整套系统的请求链路是这样的用户在浏览器里点击Vue页面 → 页面通过axios向后端发送HTTP请求 → Django的URL路由把请求分发给对应的视图函数 → 视图从数据库读取或写入数据 → 数据经过处理比如推荐算法计算后以JSON格式返回 → Vue拿到JSON后更新页面状态 → 图表和推荐列表刷新。数据库层面用MySQL或SQLite都行。个人建议本地开发用SQLite起步等所有功能跑通了再迁移到MySQL。理由很简单SQLite是单文件数据库不依赖独立服务启动零配置非常适合前期快速验证。你不需要像MySQL那样额外安装服务、配置用户权限、处理端口占用复制到任何一台电脑上都能直接调试。到了打包部署阶段再迁到MySQLDjango的ORM屏蔽了底层数据库差异迁移成本非常低。这种“前后端分离”的架构还有一个好处可以并行开发。你让一个人专门写后端接口一个人专注前端页面只要接口约定好了两边互不阻塞。对组队做项目的同学来讲这条价值无法忽略。2. 农产品推荐系统的核心逻辑2.1 推荐策略内容过滤与协同过滤结合推荐系统是整个项目里最有内容可写的模块。农产品推荐和普通电商推荐有一点重要的差异农产品的生命周期短、季节性强、价格波动大用户对“新鲜”和“产地”的敏感度远高于对“品牌”的敏感度。所以推荐策略不能简单套用“买了A的人还买了B”这种通用电商逻辑。我在这个项目里采用的是“内容过滤协同过滤”结合的策略。内容过滤的思路是给每个农产品打上特征标签比如类别水果/蔬菜/粮油、产地、价格区间、季节性特点、营养价值标签。用户注册时会先选择自己的偏好之后系统根据这些偏好计算物品与物品之间的相似度把最相似的商品推荐给他。协同过滤则更进一步它不依赖物品的显式标签而是通过用户行为来寻找规律。如果用户A和用户B在历史上的浏览记录、购买记录高度重合我们就可以把B近期关注过的商品推荐给A。这个逻辑对农产品同样适用比如两个注重健康饮食的用户都频繁购买西蓝花、紫甘蓝这类高纤维蔬菜系统就可以在他们之间互相补充推荐。两种策略各有优劣。内容过滤容易理解、冷启动时也能推荐但推荐结果容易“千篇一律”协同过滤能发现用户自己都没意识到的需求但新用户没有行为数据时完全无法工作。所以实践中通常先做内容过滤兜底等用户积累了一定的行为数据再逐步叠加协同过滤的结果最后用加权融合的方式生成最终推荐列表。2.2 关键算法实现思路具体实现时我推荐用最经典的“基于物品的协同过滤”作为骨架理由是整个流程清晰且可控。你在论文里能讲清楚“步骤一建立评分矩阵步骤二计算物品相似度步骤三生成推荐列表”评委听着很舒服你写代码也不容易走偏。典型步骤如下从数据库中取出所有用户的历史行为记录包括浏览、加入收藏、购买等动作转换成用户对物品的“隐式评分”。评分规则可以自定义比如浏览记1分、收藏记3分、购买记5分这样同一个用户对不同商品就有了不同的偏好权重。构建“用户-物品”评分矩阵。矩阵的每一行代表一个用户每一列代表一种农产品。没有交互就填0有交互就填对应的隐式评分。计算物品之间的相似度。推荐用余弦相似度。公式的本质是把每列数据看成一个向量两个向量的夹角越小说明这两个物品在用户行为上越接近。在NumPy里直接用cos_sim np.dot(A, B) / (np.linalg.norm(A) * np.linalg.norm(B))就能算出来。找到和用户已购买商品最相似的Top-N个商品排除掉用户已经买过的就得到推荐列表。这里有一个容易被忽略的细节温度补偿。农产品是有季节性的你在计算相似度时可以额外加一个时间权重。比如西瓜在夏季的推荐权重应该高于冬季。具体做法可以是给评分矩阵加时间衰减因子行为时间距离当前越近评分权重越高。这样系统就不只是“根据历史猜你想买”而是“根据历史加当前季节猜你想买”听起来也更有逻辑深度。2.3 推荐效果的评估与优化推荐做完了怎么证明它好用答辩时大概率会被问到。如果你自己都不清楚推荐效果怎么评估这个问题会非常尴尬。基础的做法是离线划分数据集。把用户行为数据按时间先后分成训练集和测试集比如前70%的数据用来生成推荐规则后30%的数据用来验证。在测试集里统计“用户实际发生交互的商品中有多少是系统推荐出来的”这个指标叫召回率统计“系统推荐的商品中有多少用户真的交互了”这个指标叫准确率。两者是此消彼长的关系通常看F1值来综合评估。更好看一点的做法是手动构造几个用户画像做对比测试。比如创建一个“偏爱水果的用户”做20次交互创建一个“偏爱低脂蔬菜的用户”做20次交互。然后看推荐结果是否和他们的画像对齐。这比冷冰冰的数值指标更能打动评委因为评委能直观看到系统的推荐逻辑是符合预期的。我做这套系统的时候明显感受到一个规律推荐准不准算法只占一半数据质量占另一半。如果你的行为数据是临时造出来的而且分布完全随机那再好的协同过滤也输出不了有意义的结果。造测试数据时要有意识地模拟真实场景比如访谈一些用户粗略记录他们的购买习惯再把这些习惯翻译成行为数据。这样产出的推荐结果才具备说服力。3. 农产品可视化模块这样落地3.1 用ECharts展示的数据维度可视化不是单纯“画个图”就完事关键是选择合适的图表类型对应合适的业务问题。农产品系统里我认为必须呈现四个方面第一价格趋势图。每种农产品在一段时间内的价格走势用折线图呈现横轴是日期纵轴是价格。这张图解决的问题是“这东西最近是涨还是跌”。很多用户买农产品前最关心的就是这个也可以顺势引出“推荐低价时段的优质农产品”这个功能点。第二品类分布图。统计当前农产品库里各类产品蔬菜、水果、粮油、肉类、水产的数量和比例用饼图或环形图。这张图的意义在于让用户快速了解平台的产品结构。第三产地分布图。用中国地图或柱状图展示不同农产品产地的供货量。地图类的可视化会直接拉升整个项目的感觉而且它在技术实现上并不难ECharts官方就有地图组件的地理数据你只需要把各省市的农产品数量汇总成JSON格式填充进去。第四销量排行图。以柱状图或横向条形图展示一段时间内销量Top10的农产品。这张图对运营决策最有价值能直观告诉商家“哪些产品是主力产品”。3.2 前端组件设计与交互在Vue项目里我建议把每个图表封装成独立的组件统一放到src/components/charts目录下。每个组件接收一个data属性内部负责初始化ECharts实例和更新配置。这样做的最大好处是图表逻辑和页面业务逻辑彻底分离页面上只需要写一行“传数据进去”的代码图表就能自己跑起来。以价格趋势图为例组件内部的核心逻辑是watch: { data: { handler(newVal) { this.chart.setOption({ xAxis: { data: newVal.map(item item.date) }, series: [{ data: newVal.map(item item.price) }] }); }, deep: true } }用watch监听数据变化这比手动调用setOption要优雅很多。数据一旦更新图表自动跟着刷新你不用关心是用户切换了产品类别还是时间范围。图画完之后交互不能少。至少要有两个交互点一个是图表的tooltip提示框鼠标悬浮时显示当前时间点的具体数值和涨跌幅另一个是点击图表时的高亮效果。ECharts里这些基本是配置项几行代码就能实现但效果非常直观答辩演示时能明显提升用户体验的感知。3.3 可视化的几个坑ECharts用起来不难但有几个坑我必须帮你踩掉。每个页面首次加载后出现警告“容器没有宽度或高度”原因是你给图表的父容器设置了display: none或者容器尺寸还没渲染完成就调用了init。解决方法有两个一是确保图表容器有明确的width: 100%; height: 400px这种固定尺寸二是在mounted生命周期里延迟调用初始化或者用Vue的$nextTick等待DOM完全渲染后再初始化。当页面包含选项卡切换不同的Tab页签时隐藏的那个图表可能会变形宽高变成0。原因是DOM重新布局后ECharts实例不知道该调整自己的尺寸。解决办法是在Tab切换完成后调用chart.resize();用ECharts自带的resize方法强制重新测量容器大小。还有一个数据格式问题。ECharts要求数据字段必须结构一致比如折线图的date字段必须是时间字符串你不能在这里拿到的是“2025-06-01”、那里拿到的是“06/01/2025”。建议在Django后端序列化数据时就统一格式不要指望前端做兼容性修复。后端多几行代码前端省一晚上的Debug时间。4. 农产品大数据处理部分并没有那么“高不可攀”4.1 大数据在毕业设计里的边界“大数据”这个词在项目名里很大但落到实操上你要做的是把一套能够处理较大数据量的流程跑通而不是真的去搭建分布式集群。毕业设计时间有限没有哪个评委期待你用Hadoop跑农产品数据那不是明智的选题策略。更现实的做法是用Pandas在Python里处理数据用Django ORM做数据库交互数据量控制在几千到几万条就能充分展示“大数据处理”的核心能力。真正有价值的是数据处理流程本身数据从哪来、怎么清洗、如何入库、怎么被上层业务使用。能把这条链路讲明白你的论文已经有了扎实的实践支撑。4.2 数据采集、清洗与导入数据来源是这个项目里的一个隐患。如果你没有真实的农产品数据千万别直接编造几万条假数据丢进数据库那样后续推荐和可视化全都会失真。我的做法是分三步走第一步从公开的农业数据源或市面上已有的农产品价格数据文档中收集一些真实的年度价格与销量数据。不需要多全有一两个月的历史记录就够了。第二步用Pandas做清洗。这一步关注三件事去重、缺失值填充、类型转换。如果你拿到的数据是price: 5.5元/斤这种带单位字符串直接存进数据库没法计算必须先提取出数值部分并转成FloatField。我用一个简单的活用的例子import pandas as pd df pd.read_csv(agri_data.csv) df[price] df[price].replace([元/斤], , regexTrue).astype(float) df[sales_date] pd.to_datetime(df[sales_date]) df df.dropna(subset[name, price]) df df.drop_duplicates(subset[name, sales_date, region])第三步把清洗后的DataFrame导入MySQLfrom django.core.management.base import BaseCommand class Command(BaseCommand): def handle(self, *args, **options): df pd.read_csv(cleaned_agri_data.csv) for _, row in df.iterrows(): Product.objects.update_or_create( namerow[name], defaults{price: row[price], region: row[region]} )用update_or_create而不是直接create这样重复导入时不会报唯一性错误也支持增量更新。4.3 数据统计与关联分析大数据模块还要向评委展示你“能从数据里发现规律”。推荐的做法是写一组统计接口从数据库里聚合出有业务含义的指标。比如“月初和月底的蔬菜价格波动对比”。Django的ORM本身就支持聚合查询from django.db.models import Avg, Sum monthly_price ( ProductPrice.objects .filter(product__categoryvegetable) .values(sales_date__month) .annotate(avg_priceAvg(price)) .order_by(sales_date__month) )这个查询直接返回每个月的平均蔬菜价格前端图表拿过去渲染成柱状图就是一张很直观的“价格月度波动分析图”。再比如“不同产地的产品销量对比”。思路一样按region分组再做聚合可视化层用饼图呈现。这两张图的功能就是大数据模块的最佳证明。你会发现它们不复杂但完整地展示了“抽取数据、清洗处理、统计分析、可视化呈见”的完整链路这正是评委想看到的东西。5. 完整实操从零搭出一套可演示系统5.1 项目目录与工程初始化我实际搭过的项目结构是这样的你可以直接按这个来agri_recommend/ ├── backend/ # Django项目根目录 │ ├── manage.py │ ├── agri_recommend/ # Django主配置 │ ├── apps/ │ │ ├── users/ # 用户模块 │ │ ├── products/ # 农产品模块 │ │ ├── recommend/ # 推荐模块 │ │ └── dashboard/ # 数据统计模块 │ ├── scripts/ # 数据清洗与导入脚本 │ └── requirements.txt ├── frontend/ # Vue项目根目录 │ ├── src/ │ │ ├── api/ # axios接口封装 │ │ ├── components/ │ │ │ ├── charts/ # 图表组件 │ │ │ └── RecommendCard.vue │ │ ├── views/ │ │ │ ├── Home.vue │ │ │ ├── Products.vue │ │ │ └── Dashboard.vue │ └── package.json └── docs/ # 文档、PPT、演示脚本初始化环境时的命令不用背记住套路就够# 后端 cd backend python -m venv venv source venv/bin/activate # Windows是 venv\Scripts\activate pip install django djangorestframework pandas mysqlclient numpy django-admin startproject agri_recommend . python manage.py startapp products python manage.py startapp users python manage.py startapp recommend # 前端 cd frontend npm create vuelatest . npm install axios echarts element-plus创建完应用后记得在Django的settings.py里将应用注册到INSTALLED_APPS把CORS_ALLOW_ALL_ORIGINS True加上不然前后端联调时跨域请求会直接报错。别小看这个配置每次我帮别人排查联调问题十次里有六次是跨域没配好。5.2 后端核心代码实现我突然想到可以先给出模型层。农产品模块用三个核心模型足以支撑全套功能class Category(models.Model): name models.CharField(max_length50) # 蔬菜、水果等 icon models.CharField(max_length100, blankTrue) class Product(models.Model): name models.CharField(max_length100) # 农产品的品名 category models.ForeignKey(Category, related_nameproducts, on_deletemodels.CASCADE) origin models.CharField(max_length100) # 产地 price models.DecimalField(max_digits8, decimal_places2) season models.CharField(max_length50) # 适宜季节 tags models.CharField(max_length200) # 标签逗号分隔 sales_count models.IntegerField(default0) class UserBehavior(models.Model): user models.ForeignKey(User, related_namebehaviors, on_deletemodels.CASCADE) product models.ForeignKey(Product, related_namebehaviors, on_deletemodels.CASCADE) behavior_type models.CharField(max_length20) # view / collect / purchase score models.IntegerField(default1) created_at models.DateTimeField(auto_now_addTrue)推荐模块的接口写起来非常直接。核心函数就三步加载评分矩阵、计算相似度、生成推荐列表。def recommend_for_user(user_id, top_n10): be UserBehavior.objects.filter(user_iduser_id) products_df pd.DataFrame( list(be.values_list(user_id, product_id, score)) ) if products_df.shape[0] 0: # 冷启动返回销量Top商品作为默认推荐 return list(Product.objects.order_by(-sales_count)[:top_n]) matrix products_df.pivot_table( indexuser_id, columnsproduct_id, valuesscore, fill_value0 ) # 计算用户行为向量与所有物品的相似度 user_vector matrix.loc[user_id].values sims cosine_similarity(user_vector.reshape(1, -1), matrix.T) item_indices sims.argsort()[0][-top_n:][::-1] return list(Product.objects.filter(pk__inmatrix.columns[item_indices]))这段代码不是最优雅的但足够清晰每行都能在答辩现场讲明白。把用户历史行为变成DataFrame、用矩阵运算算相似度、取Top-N结果整个推荐的链路一眼到底。视图层用Django REST Framework来写可以直接用api_view装饰器api_view([GET]) def recommend(request): user request.user if request.user.is_authenticated else None if user is None: return Response({detail: 请先登录}, status401) recs recommend_for_user(user.id) data ProductSerializer(recs, manyTrue).data return Response(data)5.3 前端页面与接口对接Vue这边需要解决的问题是如何优雅地请求后端接口并渲染数据。以推荐列表为例我的做法是在src/api目录建立一个统一接口层import request from ./axios export function getRecommendList() { return request.get(/api/recommend/) } export function getPriceTrend(productId) { return request.get(/api/products/${productId}/price_trend/) } export function getCategoryStats() { return request.get(/api/dashboard/category_stats/) }统一封装的axios实例里配置好baseURL和拦截器。拦截器的作用是在请求头里自动带上Token响应里如果发现401就跳转登录页。这样每个页面组件不需要关心登录状态统一处理即可。页面组件内部的典型写法就是一套完整的“加载-请求-渲染-异常处理”流程const loading ref(true) const products ref([]) const loadProducts async () { try { const res await getRecommendList() products.value res.data loading.value false } catch (e) { ElMessage.error(推荐数据加载失败) } } onMounted(loadProducts)模板层用Element Plus的卡片组件把推荐商品封装成一张张产品卡片展示图片、名称、价格、产地。卡片上再加一个“加入收藏”的按钮点击后调用后端接口写入行为数据这就形成了完整的数据闭环——用户在页面上发生的动作反过来会优化这个用户下一次收到的推荐结果。每次演示到这一步我都建议大家多操作几下让评委看到“每点一次收藏下一次推荐的列表会发生变化”这个动态反馈最有说服力。5.4 打包部署与演示准备答辩前的部署工作我建议区分两个场景本地演示场景下后端用python manage.py runserver启动前端用npm run dev启动两个服务并行跑。在Vite配置文件里设置server.proxy代理把/api路径代理到Django端口// vite.config.js server: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true } } }配置好代理以后前端实现起来就不必操跨域的心所有请求都走同一个端口感觉像是前后端一体。如果要在服务器上部署则要在本地先npm run build构建前端静态资源然后用Nginx托管dist目录反向代理/api到Django的Gunicorn进程。这部分可以写进论文里的“系统部署”章节实践价值很大。还有最后一道闭环种子数据脚本。很多同学答辩前紧张到忘记点数据初始化按钮导致评委打开系统时看到一片空白。建议把演示必需的账号、推荐测试数据、可视化统计数据全部写进一个seed_demo_data管理命令里一键执行python manage.py seed_demo_data每次演示前跑一遍保证数据库状态干净、完整体现系统功能。6. 常见问题与排查经验6.1 跨域与接口联调前置开发中最常见的报错是浏览器控制台的CORS policy。这是浏览器的同源策略在阻止你的请求解决方式是在Django安装django-cors-headers并在settings.py里配置INSTALLED_APPS [corsheaders] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware ] CORS_ALLOW_ALL_ORIGINS True如果你用了我前面说的Vite代理方案本地开发时其实不需要这个配置因为请求路径在同一个域名下根本不触发跨域。但如果你直接从前端的3000端口访问后端的8000端口跨域配置就是必须的。另一个常见的接口联调问题是400请求格式错误。多半是前端传递的JSON字段名和后端序列化器期望的字段名对不上。比如前端传productId后端期望product。我的习惯是所有接口字段一律用下划线风格命名前端也要用同一个名字两边统一。前端让我在重构时照抄通用的命名规则避免翻译层导致A字段到B字段的混乱。6.2 推荐结果不准如果你发现推荐结果很离谱比如给一个喜欢蔬菜的用户推荐了生鲜肉类先不要怀疑算法先检查数据。要检查的第一件事训练数据里是否有足够的正样本。我自己踩过一个坑造数据时候行为记录太少矩阵几乎稀疏到全部是0最后算出来的相似度矩阵全是0推荐结果退化成随机。解决办法是确保每个用户至少有20条以上有效行为记录且行为类型要有区分度——不能全是浏览必须有收藏和购买这样评分矩阵才具备梯度。要检查的第二件事标签噪声。如果农产品标签打得太随意比如胡萝卜的标签里既写了“新鲜”又写了“进口”这两类用户的画像会被拉得毫无边界相似度计算自然失真。建议在生成标签时用一套受限的词表严格控制关键词数量宁可标签少而准不要多而杂。6.3 演示现场防坑清单答辩演示往往比开发更容易出意外。根据我观察到的经验整理了一份“现场防翻车清单”提前关闭系统更新弹窗和浏览器无关标签页。演示时一个弹窗就能打断思路和节奏。数据库备份一份到U盘和个人网盘。如果你用SQLite数据库就是一个文件拷贝走就行MySQL则有更麻烦的mysqldump答辩前备份就完事了。提前准备好网络热点以防答辩教室的WiFi不稳定。前后端服务都在本机运行只要浏览器和服务器本身跑起来就不会受到影响但如果你演示时依赖在线地图资源无线网络断掉后地图组件会加载失败这就尴尬了。提前写一份“演示脚本”文档把每一步要说什么、要点哪里、预期出现什么结果都列出来。这不是给评委看的是给你自己彩排用的。我在彩排时记得有点夸张地自言自语两遍到现场脑子空白了身体的肌肉记忆还能带着你完成全部操作。还有一点经验之谈答辩现场展示代码时不要从头到尾用代码编辑器一个文件一个文件地翻没时间也没有效果。应该先把系统跑起来让评委看到完整的功能界面回答提问时再精准跳转到对应的代码段落比如推荐算法的核心函数、模型定义、图表组件三处跳转就够了。这样信息密度高也显得你对代码结构了如指掌。7. 一些来自实践中的补充思路最后分享一个我在重做类似项目时摸索出来的经验把农产品推荐系统做“活”的关键不在于堆功能而在于功能之间互相咬合。比如用户注册后做偏好选择这个选择会同时影响推荐模块的初始化和综合的商品标签体系用户在详情页点击收藏会自动更新销量榜和市场分析图表一个季节切换推荐的商品列表和价格趋势图都会同步变化。这些模块之间的联动比单纯“推荐是推荐、图表是图表”的孤岛结构更能体现系统设计能力。毕业论文的写作顺序上我建议先写数据层模型定义、数据清洗再写业务层推荐算法、接口设计最后写展示层可视化。因为数据层和业务层是你真正实现了的、经得起追问的内容写起来充实展示层虽然直观但容易被说成“只做了前端”放在最后一章会更自然。如果你想把这套系统继续扩展我建议往“智能价格预警”方向走。在现有数据基础上做一个简单的价格异常检测比如超过历史均值20%就标记为异常波动并在前端的图表里用红色标注。这个功能技术门槛不高但业务含义很强写在论文里也会让“大数据和推荐算法之间的关系”讲得更立体。做这类全栈毕业设计最忌讳的就是眼高手低。很多同学一开始想同时做成闪亮的CMS、炫酷的可视化、准确的推荐最后什么都没做透还让产品处于一团混乱中。只做好一条完整链路把“登录选品→互动建行为→数据加工→智能推荐→可视化展示”都做顺、做稳答辩时就可以拿着这套闭环自信地讲完整演示。
1. 项目全貌这套系统到底在做什么1.1 核心需求拆解先说清楚这个项目到底是个什么东西。如果你正在找毕业设计方向或者想了解全栈项目是怎么把推荐、可视化、数据处理这几个模块串起来的那这套“农产品推荐系统”是一个很典型的样本。它不是一个只写几个页面的展示项目而是一个能跑通完整业务闭环的系统后端负责业务逻辑和数据计算前端负责交互展示中间通过接口通信最后形成一套可演示、可扩展、可写进毕业论文的完整成果。项目标题里的三个关键词分别对应三个核心模块推荐系统根据用户的历史行为、偏好标签从农产品库中筛选出可能感兴趣的商品前端展示“猜你喜欢”之类的推荐列表。可视化把农产品价格、销量、产地分布等数据做成图表让人一眼看懂趋势和结构而不是面对一堆Excel数字发呆。大数据处理这里说的“大数据”不是几十台服务器跑Spark那种级别而是指系统要能处理足够量的真实或模拟数据通过合理的数据清洗、统计分析支撑推荐和可视化模块的运转。很多同学看到这种项目名会先被“大数据”三个字吓住实际上不用。毕业设计语境下的大数据核心是看你会不会把数据从原始状态变成有价值的信息。用Django做ORM模型、用Pandas做数据清洗、用ECharts做可视化已经完全够了。1.2 技术选型的真实考量为什么用DjangoVue.js这套组合我直接说结论它是目前全栈类毕业设计里“性价比最高”的搭配之一而且各部件角色非常清晰。Django是Python生态里最成熟的后端框架。它内置了ORM、Admin后台、认证系统、路由分发这意味着你不需要自己去实现用户登录、数据库建表、请求参数校验这些基础功能。对毕业设计来说省下来的时间可以全部投入推荐算法和业务逻辑而不是去造轮子。更重要的是Python本身就是做数据分析、推荐算法最顺手的语言你在写协同过滤、相似度计算时可以直接用Pandas和NumPy不需要跨语言做数据转换这一点比Java系框架顺手非常多。Vue.js负责的是前端展示层。它的核心优势是组件化开发页面上的推荐卡片、图表区域、搜索筛选区可以拆成独立的组件各自维护状态互不干扰。第一次接触前端的同学可能觉得Vue比传统模板渲染多了一层抽象但一旦你熟悉了数据绑定和生命周期开发效率会比写jQuery高一个量级。而且Vue对ECharts的支持非常友好图表初始化、数据更新、销毁都有对应的生命周期钩子不用像写原生JS那样手动去管理DOM。有人会问那为什么不选SpringBootVue或者纯Django模板渲染因为SpringBootNginx你大概率还得自己去处理数据库连接池和繁琐的配置纯Django模板又无法做出足够的交互感和现代感。毕业设计答辩时评委第一眼看到的是前端页面第二眼才看代码和文档。一个交互流畅、图表丰富的页面在第一印象上就已经赢了一半。1.3 整体架构与数据流整套系统的请求链路是这样的用户在浏览器里点击Vue页面 → 页面通过axios向后端发送HTTP请求 → Django的URL路由把请求分发给对应的视图函数 → 视图从数据库读取或写入数据 → 数据经过处理比如推荐算法计算后以JSON格式返回 → Vue拿到JSON后更新页面状态 → 图表和推荐列表刷新。数据库层面用MySQL或SQLite都行。个人建议本地开发用SQLite起步等所有功能跑通了再迁移到MySQL。理由很简单SQLite是单文件数据库不依赖独立服务启动零配置非常适合前期快速验证。你不需要像MySQL那样额外安装服务、配置用户权限、处理端口占用复制到任何一台电脑上都能直接调试。到了打包部署阶段再迁到MySQLDjango的ORM屏蔽了底层数据库差异迁移成本非常低。这种“前后端分离”的架构还有一个好处可以并行开发。你让一个人专门写后端接口一个人专注前端页面只要接口约定好了两边互不阻塞。对组队做项目的同学来讲这条价值无法忽略。2. 农产品推荐系统的核心逻辑2.1 推荐策略内容过滤与协同过滤结合推荐系统是整个项目里最有内容可写的模块。农产品推荐和普通电商推荐有一点重要的差异农产品的生命周期短、季节性强、价格波动大用户对“新鲜”和“产地”的敏感度远高于对“品牌”的敏感度。所以推荐策略不能简单套用“买了A的人还买了B”这种通用电商逻辑。我在这个项目里采用的是“内容过滤协同过滤”结合的策略。内容过滤的思路是给每个农产品打上特征标签比如类别水果/蔬菜/粮油、产地、价格区间、季节性特点、营养价值标签。用户注册时会先选择自己的偏好之后系统根据这些偏好计算物品与物品之间的相似度把最相似的商品推荐给他。协同过滤则更进一步它不依赖物品的显式标签而是通过用户行为来寻找规律。如果用户A和用户B在历史上的浏览记录、购买记录高度重合我们就可以把B近期关注过的商品推荐给A。这个逻辑对农产品同样适用比如两个注重健康饮食的用户都频繁购买西蓝花、紫甘蓝这类高纤维蔬菜系统就可以在他们之间互相补充推荐。两种策略各有优劣。内容过滤容易理解、冷启动时也能推荐但推荐结果容易“千篇一律”协同过滤能发现用户自己都没意识到的需求但新用户没有行为数据时完全无法工作。所以实践中通常先做内容过滤兜底等用户积累了一定的行为数据再逐步叠加协同过滤的结果最后用加权融合的方式生成最终推荐列表。2.2 关键算法实现思路具体实现时我推荐用最经典的“基于物品的协同过滤”作为骨架理由是整个流程清晰且可控。你在论文里能讲清楚“步骤一建立评分矩阵步骤二计算物品相似度步骤三生成推荐列表”评委听着很舒服你写代码也不容易走偏。典型步骤如下从数据库中取出所有用户的历史行为记录包括浏览、加入收藏、购买等动作转换成用户对物品的“隐式评分”。评分规则可以自定义比如浏览记1分、收藏记3分、购买记5分这样同一个用户对不同商品就有了不同的偏好权重。构建“用户-物品”评分矩阵。矩阵的每一行代表一个用户每一列代表一种农产品。没有交互就填0有交互就填对应的隐式评分。计算物品之间的相似度。推荐用余弦相似度。公式的本质是把每列数据看成一个向量两个向量的夹角越小说明这两个物品在用户行为上越接近。在NumPy里直接用cos_sim np.dot(A, B) / (np.linalg.norm(A) * np.linalg.norm(B))就能算出来。找到和用户已购买商品最相似的Top-N个商品排除掉用户已经买过的就得到推荐列表。这里有一个容易被忽略的细节温度补偿。农产品是有季节性的你在计算相似度时可以额外加一个时间权重。比如西瓜在夏季的推荐权重应该高于冬季。具体做法可以是给评分矩阵加时间衰减因子行为时间距离当前越近评分权重越高。这样系统就不只是“根据历史猜你想买”而是“根据历史加当前季节猜你想买”听起来也更有逻辑深度。2.3 推荐效果的评估与优化推荐做完了怎么证明它好用答辩时大概率会被问到。如果你自己都不清楚推荐效果怎么评估这个问题会非常尴尬。基础的做法是离线划分数据集。把用户行为数据按时间先后分成训练集和测试集比如前70%的数据用来生成推荐规则后30%的数据用来验证。在测试集里统计“用户实际发生交互的商品中有多少是系统推荐出来的”这个指标叫召回率统计“系统推荐的商品中有多少用户真的交互了”这个指标叫准确率。两者是此消彼长的关系通常看F1值来综合评估。更好看一点的做法是手动构造几个用户画像做对比测试。比如创建一个“偏爱水果的用户”做20次交互创建一个“偏爱低脂蔬菜的用户”做20次交互。然后看推荐结果是否和他们的画像对齐。这比冷冰冰的数值指标更能打动评委因为评委能直观看到系统的推荐逻辑是符合预期的。我做这套系统的时候明显感受到一个规律推荐准不准算法只占一半数据质量占另一半。如果你的行为数据是临时造出来的而且分布完全随机那再好的协同过滤也输出不了有意义的结果。造测试数据时要有意识地模拟真实场景比如访谈一些用户粗略记录他们的购买习惯再把这些习惯翻译成行为数据。这样产出的推荐结果才具备说服力。3. 农产品可视化模块这样落地3.1 用ECharts展示的数据维度可视化不是单纯“画个图”就完事关键是选择合适的图表类型对应合适的业务问题。农产品系统里我认为必须呈现四个方面第一价格趋势图。每种农产品在一段时间内的价格走势用折线图呈现横轴是日期纵轴是价格。这张图解决的问题是“这东西最近是涨还是跌”。很多用户买农产品前最关心的就是这个也可以顺势引出“推荐低价时段的优质农产品”这个功能点。第二品类分布图。统计当前农产品库里各类产品蔬菜、水果、粮油、肉类、水产的数量和比例用饼图或环形图。这张图的意义在于让用户快速了解平台的产品结构。第三产地分布图。用中国地图或柱状图展示不同农产品产地的供货量。地图类的可视化会直接拉升整个项目的感觉而且它在技术实现上并不难ECharts官方就有地图组件的地理数据你只需要把各省市的农产品数量汇总成JSON格式填充进去。第四销量排行图。以柱状图或横向条形图展示一段时间内销量Top10的农产品。这张图对运营决策最有价值能直观告诉商家“哪些产品是主力产品”。3.2 前端组件设计与交互在Vue项目里我建议把每个图表封装成独立的组件统一放到src/components/charts目录下。每个组件接收一个data属性内部负责初始化ECharts实例和更新配置。这样做的最大好处是图表逻辑和页面业务逻辑彻底分离页面上只需要写一行“传数据进去”的代码图表就能自己跑起来。以价格趋势图为例组件内部的核心逻辑是watch: { data: { handler(newVal) { this.chart.setOption({ xAxis: { data: newVal.map(item item.date) }, series: [{ data: newVal.map(item item.price) }] }); }, deep: true } }用watch监听数据变化这比手动调用setOption要优雅很多。数据一旦更新图表自动跟着刷新你不用关心是用户切换了产品类别还是时间范围。图画完之后交互不能少。至少要有两个交互点一个是图表的tooltip提示框鼠标悬浮时显示当前时间点的具体数值和涨跌幅另一个是点击图表时的高亮效果。ECharts里这些基本是配置项几行代码就能实现但效果非常直观答辩演示时能明显提升用户体验的感知。3.3 可视化的几个坑ECharts用起来不难但有几个坑我必须帮你踩掉。每个页面首次加载后出现警告“容器没有宽度或高度”原因是你给图表的父容器设置了display: none或者容器尺寸还没渲染完成就调用了init。解决方法有两个一是确保图表容器有明确的width: 100%; height: 400px这种固定尺寸二是在mounted生命周期里延迟调用初始化或者用Vue的$nextTick等待DOM完全渲染后再初始化。当页面包含选项卡切换不同的Tab页签时隐藏的那个图表可能会变形宽高变成0。原因是DOM重新布局后ECharts实例不知道该调整自己的尺寸。解决办法是在Tab切换完成后调用chart.resize();用ECharts自带的resize方法强制重新测量容器大小。还有一个数据格式问题。ECharts要求数据字段必须结构一致比如折线图的date字段必须是时间字符串你不能在这里拿到的是“2025-06-01”、那里拿到的是“06/01/2025”。建议在Django后端序列化数据时就统一格式不要指望前端做兼容性修复。后端多几行代码前端省一晚上的Debug时间。4. 农产品大数据处理部分并没有那么“高不可攀”4.1 大数据在毕业设计里的边界“大数据”这个词在项目名里很大但落到实操上你要做的是把一套能够处理较大数据量的流程跑通而不是真的去搭建分布式集群。毕业设计时间有限没有哪个评委期待你用Hadoop跑农产品数据那不是明智的选题策略。更现实的做法是用Pandas在Python里处理数据用Django ORM做数据库交互数据量控制在几千到几万条就能充分展示“大数据处理”的核心能力。真正有价值的是数据处理流程本身数据从哪来、怎么清洗、如何入库、怎么被上层业务使用。能把这条链路讲明白你的论文已经有了扎实的实践支撑。4.2 数据采集、清洗与导入数据来源是这个项目里的一个隐患。如果你没有真实的农产品数据千万别直接编造几万条假数据丢进数据库那样后续推荐和可视化全都会失真。我的做法是分三步走第一步从公开的农业数据源或市面上已有的农产品价格数据文档中收集一些真实的年度价格与销量数据。不需要多全有一两个月的历史记录就够了。第二步用Pandas做清洗。这一步关注三件事去重、缺失值填充、类型转换。如果你拿到的数据是price: 5.5元/斤这种带单位字符串直接存进数据库没法计算必须先提取出数值部分并转成FloatField。我用一个简单的活用的例子import pandas as pd df pd.read_csv(agri_data.csv) df[price] df[price].replace([元/斤], , regexTrue).astype(float) df[sales_date] pd.to_datetime(df[sales_date]) df df.dropna(subset[name, price]) df df.drop_duplicates(subset[name, sales_date, region])第三步把清洗后的DataFrame导入MySQLfrom django.core.management.base import BaseCommand class Command(BaseCommand): def handle(self, *args, **options): df pd.read_csv(cleaned_agri_data.csv) for _, row in df.iterrows(): Product.objects.update_or_create( namerow[name], defaults{price: row[price], region: row[region]} )用update_or_create而不是直接create这样重复导入时不会报唯一性错误也支持增量更新。4.3 数据统计与关联分析大数据模块还要向评委展示你“能从数据里发现规律”。推荐的做法是写一组统计接口从数据库里聚合出有业务含义的指标。比如“月初和月底的蔬菜价格波动对比”。Django的ORM本身就支持聚合查询from django.db.models import Avg, Sum monthly_price ( ProductPrice.objects .filter(product__categoryvegetable) .values(sales_date__month) .annotate(avg_priceAvg(price)) .order_by(sales_date__month) )这个查询直接返回每个月的平均蔬菜价格前端图表拿过去渲染成柱状图就是一张很直观的“价格月度波动分析图”。再比如“不同产地的产品销量对比”。思路一样按region分组再做聚合可视化层用饼图呈现。这两张图的功能就是大数据模块的最佳证明。你会发现它们不复杂但完整地展示了“抽取数据、清洗处理、统计分析、可视化呈见”的完整链路这正是评委想看到的东西。5. 完整实操从零搭出一套可演示系统5.1 项目目录与工程初始化我实际搭过的项目结构是这样的你可以直接按这个来agri_recommend/ ├── backend/ # Django项目根目录 │ ├── manage.py │ ├── agri_recommend/ # Django主配置 │ ├── apps/ │ │ ├── users/ # 用户模块 │ │ ├── products/ # 农产品模块 │ │ ├── recommend/ # 推荐模块 │ │ └── dashboard/ # 数据统计模块 │ ├── scripts/ # 数据清洗与导入脚本 │ └── requirements.txt ├── frontend/ # Vue项目根目录 │ ├── src/ │ │ ├── api/ # axios接口封装 │ │ ├── components/ │ │ │ ├── charts/ # 图表组件 │ │ │ └── RecommendCard.vue │ │ ├── views/ │ │ │ ├── Home.vue │ │ │ ├── Products.vue │ │ │ └── Dashboard.vue │ └── package.json └── docs/ # 文档、PPT、演示脚本初始化环境时的命令不用背记住套路就够# 后端 cd backend python -m venv venv source venv/bin/activate # Windows是 venv\Scripts\activate pip install django djangorestframework pandas mysqlclient numpy django-admin startproject agri_recommend . python manage.py startapp products python manage.py startapp users python manage.py startapp recommend # 前端 cd frontend npm create vuelatest . npm install axios echarts element-plus创建完应用后记得在Django的settings.py里将应用注册到INSTALLED_APPS把CORS_ALLOW_ALL_ORIGINS True加上不然前后端联调时跨域请求会直接报错。别小看这个配置每次我帮别人排查联调问题十次里有六次是跨域没配好。5.2 后端核心代码实现我突然想到可以先给出模型层。农产品模块用三个核心模型足以支撑全套功能class Category(models.Model): name models.CharField(max_length50) # 蔬菜、水果等 icon models.CharField(max_length100, blankTrue) class Product(models.Model): name models.CharField(max_length100) # 农产品的品名 category models.ForeignKey(Category, related_nameproducts, on_deletemodels.CASCADE) origin models.CharField(max_length100) # 产地 price models.DecimalField(max_digits8, decimal_places2) season models.CharField(max_length50) # 适宜季节 tags models.CharField(max_length200) # 标签逗号分隔 sales_count models.IntegerField(default0) class UserBehavior(models.Model): user models.ForeignKey(User, related_namebehaviors, on_deletemodels.CASCADE) product models.ForeignKey(Product, related_namebehaviors, on_deletemodels.CASCADE) behavior_type models.CharField(max_length20) # view / collect / purchase score models.IntegerField(default1) created_at models.DateTimeField(auto_now_addTrue)推荐模块的接口写起来非常直接。核心函数就三步加载评分矩阵、计算相似度、生成推荐列表。def recommend_for_user(user_id, top_n10): be UserBehavior.objects.filter(user_iduser_id) products_df pd.DataFrame( list(be.values_list(user_id, product_id, score)) ) if products_df.shape[0] 0: # 冷启动返回销量Top商品作为默认推荐 return list(Product.objects.order_by(-sales_count)[:top_n]) matrix products_df.pivot_table( indexuser_id, columnsproduct_id, valuesscore, fill_value0 ) # 计算用户行为向量与所有物品的相似度 user_vector matrix.loc[user_id].values sims cosine_similarity(user_vector.reshape(1, -1), matrix.T) item_indices sims.argsort()[0][-top_n:][::-1] return list(Product.objects.filter(pk__inmatrix.columns[item_indices]))这段代码不是最优雅的但足够清晰每行都能在答辩现场讲明白。把用户历史行为变成DataFrame、用矩阵运算算相似度、取Top-N结果整个推荐的链路一眼到底。视图层用Django REST Framework来写可以直接用api_view装饰器api_view([GET]) def recommend(request): user request.user if request.user.is_authenticated else None if user is None: return Response({detail: 请先登录}, status401) recs recommend_for_user(user.id) data ProductSerializer(recs, manyTrue).data return Response(data)5.3 前端页面与接口对接Vue这边需要解决的问题是如何优雅地请求后端接口并渲染数据。以推荐列表为例我的做法是在src/api目录建立一个统一接口层import request from ./axios export function getRecommendList() { return request.get(/api/recommend/) } export function getPriceTrend(productId) { return request.get(/api/products/${productId}/price_trend/) } export function getCategoryStats() { return request.get(/api/dashboard/category_stats/) }统一封装的axios实例里配置好baseURL和拦截器。拦截器的作用是在请求头里自动带上Token响应里如果发现401就跳转登录页。这样每个页面组件不需要关心登录状态统一处理即可。页面组件内部的典型写法就是一套完整的“加载-请求-渲染-异常处理”流程const loading ref(true) const products ref([]) const loadProducts async () { try { const res await getRecommendList() products.value res.data loading.value false } catch (e) { ElMessage.error(推荐数据加载失败) } } onMounted(loadProducts)模板层用Element Plus的卡片组件把推荐商品封装成一张张产品卡片展示图片、名称、价格、产地。卡片上再加一个“加入收藏”的按钮点击后调用后端接口写入行为数据这就形成了完整的数据闭环——用户在页面上发生的动作反过来会优化这个用户下一次收到的推荐结果。每次演示到这一步我都建议大家多操作几下让评委看到“每点一次收藏下一次推荐的列表会发生变化”这个动态反馈最有说服力。5.4 打包部署与演示准备答辩前的部署工作我建议区分两个场景本地演示场景下后端用python manage.py runserver启动前端用npm run dev启动两个服务并行跑。在Vite配置文件里设置server.proxy代理把/api路径代理到Django端口// vite.config.js server: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true } } }配置好代理以后前端实现起来就不必操跨域的心所有请求都走同一个端口感觉像是前后端一体。如果要在服务器上部署则要在本地先npm run build构建前端静态资源然后用Nginx托管dist目录反向代理/api到Django的Gunicorn进程。这部分可以写进论文里的“系统部署”章节实践价值很大。还有最后一道闭环种子数据脚本。很多同学答辩前紧张到忘记点数据初始化按钮导致评委打开系统时看到一片空白。建议把演示必需的账号、推荐测试数据、可视化统计数据全部写进一个seed_demo_data管理命令里一键执行python manage.py seed_demo_data每次演示前跑一遍保证数据库状态干净、完整体现系统功能。6. 常见问题与排查经验6.1 跨域与接口联调前置开发中最常见的报错是浏览器控制台的CORS policy。这是浏览器的同源策略在阻止你的请求解决方式是在Django安装django-cors-headers并在settings.py里配置INSTALLED_APPS [corsheaders] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware ] CORS_ALLOW_ALL_ORIGINS True如果你用了我前面说的Vite代理方案本地开发时其实不需要这个配置因为请求路径在同一个域名下根本不触发跨域。但如果你直接从前端的3000端口访问后端的8000端口跨域配置就是必须的。另一个常见的接口联调问题是400请求格式错误。多半是前端传递的JSON字段名和后端序列化器期望的字段名对不上。比如前端传productId后端期望product。我的习惯是所有接口字段一律用下划线风格命名前端也要用同一个名字两边统一。前端让我在重构时照抄通用的命名规则避免翻译层导致A字段到B字段的混乱。6.2 推荐结果不准如果你发现推荐结果很离谱比如给一个喜欢蔬菜的用户推荐了生鲜肉类先不要怀疑算法先检查数据。要检查的第一件事训练数据里是否有足够的正样本。我自己踩过一个坑造数据时候行为记录太少矩阵几乎稀疏到全部是0最后算出来的相似度矩阵全是0推荐结果退化成随机。解决办法是确保每个用户至少有20条以上有效行为记录且行为类型要有区分度——不能全是浏览必须有收藏和购买这样评分矩阵才具备梯度。要检查的第二件事标签噪声。如果农产品标签打得太随意比如胡萝卜的标签里既写了“新鲜”又写了“进口”这两类用户的画像会被拉得毫无边界相似度计算自然失真。建议在生成标签时用一套受限的词表严格控制关键词数量宁可标签少而准不要多而杂。6.3 演示现场防坑清单答辩演示往往比开发更容易出意外。根据我观察到的经验整理了一份“现场防翻车清单”提前关闭系统更新弹窗和浏览器无关标签页。演示时一个弹窗就能打断思路和节奏。数据库备份一份到U盘和个人网盘。如果你用SQLite数据库就是一个文件拷贝走就行MySQL则有更麻烦的mysqldump答辩前备份就完事了。提前准备好网络热点以防答辩教室的WiFi不稳定。前后端服务都在本机运行只要浏览器和服务器本身跑起来就不会受到影响但如果你演示时依赖在线地图资源无线网络断掉后地图组件会加载失败这就尴尬了。提前写一份“演示脚本”文档把每一步要说什么、要点哪里、预期出现什么结果都列出来。这不是给评委看的是给你自己彩排用的。我在彩排时记得有点夸张地自言自语两遍到现场脑子空白了身体的肌肉记忆还能带着你完成全部操作。还有一点经验之谈答辩现场展示代码时不要从头到尾用代码编辑器一个文件一个文件地翻没时间也没有效果。应该先把系统跑起来让评委看到完整的功能界面回答提问时再精准跳转到对应的代码段落比如推荐算法的核心函数、模型定义、图表组件三处跳转就够了。这样信息密度高也显得你对代码结构了如指掌。7. 一些来自实践中的补充思路最后分享一个我在重做类似项目时摸索出来的经验把农产品推荐系统做“活”的关键不在于堆功能而在于功能之间互相咬合。比如用户注册后做偏好选择这个选择会同时影响推荐模块的初始化和综合的商品标签体系用户在详情页点击收藏会自动更新销量榜和市场分析图表一个季节切换推荐的商品列表和价格趋势图都会同步变化。这些模块之间的联动比单纯“推荐是推荐、图表是图表”的孤岛结构更能体现系统设计能力。毕业论文的写作顺序上我建议先写数据层模型定义、数据清洗再写业务层推荐算法、接口设计最后写展示层可视化。因为数据层和业务层是你真正实现了的、经得起追问的内容写起来充实展示层虽然直观但容易被说成“只做了前端”放在最后一章会更自然。如果你想把这套系统继续扩展我建议往“智能价格预警”方向走。在现有数据基础上做一个简单的价格异常检测比如超过历史均值20%就标记为异常波动并在前端的图表里用红色标注。这个功能技术门槛不高但业务含义很强写在论文里也会让“大数据和推荐算法之间的关系”讲得更立体。做这类全栈毕业设计最忌讳的就是眼高手低。很多同学一开始想同时做成闪亮的CMS、炫酷的可视化、准确的推荐最后什么都没做透还让产品处于一团混乱中。只做好一条完整链路把“登录选品→互动建行为→数据加工→智能推荐→可视化展示”都做顺、做稳答辩时就可以拿着这套闭环自信地讲完整演示。
