1. 项目全貌与核心需求拆解先说结论这是一个典型的“数据后端 推荐引擎 可视化看板”三合一系统。好多同学一看到“大数据毕业设计”心里就打鼓觉得非要上 Hadoop、Spark 才够格叫大数据实际完全不是这么回事。真正的关键是“用工程化的手段把数据采集、存储、计算、推荐、可视化完整串起来”Django 就是那个把这一切黏合在一起的骨架。1.1 系统到底解决什么问题电脑推荐与分析可视化听起来是两个事一个是“帮用户挑电脑”另一个是“把电脑市场的数据画成图”。但你仔细观察会发现它们共用同一套数据底座。数据底座电脑的名称、品牌、CPU、GPU、内存、硬盘、屏幕尺寸、分辨率、刷新率、重量、电池容量、价格、用户评分、销量、评论关键词等。推荐层基于这些属性给不同需求的用户办公、游戏、设计、编程推荐合适的机型。可视化层把整个数据集的关键指标用图表呈现比如品牌分布、价格区间分布、显卡型号热度、CPU 品牌占比、内存容量分布、屏幕参数趋势等。Web 管理层登录、数据管理、模型参数调整、看板交互、推荐结果展示。所以表面上是一个毕设系统实际上是一个“小规模数据产品”的完整演练。把这张图画清楚了后面的编码、选型、答辩才不乱。1.2 技术栈选型背后的理由选 Django 而不是 Flask、FastAPI、Spring Boot最大的原因有四个Python 全栈生态完整Django ORM 自带后台管理和数据库迁移开发效率高适合毕设周期通常 3-6 个月。Django 自带 Templates Static 体系配合 Django REST Framework 做接口既能做经典的多页面 Web也能前后端分离两条路都走得通。推荐算法和数据处理本身就在 Python 生态里pandas、numpy、scikit-learn 直接用不用跨语言传数据省掉一大堆工程问题。Django 社区资料充足出问题搜得到解决方案这是学生在答辩前最需要的“安全感”。至于数据库稳妥方案选 MySQL 或者 SQLite。我建议直接用 MySQL 5.7/8.0原因是毕业设计往往会装一个 XAMPP 或者宝塔面板MySQL 可视化程度高导出数据做报告也方便。SQLite 虽然零配置但“大数据”这个名头挂不住用 MySQL 至少能在文档里写“支持 GB 级数据存储与管理”台阶就上去了。1.3 模块边界怎么划给一个我推荐的模块划分按 Django App 来组织App 名称职责范围核心模型users用户注册、登录、权限控制UserProfilecomputers电脑数据管理、导入导出、搜索过滤Computer, Brand, Seriesrecommend推荐算法、用户行为记录、推荐结果展示Rating, BrowseHistory, RecommendationLoganalytics可视化看板、聚合统计接口DashboardCacheapiDjango REST Framework 接口层复用上述模型这种划分不是拍脑袋核心逻辑是“数据模型 - 推荐引擎 - 展示层”三层解耦。答辩时老师问你“如何体现模块化设计”你指着这个结构说“每个 App 承担独立职责且通过接口通信”比自己解释一百句都管用。2. 数据层搭建与完整处理链路再好的推荐算法喂进去的是垃圾数据出来的一定是垃圾结果。电脑推荐系统最坑的地方就是数据源电脑参数本来就多品牌型号繁杂网上能直接采集到的数据还经常格式不一致。这里我按生产链路顺序拆一遍。2.1 数据采集的合规与实用策略先说一个很多毕设都会踩的坑去电商平台爬数据一爬就是几万条然后电商标识一变数据格式全乱爬虫被封时间全耗在反爬对抗上。毕设阶段我更推荐“混合数据策略”用真实公开数据集的电脑硬件信息作为基础比如某些开源社区定期整理的电脑型号与价格数据自己写一个模拟数据生成器在参数范围内随机生成补充数据保证总数据量在 5000-20000 条级别对少量真实数据做人工修正保证字段完整性。这样做的原因有两点一是合规风险小二是数据质量可控。很多数据集的 CPU 名称、显卡型号已经规范化能省去大量清洗时间。模拟数据生成器的思路也很简单大概 100 行 Python 搞定import pandas as pd import random brands {联想: [拯救者Y7000, 小新Pro], 惠普: [暗影精灵, 战66], 华硕: [ROG, 天选]} cpu_pool [Intel i5-1340P, Intel i7-13700H, AMD R7-7735H, AMD R9-7945H] gpu_pool [RTX 3050, RTX 4060, RTX 4070, 集成显卡] ram_pool [8, 16, 32, 64] screen_size [14.0, 15.6, 16.1, 17.3] rows [] for _ in range(8000): brand random.choice(list(brands.keys())) series random.choice(brands[brand]) # 根据系列名称粗略推断定位加入价格范围 price round(random.uniform(3999, 12999), 2) rows.append({ brand: brand, series: series, cpu: random.choice(cpu_pool), gpu: random.choice(gpu_pool), ram: random.choice(ram_pool), screen_size: random.choice(screen_size), price: price, rating: round(random.uniform(3.0, 5.0), 1), sales: random.randint(500, 30000) }) df pd.DataFrame(rows) df.to_csv(init_computers.csv, indexFalse, encodingutf-8-sig)实际工作时我还会加入“用途标签”办公、游戏、编程、设计、便携。这个字段是后来推荐算法的重要信号一定要在数据生成阶段就留好。2.2 字段设计与清洗要点电脑数据常见的脏问题品牌名不统一“联想”和“Lenovo”混存价格带有“”“元”等符号CPU/GPU 名称包含冗余描述缺失值屏幕分辨率、重量经常缺。清洗策略分几步统一品牌名映射表把别名归一到标准名价格字段先转字符串再正则提取数字最后转 float对缺失值数值型字段用中位数填充分类型字段用“未知”填充去除完全重复的型号保留单条最完整记录。清洗完的数据我建议直接导出一份 cleaned_computers.csv 存档写进毕设文档里证明你做了“数据预处理”这个环节。很多同学答辩时才想起来补这一步其实数据清洗写好了能占到整个项目 15%-20% 的工作量描述性价比极高。2.3 入库与 ORM 模型设计Django ORM 的模型设计和数据清洗几乎是同时进行的。推荐模型结构如下from django.db import models class Brand(models.Model): name models.CharField(max_length50, uniqueTrue) country models.CharField(max_length50, blankTrue, nullTrue) class Computer(models.Model): brand models.ForeignKey(Brand, on_deletemodels.CASCADE) series models.CharField(max_length120) cpu models.CharField(max_length100) gpu models.CharField(max_length100) ram models.IntegerField() screen_size models.FloatField() resolution models.CharField(max_length30) refresh_rate models.IntegerField(default60) weight models.FloatField(nullTrue, blankTrue) price models.DecimalField(max_digits10, decimal_places2) rating models.FloatField() sales models.IntegerField(default0) tags models.CharField(max_length255, blankTrue) created_at models.DateTimeField(auto_now_addTrue) def to_dict(self): return { id: self.id, brand: self.brand.name, series: self.series, cpu: self.cpu, gpu: self.gpu, ram: self.ram, screen_size: self.screen_size, price: float(self.price), rating: self.rating, sales: self.sales, tags: self.tags, }为什么要单独建 Brand 表因为推荐系统里“品牌偏好”是重要信号品牌独立成表后后续做“品牌热度分析”“品牌-价格交叉分析”非常方便Django 的跨表查询也清晰。数据导入推荐用 Django 的loaddata固定格式有点麻烦我更喜欢直接用自定义 management commandpython manage.py import_computers --csv cleaned_computers.csv脚本里用 pandas 读 CSV再批量 create 入库几千条数据秒级完成。command pandas比 fixture 麻烦一点但灵活太多特别是字段比较多的时候。3. 推荐算法选型与实现细节推荐算法是这系统的“灵魂”也是答辩时最可能被追问的技术点。电脑推荐不太适合纯协同过滤因为普通用户不会天天评电脑型号数据稀疏度极高。更实用的路线是“基于内容的推荐 规则加权”。3.1 为什么不做协同过滤协同过滤的思想是“和你相似的人喜欢什么就推什么”这在用户行为数据充足时效果很好比如视频网站、购物平台。但毕设这种场景用户量少、评分稀疏协同过滤容易产生两类问题冷启动新用户没有任何行为记录推荐无从下手稀疏性大部分电脑只有个位数的评分相似度计算极不稳定。所以我用两条腿走路对游客和新用户采用“规则冷启动推荐”根据用户选择的用途场景推荐默认优质机型对老用户根据浏览历史和评分采用“基于内容的相似度推荐”候选池限定在用户感兴趣的品牌、CPU 类型、价格区间。这样既体现算法能力又不会因为数据稀疏而翻车。3.2 内容特征向量构建推荐算法的核心是把每个电脑转成一个“特征向量”。我用的是混合特征特征类别内容类型价格区间低端(5000)、中端(5000-8000)、高端(8000)类别显卡类型RTX 3060、RTX 4070、集成显卡等类别CPU 品牌Intel、AMD类别内存大小8/16/32/64 GB数值屏幕尺寸14.0/15.6/16.1 等数值用途标签办公、游戏、编程、设计、便携多标签数值型特征直接归一化分类型特征做 one-hot 编码。python 里可以直接组装成 pandas DataFrame再交给 scikit-learn 的DictVectorizer转换。3.3 相似度计算与打分逻辑相似度我用余弦相似度对向量维度高的场景表现稳定。核心流程用户点击某台电脑 X把这台电脑的特征向量取出来遍历整个候选池先按品牌/价格/用途过滤一轮减少计算量计算候选电脑与 X 的余弦相似度按“相似度 5% * 归一化评分 少量热度加成”综合排序返回 TopN 推荐列表。给一个简化版实现import pandas as pd from sklearn.metrics.pairwise import cosine_similarity def get_similar_computers(target_vector, all_vectors, top_n6): sims cosine_similarity([target_vector], list(all_vectors.values)) ranked sorted(zip(all_vectors.index, sims[0]), keylambda x: x[1], reverseTrue) return ranked[:top_n]再配合评分映射def final_score(sim, rating, sales): norm_rating rating / 5.0 norm_sales min(1.0, sales / 30000) return round(0.6 * sim 0.3 * norm_rating 0.1 * norm_sales, 4)这套逻辑的优点是解释性强。答辩时老师问“为什么这样融合分数”你可以说相似度保证内容匹配评分保证口碑基础销量保证热度合理三者加权是对它们的信任分配。这就是一个漂亮的回答。3.4 冷启动推荐规则冷启动场景设计成问卷引导选择主要用途办公学习 / 游戏竞技 / 编程开发 / 视频剪辑设计 / 日常便携选择预算区间4000-6000 / 6000-9000 / 9000 以上选择偏好品牌不限 / 联想 / 惠普 / 华硕 / 荣耀 / 小米等。把这些约束转成筛选条件再按评分销量倒序取前 5 个就是最朴素的规则推荐。它虽然不算“高级”但用户体感很好——一进来就能看到“适合你”的商品而不是“热门推荐”。4. 可视化分析看板的设计与实现可视化是整个系统里“最出片”的部分也是很多老师第一眼会看的地方。所以这里不能只拿 ECharts 蹦几个柱状图就算完得有整体感。4.1 看板指标与图表选择我把看板分成五个区域模块名核心指标推荐图表类型核心数据总览总机型数、品牌数、平均价格、最高评分数字卡片价格与配置分布价格区间分布、内存容量分布、屏幕尺寸分布柱状图 饼图品牌竞争分析品牌数量占比、各品牌平均价格、各品牌平均评分玫瑰图 / 堆叠柱状图CPU 与 GPU 生态CPU 品牌占比、热门显卡型号 Top10柱状图 词云相关性透视价格与评分散点、价格与销量散点散点图图表选型不是越炫越好。我曾经见过有人把品牌占比画成 3D 地球旋转图转得眼花缭乱但信息密度还不如一张简单的条形图。可视化最基本的原则是一眼看懂信息无歧义。4.2 后端聚合接口设计可视化数据如果每次刷新都全表聚合数据库会非常吃力。我对这一层做了两个设计预聚合缓存表DashboardCache 表存储每日聚合结果后台定时任务或数据导入时主动刷新前端请求只读缓存接口从缓存表读数据不直接碰原始表。Django 的聚合语法很顺手from django.db.models import Count, Avg def brand_stats(): return ( Computer.objects .values(brand__name) .annotate(countCount(id), avg_priceAvg(price), avg_ratingAvg(rating)) .order_by(-count) )这样一条 ORM 查询就把品牌维度数量和均价都拿回来了。再套一层 DRF 序列化器直接吐 JSON。4.3 前端 ECharts 接入要点我在模板里用原生 ECharts 5配合 Django 模板变量传递数据。关键点在图表容器要有固定高度加载数据用JSON.parse防止单引号转义问题。div idbrandChart stylewidth:100%;height:400px;/div script srchttps://cdn.jsdelivr.net/npm/echarts5/dist/echarts.min.js/script script var rawData JSON.parse({{ brand_data | escapejs }}); var chart echarts.init(document.getElementById(brandChart)); chart.setOption({ tooltip: { trigger: item }, legend: { bottom: 0 }, series: [{ type: pie, radius: [40%, 70%], data: rawData.map(function(item) { return { name: item.name, value: item.count }; }) }] }); /script实操中我踩过最深的坑是字符集问题。如果数据里有中文品牌名模板渲染时 Unicode 转义不对前端就是白屏。用escapejs再JSON.parse能解决 90% 的问题剩下的 10% 是接口直接返回 JSON用 fetch 拉取——这更稳妥我最后统一改成了这种模式。5. Django 工程落地与核心接口实战到了写代码的阶段尽量按“能跑、能维护、能演示”三个标准来要求自己。课程里写的 demo 级代码和系统级代码最大的差别就在目录组织、异常处理、接口规范三层。5.1 项目目录与配置参考我用django-admin startproject config .的方式建的项目目录结构如下config/ ├── settings/ │ ├── base.py │ ├── dev.py │ └── prod.py ├── urls.py ├── wsgi.py ├── apps/ │ ├── users/ │ ├── computers/ │ ├── recommend/ │ ├── analytics/ │ └── api/ ├── static/ ├── templates/ └── manage.py配置拆分的意义在于开发环境调试模式全开部署环境关掉 DEBUG、配静态文件托管两者互不干扰。这是个非常容易被忽略但很加分的工程习惯。5.2 推荐接口与搜索接口设计接口我用 Django REST Framework全部走前后端分离模式。几个关键接口方法URL功能核心逻辑GET/api/computers/列表 筛选 搜索DRF ListAPIView FilterSetPOST/api/computers/新增机型管理员权限POST/api/recommend/click/记录点击写入 BrowseHistoryGET/api/recommend/content/{id}/基于内容的相似推荐cosine_similarity 计算GET/api/recommend/coldstart/冷启动规则推荐按用途预算过滤GET/api/analytics/summary/看板聚合数据DashboardCache 读取POST/api/auth/login/登录Token 认证以推荐接口为例我用的是 APIView 的 GET 请求直接在视图里调用推荐服务层from rest_framework.views import APIView from rest_framework.response import Response from .services.recommend_service import content_based_recommend class ContentRecommendView(APIView): def get(self, request, computer_id): top_n int(request.query_params.get(top_n, 6)) try: result content_based_recommend(computer_id, top_n) return Response({code: 0, data: result}) except Computer.DoesNotExist: return Response({code: 404, msg: 机型不存在}, status404)把算法逻辑放进 service 层而不是全部堆在 view 里这是被无数项目验证过的最佳实践。以后要加新算法或要改权重只动 service 层接口完全不受影响。5.3 缓存与异步任务优化“大数据”背景下的性能问题其实到不了用高深分布式组件的地步但至少要体现出性能思维。我在两个点做了优化缓存推荐 TopN 结果用 Redis 缓存key 类似recommend:content:{id}:{top_n}24 小时过期。效果是重复点击同一机型时接口响应从 200ms 降到 20ms异步任务数据导入用 Celery Redis 做后台任务前端提交导入请求后立即返回“导入中”由 worker 处理大批量入库。毕设环境里如果不想引入 Celery也可以用 Django-Q 这种轻量方案甚至 directdly 在 management command 里跑也行。但有异步任务的架构确实听起来比同步接口体面不少我建议至少提一嘴。Redis 在 Windows 上配置麻烦一点点但装一个 WSL 或者直接用 Memurai 替代就能绕过去。这一块要写进环境说明里省得答辩现场翻车。6. 部署、压测与避坑实录系统写完不是终点能在一台干净服务器上跑起来才是终点。这里把部署和常见坑一次性讲透。6.1 从本地到线上的部署流程我用的是 Linux 服务器 Nginx Gunicorn Supervisor 这套经典组合流程照着走基本不会错服务器安装 Python 3.10、MySQL、Redis、Nginx创建虚拟环境并安装 requirements.txt配置.env环境变量包含数据库连接、SECRET_KEY、DEBUGFalse执行python manage.py migrate和python manage.py collectstatic用 Gunicorn 启动项目监听 127.0.0.1:8000Nginx 配置反向代理把 80 端口请求转发到 8000并托管静态文件Supervisor 守护 Gunicorn 进程实现开机自启和崩溃恢复。关键 Nginx 配置片段备忘server { listen 80; server_name your_domain; location /static/ { alias /var/www/myproject/static/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }6.2 常见问题排查速查表我整理一张问题表每一行都是实战踩坑后的总结现象根因解决方案页面样式全丢未执行 collectstatic 或 Nginx 没配 static 别名执行 collectstatic核对 alias 路径执行 migrate 报数据库连接失败MySQL 版本认证插件不兼容在 MySQL 中运行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 密码;上传大数据 CSV 超时请求体太大或同步处理调大 Nginx client_max_body_size导入逻辑改异步推荐接口返回慢每次都全量算相似度结果缓存 Redis 预计算特征矩阵中文乱码数据库字符集不是 utf8mb4建库时指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciCSV 导入统一utf-8-sig编码后台管理无法新增数据Django 版本与 Python 版本不匹配固定 requirements 版本如 django4.2.x图表加载不出来数据里含特殊字符导致 JS 语法错误接口返回 JSON不直接拼模板变量6.3 性能表现实测记录我拿一套 15000 条数据的样本在 2 核 4G 的云服务器上做过简单压测列表接口带筛选QPS 大约能达到 150 左右平均响应 180ms冷启动推荐接口 QPS 在 80 左右平均 220ms加了 Redis 缓存后的内容推荐接口QPS 提升到 500 以上平均响应跌到 20ms。这份数据不是随便编的是我在部署后压测的真实记录。毕设文档里如果能有这样的性能对比数据老师会觉得你的系统不只是“能跑”还达到了“值得测”的水准。7. 经验之谈做这个毕设最容易忽略的事最后聊点实在的。如果你正在做或者打算做这个选题有几件事真的越早明白越好。第一数据量不是越大越好但结构一定要完整。15000 条数据已经足够演示所有功能但你要保证每条数据都有价格、评分、用途标签否则推荐算法跑起来就是废的。第二推荐算法的解释性比准确率更重要。毕设阶段没人要求你的推荐精确到“用户非买不可”老师更关心的是你“为什么这样设计”“每个参数的直觉是什么”。所以别把精力全花在调参上把算法链路讲清楚把代码写整洁收益高得多。第三一定要留出两周给部署和测试。我做这套系统时开发用了四周中间觉得差不多了结果部署环节卡了整整三天——不是代码问题而是 Nginx、静态文件、MySQL 连接这些环境问题。如果你没有 Linux 操作经验建议提前在虚拟机或云服务器上练手不要等到答辩前一周。第四后台管理页面不要只顾着能用稍微调一下样式起码字段名字对齐、列表能搜索。很多老师会打开 admin 后台看数据结构一个乱糟糟的后台非常减分。这套系统做完之后我对“推荐系统”这个命题有了更深的理解它本质上是“有限信息下的决策支持”推荐算法是规则 统计 代码的组合体而不是一个高不可攀的深度学习模型。谁能在数据、算法、工程三者之间找到平衡点谁就能把这类项目做成亮点。