得物商品销售可视化分析与协同过滤推荐系统实战

如果你正在为计算机毕设选题发愁，又不想做那种满大街都是的图书管理系统或者学生信息管理系统，得物商品销售可视化分析加协同过滤推荐系统这个方向，确实值得认真考虑一下。它把电商数据分析、可视化大屏、推荐算法三个热门考点串在了一条业务链上——从商品销售数据里挖规律、用图表讲清楚业务结论、再基于用户行为做个性化推荐，一套系统下来，前端展示、后端开发、算法实现、数据库设计全都覆盖到了。无论是本科毕业设计还是求职作品集，这个项目都能拿得出手。

这篇内容我就以过来人的角度，把这个项目从选题、数据准备、算法实现到可视化集成、进阶亮点、答辩避坑，完整拆一遍。适合正在做毕设的计算机相关专业学生，也适合想练手电商数据分析和推荐系统的开发者。我会把每个关键环节的"为什么这么做"也讲清楚，不是光贴代码让你抄，而是让你真正明白这套系统是怎么搭起来的。

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 脚本生成一批合理的模拟数据。比如商品销量遵循长尾分布、价格集中在几个主流区间、用户购买行为有周期性。仿真数据的好处是你可以完全控制数据规模和质量，想生成一万条就一万条，想模拟冷启动场景就专门构造新用户数据。
• 爬取公开排行榜或脱敏后的聚合信息：如果确实想体现"得物"这个主题，可以只获取平台公开的榜单类聚合信息，注意控制请求频率，不做商业化使用，并且在使用时说明数据来源。

数据字段设计直接决定后面所有模块的复杂度，我建议至少规划四类核心表：

我建议把"购买行为"作为隐式反馈来构造评分，因为真实电商场景中用户很少主动打分。一种通用的做法是：购买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( index='user_id', columns='item_id', values='score', fill_value=0 ) # 2. 计算商品之间的相似度矩阵（基于余弦相似度） # 转置后每一行是一个商品的评分向量 item_matrix = user_item_matrix.T item_sim_matrix = cosine_similarity(item_matrix) item_sim_df = pd.DataFrame( item_sim_matrix, index=item_matrix.index, columns=item_matrix.index ) # 3. 对指定用户生成推荐 def itemcf_recommend(user_id, top_n=10): 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(ascending=False)[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(), key=lambda x: x[1], reverse=True)[: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 列表时，Precision@10、Recall@10是最常用的两个指标。纯 ItemCF 的召回率通常不会太高，但调到 10% 以上就能说明你的算法是有效的。这里要注意：测试集中的"正样本"其实是用户真实购买了但推荐系统没见过的商品，评估逻辑是"推荐列表里有多少命中用户真实行为"。

算法优化方面，我建议重点做三个方向，既好实现又有内容可写：

以惩罚热门物品为例，具体做法是在计算商品相似度时引入一个逆流行度权重，让频繁出现在所有用户行为里的"大众商品"在相似度累加时被降权。代码层面只需要在分数累加时乘以1 / log(1 + popularity[item])，但写进论文里就是很完整的优化策略了。

4. 可视化分析与 Django 集成：把数据变成会说故事的图表

4.1 数据分析维度的选择逻辑

可视化不是随便画几张图就完事，每个图表都要回答一个业务问题。我在做这套系统时先列了五个核心分析问题，然后针对每个问题选图表类型：

• 哪些商品卖得最好？→ 销量 Top10 柱状图 + 销售额 Top10 柱状图，配上商品名和图片展示。
• 不同品牌的销售结构如何？→ 品牌销量占比饼图/环形图，突出头部品牌。
• 商品价格集中在什么区间？→ 价格带分布直方图，直观看出平台的定位区间。
• 销量随时间如何变化？→ 月度销售趋势折线图，按年份对比或按品类筛选。
• 用户的消费能力如何分布？→ 用户消费金额区间分布和城市维度地理分布，用热力图或者地图组件。

这几个维度覆盖了"商品—时间—用户—地域"四个角度，答辩时有足够的分析结论可以讲。我强烈建议在做图表之前先用 Pandas 跑一遍探索性分析，把数据里的"故事"先找出来，比如哪个月销量最高、哪个品牌在哪个价格带表现最优，然后再用图表把故事讲出来。这样可视化才有洞察力，而不是为了画图而画图。

4.2 Django 视图 + ECharts 的数据传递实践

Django 和 ECharts 的集成方式，核心就一句话：视图函数返回 JSON 数据，前端用 Ajax 获取并渲染图表。这里给出一个标准的实现链路。

第一步，在 Django 视图里聚合数据并返回 JSON：

from 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_sales=Sum('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 id="topChart" style="width: 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而不是aggregate：annotate按商品分组返回多条记录，aggregate只返回汇总的一条，场景完全不同，用错了图就画不出来。
• Decimal 字段必须转 float：Django 的价格字段是 Decimal 类型，直接放进 JSON 会序列化报错，用float()转换之后再返回。
• 中文标签的编码问题：ECharts 的图表标题和标签直接用中文没有问题的，但注意 HTML 文件要在meta charset="utf-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, timeout=600) 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，锁定关键依赖版本，比如Django==4.2.*、pandas==2.0.*。不然开发到一半运行报错，查半天发现是版本兼容问题，非常崩溃。
• MySQL 字符集没设成 utf8mb4：商品名称里如果包含 emoji 或特殊符号，默认的 utf8 字符集会报错。建库时直接指定utf8mb4，Django 连接时在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 部署细节拆开来写，这两块也是被问得最多的部分，到时候可以照着一步步来。