做计算机毕业设计这几年我见过太多同学选了“商品推荐系统”或者“电商数据分析”这类题目结果做着做着就卡在“数据从哪来”“推荐逻辑怎么做”“图表怎么摆”上最后草草交差。你手上这个题目——Python商品推荐系统 商品比价系统 商品可视化 电商大数据——其实是个非常典型的“一个题目吃透全链路”的毕设组合它把电商领域里最核心的几个功能点全部串起来了数据采集、数据清洗、存储建模、推荐算法、比价逻辑、可视化报表展示。只要理清思路这个题目的完成度可以做得相当高答辩的时候也特别容易讲出亮点。这篇文章我不打算给你堆一堆教科书式的概念而是直接按照我实际带项目的经验把这个毕设从0到1的完整思路、技术选型、核心代码、论文写作、PPT和讲解视频的注意事项全部拆开揉碎讲清楚。不管你是刚接触Python的萌新还是已经有点基础但不知道从哪下手的同学这篇文章都能给你一条可以直接落地的路径。1. 项目整体设计与技术选型的思路这个题目看起来是四个功能点实际上它们之间是有清晰依赖关系的。很多同学一上来就着急写代码结果写到一半发现数据不够、表结构要返工、推荐算法跑不起来全是因为没有先做顶层设计。1.1 为什么把推荐、比价、可视化打包在一个系统里先看这个组合的逻辑电商大数据是底座爬虫把商品数据抓下来存进数据库商品可视化负责把数据变成人看得懂的图表让系统“有脸面”商品推荐系统负责根据用户行为做个性化推荐让系统“有脑子”商品比价系统负责多平台价格对比让系统“有价值”。四者层层递进正好对应着数据分析的完整流程——采集、清洗、分析、展示、应用。毕设答辩时老师最常问的一句话就是“你这个系统的创新点在哪里”。如果你只做一个普通的CRUD管理系统那基本没什么竞争力。但这个组合天然就有故事可以讲推荐系统解决“用户找商品难”的问题比价系统解决“用户买贵了”的问题可视化解决“数据看不懂”的问题。三个痛点对应三个功能模块逻辑闭环非常清晰。1.2 技术栈怎么选Python生态里最稳的组合毕设的技术选型原则只有一个既要体现实力又要保证自己能驾驭。我不建议在这个阶段引入太多花哨的新框架选最成熟的组合最稳妥。后端框架我推荐Django不是因为它比Flask高级而是因为Django自带的admin后台、ORM、模板系统、用户认证模块能帮你省下大量写基础代码的时间。你想想毕设本来就时间紧用Flask虽然灵活但用户注册登录、数据库迁移、表单处理这些都要自己搭光这些杂活就能耗掉你两周。而Django把这些东西都封装好了你只需要专注写核心业务逻辑。数据库方面MySQL是很多学校实验室的标配但如果你是个人开发我更推荐SQLite或者PostgreSQL。SQLite的优势是零配置文件即数据库适合快速开发和演示PostgreSQL功能更强对JSON字段支持好如果你的商品数据是爬虫抓下来的半结构化数据用JSONField会方便很多。我个人在实际项目中更倾向MySQL因为论文里写“使用MySQL数据库”听起来更正式而且Navicat操作起来直观答辩演示的时候调整数据也方便。前端可视化这块ECharts是第一选择没有之一。它基于JavaScript图表类型丰富交互效果好而且百度生态在国内有大量中文文档遇到问题一搜就有答案。有些同学想用Python的Matplotlib或者Pyecharts我能理解这种“想少碰前端”的想法但Matplotlib做出来的图表风格偏学术交互性差Pyecharts虽然生成的也是ECharts图表但底层封装的灵活性比不上直接写JavaScript配置。既然你报表模块要做成网页展示给用户看直接上ECharts才是最佳方案。推荐算法方面本科生只要能实现协同过滤Collaborative Filtering就已经能拿到不错的分数了。具体选基于用户的协同过滤还是基于物品的协同过滤后面我会单独讲这里先卖个关子。1.3 系统架构怎么搭从数据到展示的一条线推荐系统的经典架构是分层架构每一层各司其职层与层之间通过数据接口通信。我在实际项目中通常是这么分层数据采集层负责用爬虫抓取电商平台的数据。这里要处理好反爬机制、请求频率、数据格式解析等问题。学爬虫的基础是Python的requests和Scrapy抓动态页面还需要用Selenium模拟浏览器操作。数据存储层负责把清洗后的数据写入数据库。设计表时要想清楚商品表、用户表、评分表、评论表、价格历史表这五张核心表之间的关联关系怎么建立。画像和推荐结果存哪里也要在动手前就规划好。业务逻辑层负责实现推荐算法和比价逻辑。推荐算法计算的是“用户可能喜欢什么”比价逻辑计算的是“同一个商品在哪买更便宜”。这两个模块是整个系统的技术核心也是论文里写“关键技术”部分的重要素材。展示层负责把结果呈现给用户。一个是可视化看板展示商品价格分布、销量排行、品牌占比等统计图表另一个是前端推荐页面给用户展示推荐列表和比价结果。我带的很多学生容易犯一个错误上来就埋头写代码代码写完才发现论文没东西可写因为很多技术决策都是拍脑袋做的没有留下设计过程。我的建议是把一周时间专门留给设计文档和数据库设计这个投入非常值得。你后面写代码、写论文、做PPT靠的全是这个阶段沉淀下来的思路。2. 数据从哪来爬虫与数据清洗的实战细节有了架构图之后第一件真正动手做的事情就是搞数据。这个系统的数据来源无非两种途径公开数据集和爬虫抓取。如果时间紧直接去Kaggle或者天池下载现成的电商数据集也是可以的比如一些公开的淘宝商品数据、亚马逊评论数据。但我负责地说自己写爬虫抓到的数据对你的毕设帮助更大。为什么因为你的论文需要写“数据采集与预处理”这一章如果你用的是现成数据集这一章只能草草带过而如果你写了爬虫这一章的内容会非常充实——反爬策略分析、User-Agent伪装、请求头设置、数据解析、异常处理、增量爬取全是能写进论文的素材。2.1 爬虫的目标网站与合规注意先说合规问题这很重要。爬取公开电商平台的商品信息用于学习研究只要爬取频率合理、不涉及用户隐私数据、不做商业用途一般不会有什么问题。但要注意几个底线别爬对方服务器的接口别高并发请求把人家网站打瘫这一点尤其重要很多同学一调试就开几十个线程疯狂请求这是很不好的习惯别抓取用户个人信息。我只能说用于毕业设计的数据采集把频率控制在每5-10秒一个请求是相对合适和稳妥的。目标网站怎么选我的建议是不要爬淘宝、京东这种大型平台一方面是反爬机制复杂搜索接口都是加密参数解析成本很高另一方面高频请求容易触发风控一旦把你IP封了就很麻烦。更合适的做法是爬一些结构相对简单的平台比如一些垂直电商、比价平台或者有公开API的电商数据源。如果实在没有合适的也可以爬某些知名跨境电商的商品详情页相对容易处理。2.2 数据清洗与存储不要以为爬下来就能用很多同学第一次爬完数据兴冲冲地打开数据库一看差点崩溃商品名称里全是乱码和表情符号价格字段有的是“299.00”有的是“29900”图片链接有的有协议头有的没有同一件商品不同平台的价格单位也不同。这就是爬虫数据的常态清洗是这个项目里最枯燥但最核心的环节。我的清洗流程一般是这样的第一步去重。判重不能只看商品ID因为同一个商品在不同平台的ID完全不同。我习惯用“品牌型号关键规格”这组特征做MD5哈希相同哈希的商品就认为是同一个商品。这个思路在后面比价系统里也能用上。第二步统一格式。价格字段统一存成DECIMAL(10,2)去掉人民币符号和千分位分隔符标题字段统一去掉换行符、制表符和多余空格图片链接统一补全协议头。第三步缺失值处理。如果某个字段的缺失率超过30%果断删掉这个字段别在论文里为了凑字数而硬留一个没用的字段。如果缺失率低于5%填充默认值就行。第四步中文分词预处理。这步是为后面的推荐算法服务的。商品标题比如“Apple iPhone 15 Pro Max 原装正品 全网通5G手机”需要分词后把“原装正品”“全网通”这类非关键信息过滤掉提取出品牌、型号、存储容量、颜色等关键属性。用jieba分词就可以搞定。清洗完的数据存储我的建议是建一个商品主表和一个价格历史表。商品主表存储商品的基本属性和当前价格价格历史表存储每次抓取的价格快照。为什么要单独建价格历史表因为比价系统不仅要告诉你“哪个平台现在便宜”还要能画出“过去30天这个商品的价格走势”。如果你只存一个当前价格走势图就没法画了。2.3 数据库表结构设计这里给出我在实际项目中验证过的表结构设计你可以直接修改后使用表名主要字段说明userid, username, password_hash, email, created_at用户信息productid, product_hash, title, brand, category, image_url, current_price, source_platform, created_at, updated_at商品主信息price_historyid, product_id, price, platform, record_date商品价格历史记录user_behaviorid, user_id, product_id, behavior_type, rating, created_at用户对商品的浏览/收藏/评分行为recommendationid, user_id, product_id, score, algorithm_type, created_at推荐结果记录cartid, user_id, product_id, quantity, added_at购物车数据第5张表recommendation我在很多毕设里都没看到但这张表其实非常重要。推荐系统算完分数后把结果先存进这张表前端页面上直接查表就行不需要每次请求都重新跑一遍算法性能好很多。而且答辩的时候你可以打开数据库向评委展示不同算法的推荐结果差异这个细节非常加分。3. 商品可视化让评委一眼看懂你的数据数据清洗好、存储完成后下一个要做的就是可视化看板。视觉给评委留下的印象远比代码逻辑来得深刻。一套设计好看的数据看板能在答辩前30秒内就帮你建立领先优势。3.1 可视化图表怎么选可视化不是越多越好而是要让每张图都对应一个具体的业务问题。我在这个项目里一般就做这几张图价格区间分布图直方图展示所有商品的价格分布情况让用户了解商品整体的价格水平。TOP10热门商品销量排行柱状图展示销量最高的商品体现数据采集结果的核心价值。各平台平均价格对比箱线图或柱状图从比价数据里提炼告诉用户哪个平台的商品平均价格更有优势。商品品牌分布饼图或南丁格尔玫瑰图展示爬取数据的品牌构成体现数据的丰富度。价格走势图折线图配合价格历史表展示某件商品最近30天的价格波动这个图在比价系统里特别有说服力。用户行为图表如折线图展示每天活跃用户数体现系统除了商品数据之外还能分析用户行为数据。3.2 ECharts接入Django模板的完整流程可视化看板的代码实现并不复杂但有几个小细节值得注意。很多人第一次的时候会把ECharts的JavaScript代码全部塞进HTML模板里结果页面一大代码全堆在一起绕得头晕。我习惯的做法是模板只保留一个div容器和Script标签图表配置单独放一个js文件用Django的static模板标签引入。大致流程是这样后端视图函数里查数据库把需要可视化的数据聚合成JSON格式传给模板模板里在JavaScript中读取这个JSON数据传入ECharts的option配置中渲染图表。所以关键就是前后端数据的格式化要约定好。下面是一个典型的ECharts配置注意它在读取后端JSON数据时如何处理// 图表1价格区间分布 var priceDistChart echarts.init(document.getElementById(priceDist)); var priceData JSON.parse({{ price_distribution | escapejs }}); var option { title: { text: 商品价格区间分布, left: center }, tooltip: { trigger: axis }, xAxis: { type: category, data: priceData.bins }, yAxis: { type: value, name: 商品数量 }, series: [{ type: bar, data: priceData.counts, itemStyle: { color: #5470c6 } }] }; priceDistChart.setOption(option);有两个坑需要特别提醒第一Django模板渲染时会对特殊字符进行转义所以后端传过来的图表数据必须用escapejs过滤器否则JSON字符串里的引号会被#34;转义掉JavaScript解析直接报错。第二模板加载完成后才能初始化图表所以script标签要放在页面底部或者用jQuery的$(document).ready()包裹。3.3 可视化页面的布局技巧很多同学用Bootstrap栅格系统把图表一个个摞在页面上看起来像菜市场不够清爽。我推荐的经验是先去参考一下常见的响应式Dashboard布局整体审美是统一的顶部是一个总览栏放两个关键指标卡片比如商品总数、监测平台数、平均价格、价格波动率用四个彩色卡片横向排开中间一行放价格趋势和销量排行两个图表下面一行放平台价格对比和品牌分布两个图表。设计卡片时我习惯用一个CSS卡片包裹每个图表设置固定高度、圆角、阴影。图表在卡片里要在页面加载完成后根据容器宽度自适应尺寸这样不同分辨率的电脑演示都能正常显示。另外配色很关键我见过不少毕设的图表用的是默认配色的红黄蓝绿显得很廉价。ECharts自带的dark主题或者内置的一些调色盘都比我手动去搭配更保险。我的经验是表格基调用深色系图表用低饱和度的配色视觉上会专业很多。4. 推荐系统从协同过滤到冷启动推荐系统是技术含量最高的一个模块但核心算法其实并不复杂。本科生能写明白协同过滤并且能在论文里把公式推导清楚、把代码运行结果展示出来已经足够在答辩中取得好成绩。4.1 协同过滤算法的原理讲清楚协同过滤的核心思想是“物以类聚人以群分”。它不需要任何商品的内容属性只需要依赖用户的历史行为数据——比如用户的浏览记录、收藏记录、评分记录——就能完成推荐。基于物品的协同过滤ItemCF步骤大概是构建“用户-商品”评分矩阵没有评分的用0或null表示计算商品之间的相似度常见方法有余弦相似度、皮尔逊相关系数、杰卡德相似系数根据用户的历史交互商品找到与这些商品最相似的商品过滤掉用户已经买过、看过的东西按相似度得分排序取Top-N作为推荐列表。它的逻辑非常好向评委解释你买过《三体》系统发现买《三体》的人大概率也买《流浪地球》所以系统就把《流浪地球》推荐给你。这个自然语言的表述非常容易理解。4.2 关键代码实现基于物品的协同过滤下面是我在项目里实际用过的ItemCF核心代码你可以直接拿去改造。这里用的是余弦相似度因为它的计算简洁并且对稀疏矩阵有较好的表现能力import numpy as np import pandas as pd from sklearn.metrics.pairwise import cosine_similarity class ItemCF: def __init__(self, behavior_data): behavior_data: DataFrame, 包含user_id, product_id, rating三列 self.behavior_data behavior_data self.user_item_matrix None self.item_sim_matrix None def build_matrix(self): 构建用户-商品评分矩阵作者实际项目中注意处理重复行 self.user_item_matrix self.behavior_data.pivot_table( indexuser_id, columnsproduct_id, valuesrating, fill_value0 ) return self.user_item_matrix def compute_similarity(self): 计算商品间余弦相似度矩阵 # 转置矩阵行变商品列变用户 item_user_matrix self.user_item_matrix.T.values self.item_sim_matrix cosine_similarity(item_user_matrix) return pd.DataFrame( self.item_sim_matrix, indexself.user_item_matrix.columns, columnsself.user_item_matrix.columns ) def recommend(self, user_id, top_n10): 给指定用户推荐top_n个商品 if user_id not in self.user_item_matrix.index: return [] # 用户已交互过的商品 interacted self.user_item_matrix.loc[user_id] interacted_items interacted[interacted 0].index.tolist() scores {} # 遍历用户交互过的商品累加相似商品的得分 for item in interacted_items: item_ratings self.item_sim_matrix[item] for sim_item, sim_score in item_ratings.items(): if sim_item ! item and sim_item not in interacted_items: # 累加得分相似度 * 用户对原商品的评分 scores[sim_item] scores.get(sim_item, 0) sim_score * interacted[item] sorted_scores sorted(scores.items(), keylambda x: x[1], reverseTrue) return [item for item, score in sorted_scores[:top_n]]这段代码里有几个细节值得展开讲第一构建评分矩阵时Django的ORM查询结果需要先转成DataFrame再按user_id和product_id做透视表容易踩的坑是同一个用户对同一个商品有多条行为记录透视表会报错所以建议先drop_duplicates([user_id, product_id])。第二计算相似度矩阵时的内存问题。如果商品数量超过1万商品x商品的相似度矩阵会非常占内存运行起来你的笔记本风扇能响到起飞。所以在计算之前最好先对商品做一次筛选比如只保留行为数大于5的热门商品参与相似度计算这样既降维度又不影响推荐的覆盖效果。第三推荐结果生成后如果你用的不是预计算加缓存的方式性能会很差。尤其是在Web端每次请求都重新跑一遍算法的话用户可能要等好几秒。这就是前面说的recommendation表存在的意义——把推荐结果提前算好存起来前端直接查表速度能提升十倍以上。4.3 冷启动问题怎么解决这是答辩时老师必问的问题“如果系统里有一个新用户或者有一个新商品没有任何行为数据协同过滤算法怎么给他推荐”如果答不上来这个模块的分数就会大打折扣。我的建议是用混合推荐策略主推协同过滤当协同过滤因为用户行为数据不足而无法产生推荐时回退到基于流行度的推荐或基于内容的推荐。基于流行度的推荐实现起来很简单统计全站被收藏、加购次数最多的商品按热度排Top-N直接推荐。基于内容的推荐则需要做商品标签化的处理——对商品标题做分词提取关键词存入商品的tag字段然后计算商品与商品之间的关键词重合度作为相似度。当新商品上架时系统根据关键词匹配找到内容相似的历史商品推荐给偏好这些商品标签的用户。把这两种策略做成一个推荐调度器类逻辑上是def recommend_for_user(user_id, top_n): if user_has_enough_behavior(user_id): rec item_cf.recommend(user_id, top_n) if not rec: rec content_based_recommend(user_id, top_n) else: rec popularity_recommend(top_n) return rec你把这个完整逻辑写进论文的“推荐优化策略”章节然后答辩时主动提一嘴“我们用了多渠道召回多策略兜底来解决冷启动问题”评委基本就不会再追问了。当然下面的倡导是不提倡对代码进行夸大但合理包装自己的设计方案是正常能力。5. 比价系统商品数据对齐才是难点比价系统的功能听起来简单——把同一个商品在不同平台的价格列出来让用户看到哪里便宜。但真正动手做的时候你会发现最难的环节不是展示价格而是如何判定两个不同来源的商品是同一个商品。5.1 比价的逻辑拆解比如你在平台A看到标题叫“Apple iPhone 15 Pro Max 256G 原装正品”平台B的标题叫“苹果手机 iPhone15 Pro Max 256GB 全新未拆封”人类一眼就知道是同一个商品但机器不会。这时候就要用文本相似度算法来匹配了。我用的方案是三步走第一步标题标准化。这里首先要做的不是算相似度而是把所有平台的标题统一格式。我写了一个预处理函数把全角字符转半角统一品牌名的大小写和简称数字和单位统一成英文标题转为小写去掉冗余描述词。这样处理之后两个平台标题的相似基础会好很多。第二步特征抽取。从标准化后的标题里用正则表达式抽出关键特征比如品牌、型号、容量、颜色、尺寸。把这些特征拼接成一个简洁的指纹串例如appleiphone15pro256black。第三步相似度匹配。用编辑距离、杰卡德相似度或者向量化后的余弦相似度计算两个指纹串的相似度。相似度大于某个阈值比如0.85就判定为同一个商品。考虑到商品数据可能是不干净的我建议阈值的设定别太严也别太松我一般在实际项目中是根据测试集调出来的0.85左右表现相对均衡。其实还有一个更简单的业务绕过方案很多资深爬虫团队在爬数据时会把电商平台的商品编号SPU/SKU一起抓下来因为同款商品在不同平台上的标题往往相同或高度相似用标准化后的标题精确匹配就已经能解决很大一部分匹配问题。文本相似度算法用来处理标题有品牌差异的“漏网之鱼”。这个方案简单有效优先去做。5.2 价格比较与变化趋势比价结果不只是展示价格差异还可以加一些加分项。比如“当前最低价”加“近30天最低/最高价”对比让用户看到当前价格是处于历史低位还是高位。降价提醒也是一个很好的功能——用户关注某件商品后系统每天检查价格变化如果价格降幅超过5%就发通知。这样一个简单的功能就能让你在答辩时讲“系统的商业价值”。价格历史表的查询逻辑from django.db.models import Min, Max, Avg def get_price_trend(product_id, days30): end_date timezone.now().date() start_date end_date - timedelta(daysdays) history PriceHistory.objects.filter( product_idproduct_id, record_date__range[start_date, end_date] ).values(record_date).annotate( min_priceMin(price), max_priceMax(price), avg_priceAvg(price) ).order_by(record_date) return list(history)这里有一个细节一天之内不同平台的价格不同所以日报折线图要画三条线min/max/avg还是只画一条我的经验是只画一条平均价格线条把最高最低价用区间阴影表示这样图表既简洁又有信息量。ECharts里用stack加lineStyle.normal.areaStyle就能实现类似的区间展示效果。比价结果页面需要突出用户关心的信息。我会做一个明显的“全网最低价”标签筛选出价格最低的平台并在该平台名称旁边标红价格。首页上设置一个比价入口让用户搜索商品关键词搜索结果的每一行显示商品基础信息和三个平台的实时价格点击“查看详情”进入该单品的比价历史页面。6. 论文、PPT与讲解视频毕设最后一公里代码写完并不代表毕设完了论文、PPT、演示视频这三样东西在评分里的权重其实很高。很多代码写得好的同学论文一塌糊涂最终得分反而不如那些代码一般但包装到位的同学。既然这个题目自带“代码LW文档PPT讲解视频”的完整交付包我把每一件的做法都说一下。6.1 毕业论文的结构与写法毕设论文的结构其实有惯例不需要你创新遵循学校的模板就好。不过每个章节的写作要点还是有讲究的第一章绪论重点说清楚国内电商平台“信息不透明”的痛点引出卖比价系统解决“哪里买更便宜”的问题、推荐系统解决“选择困难症”问题、可视化解决“数据看不懂”问题。注意绪论里要引用几篇高质量文献作为研究背景支撑不要泛泛而谈。第二章相关技术介绍用表格列一下你用到的核心技术然后每个技术写一段“是什么为什么选他”的解释。这里要避免把技术介绍从菜鸟教程里直接整段复制最好用自己的话压缩改写不然查重那关很难过。第三章系统分析与设计需求分析要做两张图或者表——功能需求表、非功能需求表。功能需求表列出每个模块的具体功能点非功能需求写性能指标比如推荐响应时间小于2秒、安全性、可用性。数据库设计部分把ER图放上去设计评审时这个图必看。第四章系统实现这是代码展示的主战场把核心代码贴进去注意每段代码前后都要有文字说明写清楚这段代码“解决什么问题”“怎么实现的”“运行效果如何”。很多人论文里光堆代码没有文字说明读起来非常累。还要把页面截图放进去标注关键区域这能让论文生色很多。第五章系统测试除了写功能测试用例表格我强烈建议加一个“推荐效果评估”小节。用离线评测的方法把用户行为数据按82划分训练集和测试集用准确率、召回率、覆盖率指标量化推荐算法的效果。哪怕只是按Top-5命中率计算这个数也能让论文显得更有说服力。查重这块多说一句代码部分的相似度检测其实可以通过算法实现层面的“换名称加注释换结构”来降低度比如变量名改成有领域含义的词、子函数拆小、多写注释都能有效改善。但论文的文字部分一定老老实实自己写抄就是死路一条。6.2 PPT和答辩讲解的思路PPT不需要做太多花哨的动画页数控制在15-20页足够了。答辩PPT的思路有一条主线选题初衷 - 系统架构 - 功能展示带截图 - 核心算法讲解 - 系统测试效果 - 总结与展望。要注意的是核心算法这一页不要只贴公式要配一个具体的例子。比如在讲解ItemCF算法时我建议准备一个“用户A看过商品X系统推荐商品Y相似度计算过程如下”的案例用表格列出相似度计算过程。这一页讲完评委基本能判断你对算法是真懂还是假懂。答辩时被问到不会的问题不要慌这是一场应对的较量。常见的刁钻问题有“如果用户行为数据稀疏怎么办”“你的推荐系统有没有考虑实时性”“你这个算法跟基于矩阵分解的有什么区别”提前准备几个你熟悉的话术数据稀疏用冷启动兜底策略实时性可以用增量更新批量计算回应矩阵分解在张量维度呈现不一样的特性……根据个人实际情况准备就行。6.3 讲解视频怎么录才不翻车讲解视频的本质是演示系统运行逻辑内容比画质重要。我的录制习惯是先跑通全部功能列一个录屏脚本说明每一段要做什么操作、讲什么话再开始录不建议边录边想否则容易陷入“恩啊阿”的口头禅循环。录屏工具选免费的OBS就挺好画质选1080P帧率30即可。视频里按顺序依次展示系统登录 - Django管理后台快速带过 - 用户首页商品列表 - 可视化看板这里可以稍微讲解每张图的含义 - 商品搜索功能 - 评分/收藏操作 - 推荐结果页重点讲解推荐依据 - 比价功能搜索羽绒服等商品展示价格对比和走势图。视频总长约8-12分钟即可不必过长。开麦克风调试阶段先试录一段10秒试听一下音量回放发现问题及时调整不要等到录完了才发现麦克风有电流声。讲解视频里有一个技巧很多人不知道不要把自己在副屏上的操作过程录进去只录浏览器窗口内容减少干扰。而且正式开录前理清脚本逻辑录的时候多一点“刻意停顿”比如打开图表之后停两秒再说话会方便后期剪辑。7. 常见问题与避坑指南这个项目从搭建环境到最终交付我整理了十个高频坑基本覆盖了大部分人在毕设路上踩过的雷。7.1 环境问题速查表问题现象常见原因解决方案pip安装库时龟速、超时默认官方源在国外配置国内镜像源pip install 包名 -i https://pypi.tuna.tsinghua.edu.cn/simpleVSCode中Python不能运行或找不到解释器Python环境未正确配置在VSCode中打开命令面板CtrlShiftP选择“Python: Select Interpreter”指向你的Python安装路径安装Django后却提示“No module named Django”多个Python版本并存pip安装到了其他版本用python -m pip install Django代替pip install Django确保安装到当前python的解释器MySQL连接报错Authentication Plugin新版MySQL默认加密方式与旧版驱动不兼容Django中修改数据库配置密码认证插件切换成mysql_native_password或者改用PyMySQL连接库爬取中文乱码没有正确设置编码requests返回结果用response.encoding utf-8后重试或者在解析时指定charsetECharts图表不显示容器没有高度或者JS初始化时机不对给图表的div容器设置固定高度比如500px确认脚本在DOM加载后执行Django模板变量注入JS解析出错转义问题模板中的JSON数据加Excel或CSV中文乱码编码不一致用utf-8-sig编码写出CSVExcel打开就能正常显示中文相似度矩阵计算内存溢出商品数量太大只对“活跃商品”行为数大于阈值计算相似度矩阵答辩现场网络不通导致图表白屏依赖CDN资源未离线把ECharts的JS文件下载到本地static文件夹所有外部依赖在答辩前检查一遍7.2 几个值得养成的好习惯第一个习惯是顺手写注释。毕设代码动辄几千行一周后你自己回头看都不知道当时写的是啥更别提老师还要看代码。关键函数前用docstring写明输入输出业务逻辑复杂的地方加行注释说明思路。第二个习惯是做好数据备份。数据库里的爬虫数据是你整个项目的灵魂建议每天把.sql文件导出一次备份到网盘。别问我为什么这么强调我有学生答辩前一天数据库文件损坏差点当场崩溃。第三个习惯是控制好时间节奏。我给大多数学生规划过时间表可以参考第1-2周做需求分析和数据建模第3-4周完成爬虫与数据清洗第5周完成可视化和基础页面第6-8周主攻推荐系统模块第9周完成比价系统第10-11周边写边系统测试第12-13周集中写论文第14周做PPT和录制讲解视频最后留1周打磨和预答辩。我个人在实际操作中最大的体会是这个题目最耗时间的不是写代码而是处理数据和调推荐效果。很多同学卡在“数据量太小导致推荐效果不明显”这个问题上这时候不要慌有两个解决方案一是扩大爬虫范围多爬几个平台的数据二是在测试阶段人为构造一批模拟用户行为数据用来演示推荐效果。我的建议是两者并行真实数据保证可信度模拟数据保证演示效果。另外分享一个小技巧在做讲解视频的时候用固定书签打开你系统的每个核心页面提前把页面缓存加载好录制的时候页面跳转就是秒开整个视频节奏会顺畅非常多。这个项目的路走到这里已经通了接下来就是按着这个思路一步步落地。代码、文档、PPT、视频这个毕设组合包不愁没内容就怕你不开始动手。