如果你正在为计算机毕设选题发愁又不想做那种满大街都是的图书管理系统或者学生信息管理系统得物商品销售可视化分析加协同过滤推荐系统这个方向确实值得认真考虑一下。它把电商数据分析、可视化大屏、推荐算法三个热门考点串在了一条业务链上——从商品销售数据里挖规律、用图表讲清楚业务结论、再基于用户行为做个性化推荐一套系统下来前端展示、后端开发、算法实现、数据库设计全都覆盖到了。无论是本科毕业设计还是求职作品集这个项目都能拿得出手。这篇内容我就以过来人的角度把这个项目从选题、数据准备、算法实现到可视化集成、进阶亮点、答辩避坑完整拆一遍。适合正在做毕设的计算机相关专业学生也适合想练手电商数据分析和推荐系统的开发者。我会把每个关键环节的为什么这么做也讲清楚不是光贴代码让你抄而是让你真正明白这套系统是怎么搭起来的。1. 选题逻辑拆解为什么得物商品数据适合做毕设1.1 这个题目的答辩优势在哪里先说选题。很多同学纠结怕题目太简单被老师挑刺又怕太难做不完。得物商品销售可视化加推荐系统这个组合恰好卡在一个本科毕设的黄金难度区间——数据分析部分足够展示工程能力协同过滤算法足够展示理论基础可视化部分又足够展示审美和交互设计。三个模块不是硬凑的它们之间有一条完整的业务逻辑线平台积累了海量商品和用户行为数据 → 通过数据分析洞察销售规律 → 借助推荐算法提升转化率。这条线本身就是电商行业的标准业务流程答辩的时候老师问你这个系统有什么价值你完全可以从业务闭环的角度回答。另外得物这个平台本身自带话题度。它主打潮流单品、球鞋、限量发售、二手交易商品的价格波动和用户偏好非常有特点。比如某款限量球鞋发售当天的销量曲线、不同品牌在不同价格带上的分布、潮流单品的地域热度差异这些分析维度比传统的某某超市销售分析有意思得多也更容易在答辩时讲出亮点。1.2 技术选型与前因后果技术栈我建议这样定后端用 Python Django推荐算法用协同过滤可视化用 ECharts数据库用 MySQL数据分析用 Pandas。这套组合的合理性在于Django 自带 Admin 后台和 ORM可以快速把商品、用户、订单这些数据模型建好并管理起来。毕设周期紧张不需要像 Spring 全家桶那样配一大堆东西Django 开箱即用的特点能帮你节省大量开发时间。Python 生态对数据处理最友好。Pandas 做清洗聚合、Scikit-learn 做算法评估、Matplotlib/Seaborn 做探索性分析全程只用一种语言不用在前后端切换心智。ECharts 是可视化大屏的事实标准。社区案例多、配置项丰富、中文文档齐全动态效果和交互性比 Matplotlib 生成的静态图强太多直接输出到浏览器展示非常契合毕设答辩的演示场景。协同过滤这块本科阶段我建议用基于物品的协同过滤ItemCF做核心推荐再用基于用户的协同过滤UserCF做对照。这两个算法是推荐系统课程的必讲内容实现难度适中又有足够的优化空间——后面我会具体讲怎么在基础版本上做改进。2. 数据层设计从原始数据到可用数据集的完整链路2.1 数据获取的合规方式与字段规划数据是这套系统的地基。很多同学第一反应是写爬虫去得物上抓数据这里我必须提醒一句爬虫本身涉及合规风险尤其是商品详情页、用户信息这类数据未经授权抓取并公开使用可能带来法律问题。作为毕设项目我更推荐几种稳妥的替代方案使用公开数据集GitHub 和 Kaggle 上有不少电商公开数据集虽然不一定是得物的原始数据但字段结构完全可以模拟出商品销售场景。自己构造仿真数据根据电商业务的真实规律用 Python 脚本生成一批合理的模拟数据。比如商品销量遵循长尾分布、价格集中在几个主流区间、用户购买行为有周期性。仿真数据的好处是你可以完全控制数据规模和质量想生成一万条就一万条想模拟冷启动场景就专门构造新用户数据。爬取公开排行榜或脱敏后的聚合信息如果确实想体现得物这个主题可以只获取平台公开的榜单类聚合信息注意控制请求频率不做商业化使用并且在使用时说明数据来源。数据字段设计直接决定后面所有模块的复杂度我建议至少规划四类核心表表名核心字段用途用户表用户ID、注册时间、性别、城市、偏好标签用户画像分析、UserCF算法商品表商品ID、名称、品牌、分类、价格、上架时间、图片URL商品维度分析、推荐结果展示订单/行为表订单ID、用户ID、商品ID、购买数量、成交价格、下单时间销售分析、协同过滤评分矩阵来源评分表用户ID、商品ID、评分值、评分时间显式反馈数据可结合购买行为构造我建议把购买行为作为隐式反馈来构造评分因为真实电商场景中用户很少主动打分。一种通用的做法是购买1次记1分复购加分加购物车或浏览记0.5分。这样评分矩阵虽然不是 0-5 的显式评分但能真实反映用户对商品的偏好程度。2.2 数据清洗与特征工程的实操细节拿到原始数据后清洗这一步决定了分析结果靠不靠谱。我见过太多毕设卡在这一步数据没洗干净可视化图表里冒出销量为负数、价格为 0 的异常点答辩时被老师一眼看穿。实操中必须处理的几类问题缺失值处理商品分类为空、用户城市为空这类情况很常见。分类为空可以按品牌名推断或标记为未知城市为空可以填充默认值参与统计时用条件过滤排除掉即可。重复值处理同一订单被重复记录或者同一商品多条记录内容完全一致Pandas 里drop_duplicates()一句搞定但要注意指定判断重复的字段子集避免误删。异常值处理电商数据里销量突增突降其实可能是秒杀活动导致但销量为负、价格为 0 这种物理上不合理的数据必须剔除。我习惯用箱线图或describe()先看分布再按业务规则清洗。时间格式统一Django 的DateTimeField存的是标准时间格式但 CSV 导入时常常变成字符串统一用 Pandas 的to_datetime()转换并提取年、月、周、季度等时间特征方便后续做趋势分析。特征工程方面值得做的是价格带划分和品牌聚合。商品价格是连续变量直接聚合没有意义我建议按业务含义划分0-500 元为入门款500-2000 元为中端款2000-5000 元为高端款5000 元以上为奢品款。划分之后可以直观分析不同价格带的销量占比和用户偏好这个角度在答辩时非常出彩。品牌字段则建议做归一化处理同一品牌的不同写法合并成统一名称。3. 协同过滤推荐模块算法选型、代码实现与效果优化3.1 UserCF 与 ItemCF 的取舍逻辑协同过滤的核心思想很简单物以类聚人以群分。但在落地之前必须先搞清楚两个变体的适用场景差异否则答辩时老师一问你为什么选这个算法就卡住了。**UserCF基于用户的协同过滤**的逻辑是找到和你兴趣相似的一群用户把他们喜欢的商品推荐给你。它的优点是能发现跨品类的意外惊喜比如你平时买球鞋和你相似的用户还喜欢潮玩系统就能把潮玩推给你。缺点是用户数量大时相似度矩阵计算量爆炸而且用户兴趣随时间变化时效果衰减很快。**ItemCF基于物品的协同过滤**的逻辑是找到和你买过的商品相似的其他商品推荐给你。比如你买过某款 AJ1系统发现买过 AJ1 的人也常买同品牌的卫衣就把卫衣推给你。它的优点是计算复杂度相对可控推荐结果可解释性强——因为你看过 A所以推荐相似的 B这在答辩演示时特别好讲。对得物这种潮流电商来说用户数量远大于商品数量而且用户的潮流偏好变化快所以ItemCF 更适合作为核心推荐算法。我的建议是ItemCF 做主力UserCF 作为对比实验放在论文里顺带展示你理解两种算法的差异。3.2 基于 Pandas 的 ItemCF 完整实现说到代码实现很多同学一上来就想着调 Surprise 库或者 Scikit-learn 的包。我不反对用库但毕设答辩时老师大概率会问你这个算法内部怎么工作如果你只会调包答不上来印象分直接打折。我的建议是核心算法自己手写一遍用 Pandas 实现也就六七十行代码过程中每一步都能讲清楚原理。下面是 ItemCF 的核心实现思路我会把关键步骤拆开讲import pandas as pd from sklearn.metrics.pairwise import cosine_similarity import numpy as np # 1. 读取用户行为数据构造评分矩阵 # user_item_matrix: 行是用户列是商品值是评分 orders pd.read_csv(orders.csv) user_item_matrix orders.pivot_table( indexuser_id, columnsitem_id, valuesscore, fill_value0 ) # 2. 计算商品之间的相似度矩阵基于余弦相似度 # 转置后每一行是一个商品的评分向量 item_matrix user_item_matrix.T item_sim_matrix cosine_similarity(item_matrix) item_sim_df pd.DataFrame( item_sim_matrix, indexitem_matrix.index, columnsitem_matrix.index ) # 3. 对指定用户生成推荐 def itemcf_recommend(user_id, top_n10): if user_id not in user_item_matrix.index: # 冷启动返回热门商品兜底 return popularity_scores.head(top_n).index.tolist() # 该用户已交互的商品及评分 user_items user_item_matrix.loc[user_id] interacted user_items[user_items 0] # 候选商品分数累加 scores {} for item_id, rating in interacted.items(): # 找与当前商品最相似的商品 sim_items item_sim_df[item_id].sort_values(ascendingFalse)[1:11] for sim_item, sim_score in sim_items.items(): if sim_item not in interacted.index: # 排除已买过的 scores[sim_item] scores.get(sim_item, 0) sim_score * rating # 按分数排序取TopN recommendations sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] return [item_id for item_id, score in recommendations]这里有几个值得在论文和答辩中展开讲的点相似度计算为什么用余弦相似度因为商品评分向量里大量是 0余弦相似度天然忽略向量长度差异比欧氏距离更适合稀疏评分矩阵。你也可以顺带比较一下皮尔逊相关系数它在处理用户评分尺度偏差时更有优势。为什么要排除已交互的商品推荐系统的基本要求是推荐用户没买过的东西。如果不过滤推荐结果里全是用户买过的商品显得很蠢。热门商品兜底策略这是冷启动的第一层解法。新用户没有行为数据最合理的推荐就是当前平台的热销商品同时也能保证推荐列表不为空。3.3 效果评估与算法优化的进阶方向毕设只做能跑通还不够有效果评估才算完整。我建议用离线评估的方式把用户行为数据按时间分为训练集和测试集比如前 80% 的历史行为做训练后 20% 做测试然后用准确率、召回率、覆盖率这几个指标量化评估推荐效果。def precision_recall(recommended_items, test_items): hit len(set(recommended_items) set(test_items)) precision hit / len(recommended_items) if recommended_items else 0 recall hit / len(test_items) if test_items else 0 return precision, recall推荐 TopN 列表时Precision10、Recall10是最常用的两个指标。纯 ItemCF 的召回率通常不会太高但调到 10% 以上就能说明你的算法是有效的。这里要注意测试集中的正样本其实是用户真实购买了但推荐系统没见过的商品评估逻辑是推荐列表里有多少命中用户真实行为。算法优化方面我建议重点做三个方向既好实现又有内容可写优化方向做法效果惩罚热门物品对热门商品施加权重衰减避免推荐列表全是爆款提升覆盖率和新颖度加入时间衰减越近的购买行为权重越高体现兴趣变化提升时效性更贴合潮流电商场景融合物品属性品牌、分类、价格带等特征作为相似度计算的辅助信号缓解数据稀疏增强推荐可解释性以惩罚热门物品为例具体做法是在计算商品相似度时引入一个逆流行度权重让频繁出现在所有用户行为里的大众商品在相似度累加时被降权。代码层面只需要在分数累加时乘以1 / log(1 popularity[item])但写进论文里就是很完整的优化策略了。4. 可视化分析与 Django 集成把数据变成会说故事的图表4.1 数据分析维度的选择逻辑可视化不是随便画几张图就完事每个图表都要回答一个业务问题。我在做这套系统时先列了五个核心分析问题然后针对每个问题选图表类型哪些商品卖得最好→ 销量 Top10 柱状图 销售额 Top10 柱状图配上商品名和图片展示。不同品牌的销售结构如何→ 品牌销量占比饼图/环形图突出头部品牌。商品价格集中在什么区间→ 价格带分布直方图直观看出平台的定位区间。销量随时间如何变化→ 月度销售趋势折线图按年份对比或按品类筛选。用户的消费能力如何分布→ 用户消费金额区间分布和城市维度地理分布用热力图或者地图组件。这几个维度覆盖了商品—时间—用户—地域四个角度答辩时有足够的分析结论可以讲。我强烈建议在做图表之前先用 Pandas 跑一遍探索性分析把数据里的故事先找出来比如哪个月销量最高、哪个品牌在哪个价格带表现最优然后再用图表把故事讲出来。这样可视化才有洞察力而不是为了画图而画图。4.2 Django 视图 ECharts 的数据传递实践Django 和 ECharts 的集成方式核心就一句话视图函数返回 JSON 数据前端用 Ajax 获取并渲染图表。这里给出一个标准的实现链路。第一步在 Django 视图里聚合数据并返回 JSONfrom django.http import JsonResponse from django.db.models import Sum, Count from .models import Order def sales_top_chart(request): 返回销量Top10商品数据 top_items ( Order.objects.values(item__name, item__price) .annotate(total_salesSum(quantity)) .order_by(-total_sales)[:10] ) data { names: [item[item__name] for item in top_items], sales: [item[total_sales] for item in top_items], prices: [float(item[item__price]) for item in top_items], } return JsonResponse(data)第二步配置 URL 路由把/api/sales_top/映射到上面的视图。第三步在前端页面引入 ECharts用 Ajax 请求数据并渲染div idtopChart stylewidth: 100%; height: 400px;/div$.ajax({ url: /api/sales_top/, type: GET, dataType: json, success: function(res) { var chart echarts.init(document.getElementById(topChart)); chart.setOption({ title: { text: 销量Top10商品 }, tooltip: {}, xAxis: { data: res.names }, yAxis: {}, series: [{ type: bar, data: res.sales }] }); } });这是我踩过几次坑之后最推荐的方案。要注意的几个细节ORM 聚合时用annotate而不是aggregateannotate按商品分组返回多条记录aggregate只返回汇总的一条场景完全不同用错了图就画不出来。Decimal 字段必须转 floatDjango 的价格字段是 Decimal 类型直接放进 JSON 会序列化报错用float()转换之后再返回。中文标签的编码问题ECharts 的图表标题和标签直接用中文没有问题的但注意 HTML 文件要在meta charsetutf-8标签下不然前端页面显示乱码。4.3 可视化大屏的布局设计与性能考量毕设演示时一个像样的可视化大屏会大大加分。大屏布局我建议采用经典的总-分结构顶部放核心指标卡片总销售额、总订单量、活跃用户数、客单价左下和右下放商品分析和用户画像图表中间主体放地图或综合榜单。ECharts 官方有 grid 布局方案也可以用 CSS Grid 或 Flex 配合实现。性能方面需要提前想清楚一件事图表数量多的时候不要让每个图表独立向后端发请求。我建议做一个统一的聚合接口一次请求返回整个大屏需要的所有数据前端拿到后一次性渲染所有图表。这样既减少网络开销又避免页面加载时图表逐个弹出的尴尬。另外建议把后端聚合的数据缓存到内存或 Redis 里因为可视化分析的数据往往不是实时变化的。Django 自带的cache框架加上 Redis 作为缓存后端设置 10 分钟过期时间就足够应付演示场景了。from django.core.cache import cache def dashboard_data(request): cached cache.get(dashboard_data) if cached: return JsonResponse(cached) # ... 聚合计算逻辑 ... cache.set(dashboard_data, data, timeout600) return JsonResponse(data)5. 大模型与 Agent 视角给毕设加一个别人没有的亮点5.1 自然语言查询从看图表到问数据现在很多高校对毕设的选题要求越来越偏向新技术大模型Agent这些词频繁出现在老师的期望里。但本科阶段直接做大模型应用很容易失控——既要调 API 又要做微调又要保证效果周期根本来不及。我的建议是用大模型 数据分析的轻量结合做亮点把大模型定位成智能分析助理而不是整个系统的核心这样风险和收益都可控。一个可落地的功能是自然语言查询用户在输入框里打出上个月销量最高的三个品牌是什么系统调用大模型接口把自然语言转换成结构化的查询条件后端根据查询条件从数据库里检索并生成图表数据最后返回结果图表和一段文字结论。这个功能的技术链路不复杂但非常出效果前端聊天式交互 → 后端调用大模型接口做意图识别和参数抽取 → 转成 Django ORM 查询 → 返回图表和结论。本质上是一个受限场景下的 Text-to-SQL/Semantic Search 应用既蹭到了大模型热点工作量又在可控范围内。5.2 Agent 化的推荐与解释把推荐结果变成推荐理由另一个进阶方向是把推荐系统 Agent 化——不光是给出推荐商品列表还让系统用自然语言向用户解释为什么推荐这款商品。这就是推荐系统的可解释性也是当前推荐方向的研究热点之一。具体做法是ItemCF 算法算出一个推荐列表之后同时记录每个推荐商品的推荐理由比如因为你购买过 AJ1 低帮而且买过 AJ1 低帮的用户 80% 也关注了同品牌的卫衣所以为你推荐这款卫衣。把这些结构化信息组装成提示词让大模型生成一段流畅的推荐语展示在页面上。这个功能最大的好处是演示效果好到离谱。答辩时老师看到的不再是冷冰冰的推荐商品卡片而是像电商 App 一样的猜你喜欢加上了人情味的推荐语。你还可以在论文里写本系统在传统协同过滤的基础上引入了大模型生成推荐解释提升了推荐系统的透明度和用户信任度这就是一个很明确的创新点。不过做之前要控制好预算和响应速度。大模型 API 的调用建议放到异步任务里处理或者对推荐理由做缓存避免每次刷新页面都重复请求模型接口。用缓存后只有首次推荐需要等几秒生成理由后续访问秒开。6. 从开发到答辩的避坑清单与实操经验6.1 开发期最容易踩的五个坑这个项目我前后带学生做过好几轮过程中踩过的坑都很有代表性提前避掉能省下大量时间。搜索引擎让你装啥你就装啥版本不锁Django 4.x 和 3.x 的某些配置写法不同Pandas 2.x 的 API 变化也不少。建议开头就写一个requirements.txt锁定关键依赖版本比如Django4.2.*、pandas2.0.*。不然开发到一半运行报错查半天发现是版本兼容问题非常崩溃。MySQL 字符集没设成 utf8mb4商品名称里如果包含 emoji 或特殊符号默认的 utf8 字符集会报错。建库时直接指定utf8mb4Django 连接时在DATABASES配置里加上OPTIONS: {charset: utf8mb4}一步到位。Pandas 处理后的数据直接塞进 Django 模板Pandas 的 Series 或 DataFrame 不能直接作为模板变量渲染必须先转成 list、dict 或 JSON 字符串再传给前端。这个错误很低级但非常常见。签名图和可视化图表的坐标轴标签太长商品名称动辄十几二十个字横轴放不下就重叠。处理办法是截断显示前端 ECharts 里加axisLabel: { interval: 0, rotate: 30 }或者后端把名称截断到 8 个字符并加省略号。演示数据量太小导致图表难看如果你只生成了一百条订单柱状图和折线图都会显得很单薄。建议生成至少十万条订单数据模拟一年跨度、多城市、多品类的数据图表才有大数据的感觉。6.2 部署、演示与答辩准备的实操建议毕设最终要演示我强烈建议在正式答辩前把系统部署到云服务器上而不是只在本地跑给老师看。本地演示的风险在于万一现场网络波动、电脑出问题、数据库服务没启动场面会很尴尬。部署到公网服务器后你只需要在电脑上打开浏览器输入网址就能演示稳定性和安全感完全不一样。部署方案我给你一个低成本路径随便买一台最便宜的云服务器1核2G 就够了装好 Ubuntu、Python 3.10、MySQL然后使用 Gunicorn Nginx 的标准组合上线 Django 项目。要把静态文件ECharts 的 js、图片等用collectstatic收集起来交给 Nginx 处理不然静态资源 404 会让页面变得很丑。答辩演示时的讲解顺序也很重要。我建议按业务场景 → 数据概况 → 分析结论 → 推荐效果 → 创新亮点五步走先讲得物平台和电商推荐的价值再展示数据量级和整体大屏然后选两三个有意思的分析结论深入讲接着演示推荐系统给不同用户生成的不同推荐列表最后点出大模型解释推荐理由这个创新点。每一步都有实物可看节奏控制在 8 到 10 分钟基本不会卡壳。最后分享一个我个人的经验毕设做这种综合型系统最忌讳的是把每个模块都做到 100 分然后整体烂尾。正确的策略是核心链路做到 90 分旁支功能做到 60 分。所谓核心链路就是数据可看、推荐可用、演示可讲这三件事——确保数据清洗干净、推荐列表能正常输出、页面展示流畅这三件事全程无 bug你的毕设就成功了一大半。至于 Admin 后台要不要做权限控制、用户注册要不要做邮箱验证这些都属于锦上添花时间不够就砍掉不要因为纠结小功能耽误了主线。项目做完之后我会再单独把协同过滤的数学推导和 Django 部署细节拆开来写这两块也是被问得最多的部分到时候可以照着一步步来。
得物商品销售可视化分析与协同过滤推荐系统实战
如果你正在为计算机毕设选题发愁又不想做那种满大街都是的图书管理系统或者学生信息管理系统得物商品销售可视化分析加协同过滤推荐系统这个方向确实值得认真考虑一下。它把电商数据分析、可视化大屏、推荐算法三个热门考点串在了一条业务链上——从商品销售数据里挖规律、用图表讲清楚业务结论、再基于用户行为做个性化推荐一套系统下来前端展示、后端开发、算法实现、数据库设计全都覆盖到了。无论是本科毕业设计还是求职作品集这个项目都能拿得出手。这篇内容我就以过来人的角度把这个项目从选题、数据准备、算法实现到可视化集成、进阶亮点、答辩避坑完整拆一遍。适合正在做毕设的计算机相关专业学生也适合想练手电商数据分析和推荐系统的开发者。我会把每个关键环节的为什么这么做也讲清楚不是光贴代码让你抄而是让你真正明白这套系统是怎么搭起来的。1. 选题逻辑拆解为什么得物商品数据适合做毕设1.1 这个题目的答辩优势在哪里先说选题。很多同学纠结怕题目太简单被老师挑刺又怕太难做不完。得物商品销售可视化加推荐系统这个组合恰好卡在一个本科毕设的黄金难度区间——数据分析部分足够展示工程能力协同过滤算法足够展示理论基础可视化部分又足够展示审美和交互设计。三个模块不是硬凑的它们之间有一条完整的业务逻辑线平台积累了海量商品和用户行为数据 → 通过数据分析洞察销售规律 → 借助推荐算法提升转化率。这条线本身就是电商行业的标准业务流程答辩的时候老师问你这个系统有什么价值你完全可以从业务闭环的角度回答。另外得物这个平台本身自带话题度。它主打潮流单品、球鞋、限量发售、二手交易商品的价格波动和用户偏好非常有特点。比如某款限量球鞋发售当天的销量曲线、不同品牌在不同价格带上的分布、潮流单品的地域热度差异这些分析维度比传统的某某超市销售分析有意思得多也更容易在答辩时讲出亮点。1.2 技术选型与前因后果技术栈我建议这样定后端用 Python Django推荐算法用协同过滤可视化用 ECharts数据库用 MySQL数据分析用 Pandas。这套组合的合理性在于Django 自带 Admin 后台和 ORM可以快速把商品、用户、订单这些数据模型建好并管理起来。毕设周期紧张不需要像 Spring 全家桶那样配一大堆东西Django 开箱即用的特点能帮你节省大量开发时间。Python 生态对数据处理最友好。Pandas 做清洗聚合、Scikit-learn 做算法评估、Matplotlib/Seaborn 做探索性分析全程只用一种语言不用在前后端切换心智。ECharts 是可视化大屏的事实标准。社区案例多、配置项丰富、中文文档齐全动态效果和交互性比 Matplotlib 生成的静态图强太多直接输出到浏览器展示非常契合毕设答辩的演示场景。协同过滤这块本科阶段我建议用基于物品的协同过滤ItemCF做核心推荐再用基于用户的协同过滤UserCF做对照。这两个算法是推荐系统课程的必讲内容实现难度适中又有足够的优化空间——后面我会具体讲怎么在基础版本上做改进。2. 数据层设计从原始数据到可用数据集的完整链路2.1 数据获取的合规方式与字段规划数据是这套系统的地基。很多同学第一反应是写爬虫去得物上抓数据这里我必须提醒一句爬虫本身涉及合规风险尤其是商品详情页、用户信息这类数据未经授权抓取并公开使用可能带来法律问题。作为毕设项目我更推荐几种稳妥的替代方案使用公开数据集GitHub 和 Kaggle 上有不少电商公开数据集虽然不一定是得物的原始数据但字段结构完全可以模拟出商品销售场景。自己构造仿真数据根据电商业务的真实规律用 Python 脚本生成一批合理的模拟数据。比如商品销量遵循长尾分布、价格集中在几个主流区间、用户购买行为有周期性。仿真数据的好处是你可以完全控制数据规模和质量想生成一万条就一万条想模拟冷启动场景就专门构造新用户数据。爬取公开排行榜或脱敏后的聚合信息如果确实想体现得物这个主题可以只获取平台公开的榜单类聚合信息注意控制请求频率不做商业化使用并且在使用时说明数据来源。数据字段设计直接决定后面所有模块的复杂度我建议至少规划四类核心表表名核心字段用途用户表用户ID、注册时间、性别、城市、偏好标签用户画像分析、UserCF算法商品表商品ID、名称、品牌、分类、价格、上架时间、图片URL商品维度分析、推荐结果展示订单/行为表订单ID、用户ID、商品ID、购买数量、成交价格、下单时间销售分析、协同过滤评分矩阵来源评分表用户ID、商品ID、评分值、评分时间显式反馈数据可结合购买行为构造我建议把购买行为作为隐式反馈来构造评分因为真实电商场景中用户很少主动打分。一种通用的做法是购买1次记1分复购加分加购物车或浏览记0.5分。这样评分矩阵虽然不是 0-5 的显式评分但能真实反映用户对商品的偏好程度。2.2 数据清洗与特征工程的实操细节拿到原始数据后清洗这一步决定了分析结果靠不靠谱。我见过太多毕设卡在这一步数据没洗干净可视化图表里冒出销量为负数、价格为 0 的异常点答辩时被老师一眼看穿。实操中必须处理的几类问题缺失值处理商品分类为空、用户城市为空这类情况很常见。分类为空可以按品牌名推断或标记为未知城市为空可以填充默认值参与统计时用条件过滤排除掉即可。重复值处理同一订单被重复记录或者同一商品多条记录内容完全一致Pandas 里drop_duplicates()一句搞定但要注意指定判断重复的字段子集避免误删。异常值处理电商数据里销量突增突降其实可能是秒杀活动导致但销量为负、价格为 0 这种物理上不合理的数据必须剔除。我习惯用箱线图或describe()先看分布再按业务规则清洗。时间格式统一Django 的DateTimeField存的是标准时间格式但 CSV 导入时常常变成字符串统一用 Pandas 的to_datetime()转换并提取年、月、周、季度等时间特征方便后续做趋势分析。特征工程方面值得做的是价格带划分和品牌聚合。商品价格是连续变量直接聚合没有意义我建议按业务含义划分0-500 元为入门款500-2000 元为中端款2000-5000 元为高端款5000 元以上为奢品款。划分之后可以直观分析不同价格带的销量占比和用户偏好这个角度在答辩时非常出彩。品牌字段则建议做归一化处理同一品牌的不同写法合并成统一名称。3. 协同过滤推荐模块算法选型、代码实现与效果优化3.1 UserCF 与 ItemCF 的取舍逻辑协同过滤的核心思想很简单物以类聚人以群分。但在落地之前必须先搞清楚两个变体的适用场景差异否则答辩时老师一问你为什么选这个算法就卡住了。**UserCF基于用户的协同过滤**的逻辑是找到和你兴趣相似的一群用户把他们喜欢的商品推荐给你。它的优点是能发现跨品类的意外惊喜比如你平时买球鞋和你相似的用户还喜欢潮玩系统就能把潮玩推给你。缺点是用户数量大时相似度矩阵计算量爆炸而且用户兴趣随时间变化时效果衰减很快。**ItemCF基于物品的协同过滤**的逻辑是找到和你买过的商品相似的其他商品推荐给你。比如你买过某款 AJ1系统发现买过 AJ1 的人也常买同品牌的卫衣就把卫衣推给你。它的优点是计算复杂度相对可控推荐结果可解释性强——因为你看过 A所以推荐相似的 B这在答辩演示时特别好讲。对得物这种潮流电商来说用户数量远大于商品数量而且用户的潮流偏好变化快所以ItemCF 更适合作为核心推荐算法。我的建议是ItemCF 做主力UserCF 作为对比实验放在论文里顺带展示你理解两种算法的差异。3.2 基于 Pandas 的 ItemCF 完整实现说到代码实现很多同学一上来就想着调 Surprise 库或者 Scikit-learn 的包。我不反对用库但毕设答辩时老师大概率会问你这个算法内部怎么工作如果你只会调包答不上来印象分直接打折。我的建议是核心算法自己手写一遍用 Pandas 实现也就六七十行代码过程中每一步都能讲清楚原理。下面是 ItemCF 的核心实现思路我会把关键步骤拆开讲import pandas as pd from sklearn.metrics.pairwise import cosine_similarity import numpy as np # 1. 读取用户行为数据构造评分矩阵 # user_item_matrix: 行是用户列是商品值是评分 orders pd.read_csv(orders.csv) user_item_matrix orders.pivot_table( indexuser_id, columnsitem_id, valuesscore, fill_value0 ) # 2. 计算商品之间的相似度矩阵基于余弦相似度 # 转置后每一行是一个商品的评分向量 item_matrix user_item_matrix.T item_sim_matrix cosine_similarity(item_matrix) item_sim_df pd.DataFrame( item_sim_matrix, indexitem_matrix.index, columnsitem_matrix.index ) # 3. 对指定用户生成推荐 def itemcf_recommend(user_id, top_n10): if user_id not in user_item_matrix.index: # 冷启动返回热门商品兜底 return popularity_scores.head(top_n).index.tolist() # 该用户已交互的商品及评分 user_items user_item_matrix.loc[user_id] interacted user_items[user_items 0] # 候选商品分数累加 scores {} for item_id, rating in interacted.items(): # 找与当前商品最相似的商品 sim_items item_sim_df[item_id].sort_values(ascendingFalse)[1:11] for sim_item, sim_score in sim_items.items(): if sim_item not in interacted.index: # 排除已买过的 scores[sim_item] scores.get(sim_item, 0) sim_score * rating # 按分数排序取TopN recommendations sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] return [item_id for item_id, score in recommendations]这里有几个值得在论文和答辩中展开讲的点相似度计算为什么用余弦相似度因为商品评分向量里大量是 0余弦相似度天然忽略向量长度差异比欧氏距离更适合稀疏评分矩阵。你也可以顺带比较一下皮尔逊相关系数它在处理用户评分尺度偏差时更有优势。为什么要排除已交互的商品推荐系统的基本要求是推荐用户没买过的东西。如果不过滤推荐结果里全是用户买过的商品显得很蠢。热门商品兜底策略这是冷启动的第一层解法。新用户没有行为数据最合理的推荐就是当前平台的热销商品同时也能保证推荐列表不为空。3.3 效果评估与算法优化的进阶方向毕设只做能跑通还不够有效果评估才算完整。我建议用离线评估的方式把用户行为数据按时间分为训练集和测试集比如前 80% 的历史行为做训练后 20% 做测试然后用准确率、召回率、覆盖率这几个指标量化评估推荐效果。def precision_recall(recommended_items, test_items): hit len(set(recommended_items) set(test_items)) precision hit / len(recommended_items) if recommended_items else 0 recall hit / len(test_items) if test_items else 0 return precision, recall推荐 TopN 列表时Precision10、Recall10是最常用的两个指标。纯 ItemCF 的召回率通常不会太高但调到 10% 以上就能说明你的算法是有效的。这里要注意测试集中的正样本其实是用户真实购买了但推荐系统没见过的商品评估逻辑是推荐列表里有多少命中用户真实行为。算法优化方面我建议重点做三个方向既好实现又有内容可写优化方向做法效果惩罚热门物品对热门商品施加权重衰减避免推荐列表全是爆款提升覆盖率和新颖度加入时间衰减越近的购买行为权重越高体现兴趣变化提升时效性更贴合潮流电商场景融合物品属性品牌、分类、价格带等特征作为相似度计算的辅助信号缓解数据稀疏增强推荐可解释性以惩罚热门物品为例具体做法是在计算商品相似度时引入一个逆流行度权重让频繁出现在所有用户行为里的大众商品在相似度累加时被降权。代码层面只需要在分数累加时乘以1 / log(1 popularity[item])但写进论文里就是很完整的优化策略了。4. 可视化分析与 Django 集成把数据变成会说故事的图表4.1 数据分析维度的选择逻辑可视化不是随便画几张图就完事每个图表都要回答一个业务问题。我在做这套系统时先列了五个核心分析问题然后针对每个问题选图表类型哪些商品卖得最好→ 销量 Top10 柱状图 销售额 Top10 柱状图配上商品名和图片展示。不同品牌的销售结构如何→ 品牌销量占比饼图/环形图突出头部品牌。商品价格集中在什么区间→ 价格带分布直方图直观看出平台的定位区间。销量随时间如何变化→ 月度销售趋势折线图按年份对比或按品类筛选。用户的消费能力如何分布→ 用户消费金额区间分布和城市维度地理分布用热力图或者地图组件。这几个维度覆盖了商品—时间—用户—地域四个角度答辩时有足够的分析结论可以讲。我强烈建议在做图表之前先用 Pandas 跑一遍探索性分析把数据里的故事先找出来比如哪个月销量最高、哪个品牌在哪个价格带表现最优然后再用图表把故事讲出来。这样可视化才有洞察力而不是为了画图而画图。4.2 Django 视图 ECharts 的数据传递实践Django 和 ECharts 的集成方式核心就一句话视图函数返回 JSON 数据前端用 Ajax 获取并渲染图表。这里给出一个标准的实现链路。第一步在 Django 视图里聚合数据并返回 JSONfrom django.http import JsonResponse from django.db.models import Sum, Count from .models import Order def sales_top_chart(request): 返回销量Top10商品数据 top_items ( Order.objects.values(item__name, item__price) .annotate(total_salesSum(quantity)) .order_by(-total_sales)[:10] ) data { names: [item[item__name] for item in top_items], sales: [item[total_sales] for item in top_items], prices: [float(item[item__price]) for item in top_items], } return JsonResponse(data)第二步配置 URL 路由把/api/sales_top/映射到上面的视图。第三步在前端页面引入 ECharts用 Ajax 请求数据并渲染div idtopChart stylewidth: 100%; height: 400px;/div$.ajax({ url: /api/sales_top/, type: GET, dataType: json, success: function(res) { var chart echarts.init(document.getElementById(topChart)); chart.setOption({ title: { text: 销量Top10商品 }, tooltip: {}, xAxis: { data: res.names }, yAxis: {}, series: [{ type: bar, data: res.sales }] }); } });这是我踩过几次坑之后最推荐的方案。要注意的几个细节ORM 聚合时用annotate而不是aggregateannotate按商品分组返回多条记录aggregate只返回汇总的一条场景完全不同用错了图就画不出来。Decimal 字段必须转 floatDjango 的价格字段是 Decimal 类型直接放进 JSON 会序列化报错用float()转换之后再返回。中文标签的编码问题ECharts 的图表标题和标签直接用中文没有问题的但注意 HTML 文件要在meta charsetutf-8标签下不然前端页面显示乱码。4.3 可视化大屏的布局设计与性能考量毕设演示时一个像样的可视化大屏会大大加分。大屏布局我建议采用经典的总-分结构顶部放核心指标卡片总销售额、总订单量、活跃用户数、客单价左下和右下放商品分析和用户画像图表中间主体放地图或综合榜单。ECharts 官方有 grid 布局方案也可以用 CSS Grid 或 Flex 配合实现。性能方面需要提前想清楚一件事图表数量多的时候不要让每个图表独立向后端发请求。我建议做一个统一的聚合接口一次请求返回整个大屏需要的所有数据前端拿到后一次性渲染所有图表。这样既减少网络开销又避免页面加载时图表逐个弹出的尴尬。另外建议把后端聚合的数据缓存到内存或 Redis 里因为可视化分析的数据往往不是实时变化的。Django 自带的cache框架加上 Redis 作为缓存后端设置 10 分钟过期时间就足够应付演示场景了。from django.core.cache import cache def dashboard_data(request): cached cache.get(dashboard_data) if cached: return JsonResponse(cached) # ... 聚合计算逻辑 ... cache.set(dashboard_data, data, timeout600) return JsonResponse(data)5. 大模型与 Agent 视角给毕设加一个别人没有的亮点5.1 自然语言查询从看图表到问数据现在很多高校对毕设的选题要求越来越偏向新技术大模型Agent这些词频繁出现在老师的期望里。但本科阶段直接做大模型应用很容易失控——既要调 API 又要做微调又要保证效果周期根本来不及。我的建议是用大模型 数据分析的轻量结合做亮点把大模型定位成智能分析助理而不是整个系统的核心这样风险和收益都可控。一个可落地的功能是自然语言查询用户在输入框里打出上个月销量最高的三个品牌是什么系统调用大模型接口把自然语言转换成结构化的查询条件后端根据查询条件从数据库里检索并生成图表数据最后返回结果图表和一段文字结论。这个功能的技术链路不复杂但非常出效果前端聊天式交互 → 后端调用大模型接口做意图识别和参数抽取 → 转成 Django ORM 查询 → 返回图表和结论。本质上是一个受限场景下的 Text-to-SQL/Semantic Search 应用既蹭到了大模型热点工作量又在可控范围内。5.2 Agent 化的推荐与解释把推荐结果变成推荐理由另一个进阶方向是把推荐系统 Agent 化——不光是给出推荐商品列表还让系统用自然语言向用户解释为什么推荐这款商品。这就是推荐系统的可解释性也是当前推荐方向的研究热点之一。具体做法是ItemCF 算法算出一个推荐列表之后同时记录每个推荐商品的推荐理由比如因为你购买过 AJ1 低帮而且买过 AJ1 低帮的用户 80% 也关注了同品牌的卫衣所以为你推荐这款卫衣。把这些结构化信息组装成提示词让大模型生成一段流畅的推荐语展示在页面上。这个功能最大的好处是演示效果好到离谱。答辩时老师看到的不再是冷冰冰的推荐商品卡片而是像电商 App 一样的猜你喜欢加上了人情味的推荐语。你还可以在论文里写本系统在传统协同过滤的基础上引入了大模型生成推荐解释提升了推荐系统的透明度和用户信任度这就是一个很明确的创新点。不过做之前要控制好预算和响应速度。大模型 API 的调用建议放到异步任务里处理或者对推荐理由做缓存避免每次刷新页面都重复请求模型接口。用缓存后只有首次推荐需要等几秒生成理由后续访问秒开。6. 从开发到答辩的避坑清单与实操经验6.1 开发期最容易踩的五个坑这个项目我前后带学生做过好几轮过程中踩过的坑都很有代表性提前避掉能省下大量时间。搜索引擎让你装啥你就装啥版本不锁Django 4.x 和 3.x 的某些配置写法不同Pandas 2.x 的 API 变化也不少。建议开头就写一个requirements.txt锁定关键依赖版本比如Django4.2.*、pandas2.0.*。不然开发到一半运行报错查半天发现是版本兼容问题非常崩溃。MySQL 字符集没设成 utf8mb4商品名称里如果包含 emoji 或特殊符号默认的 utf8 字符集会报错。建库时直接指定utf8mb4Django 连接时在DATABASES配置里加上OPTIONS: {charset: utf8mb4}一步到位。Pandas 处理后的数据直接塞进 Django 模板Pandas 的 Series 或 DataFrame 不能直接作为模板变量渲染必须先转成 list、dict 或 JSON 字符串再传给前端。这个错误很低级但非常常见。签名图和可视化图表的坐标轴标签太长商品名称动辄十几二十个字横轴放不下就重叠。处理办法是截断显示前端 ECharts 里加axisLabel: { interval: 0, rotate: 30 }或者后端把名称截断到 8 个字符并加省略号。演示数据量太小导致图表难看如果你只生成了一百条订单柱状图和折线图都会显得很单薄。建议生成至少十万条订单数据模拟一年跨度、多城市、多品类的数据图表才有大数据的感觉。6.2 部署、演示与答辩准备的实操建议毕设最终要演示我强烈建议在正式答辩前把系统部署到云服务器上而不是只在本地跑给老师看。本地演示的风险在于万一现场网络波动、电脑出问题、数据库服务没启动场面会很尴尬。部署到公网服务器后你只需要在电脑上打开浏览器输入网址就能演示稳定性和安全感完全不一样。部署方案我给你一个低成本路径随便买一台最便宜的云服务器1核2G 就够了装好 Ubuntu、Python 3.10、MySQL然后使用 Gunicorn Nginx 的标准组合上线 Django 项目。要把静态文件ECharts 的 js、图片等用collectstatic收集起来交给 Nginx 处理不然静态资源 404 会让页面变得很丑。答辩演示时的讲解顺序也很重要。我建议按业务场景 → 数据概况 → 分析结论 → 推荐效果 → 创新亮点五步走先讲得物平台和电商推荐的价值再展示数据量级和整体大屏然后选两三个有意思的分析结论深入讲接着演示推荐系统给不同用户生成的不同推荐列表最后点出大模型解释推荐理由这个创新点。每一步都有实物可看节奏控制在 8 到 10 分钟基本不会卡壳。最后分享一个我个人的经验毕设做这种综合型系统最忌讳的是把每个模块都做到 100 分然后整体烂尾。正确的策略是核心链路做到 90 分旁支功能做到 60 分。所谓核心链路就是数据可看、推荐可用、演示可讲这三件事——确保数据清洗干净、推荐列表能正常输出、页面展示流畅这三件事全程无 bug你的毕设就成功了一大半。至于 Admin 后台要不要做权限控制、用户注册要不要做邮箱验证这些都属于锦上添花时间不够就砍掉不要因为纠结小功能耽误了主线。项目做完之后我会再单独把协同过滤的数学推导和 Django 部署细节拆开来写这两块也是被问得最多的部分到时候可以照着一步步来。
