每年到这个时间点总有一批同学为毕业设计选题挠头。如果你懂一点 Python又不想做烂大街的图书管理系统或商城那我强烈建议你看看这个方向做一个基于 Django 协同过滤的音乐推荐系统再配一套 Echarts 可视化大屏。这个组合既能展示后端开发能力又有算法含量还能把数据可视化做得非常漂亮答辩时亮点十足。这套毕设方案我已经带好几个学弟完整跑通过今天把这套系统的实现思路、核心代码、踩坑经验一次讲透想复用的可以直接照着抄。先把这个项目解决了什么问题说清楚。市面上的音乐 App 都在推歌但绝大多数校园毕设只是简单做一个“歌曲展示 搜索”完全没有个性化推荐。而这个项目的核心在于根据用户的历史播放、收藏、点赞行为用协同过滤算法算出“和你品味相似的人喜欢什么”然后从百万级歌曲库里给你挑出可能喜欢的歌。同时后台管理端配了一套可视化大屏用 Echarts 把用户活跃时间段、热门歌曲榜、歌曲类型分布、地域播放热度直接画成图表让整个系统的数据价值一眼可见。这个选题既适合计算机科学、软件工程专业的毕设也适合对数据分析和可视化方向感兴趣的同学。1. 项目整体设计毕设到底要做什么、怎么分模块1.1 核心功能拆解我拿到这类项目的第一个习惯就是先不看代码把功能模块画清楚。音乐推荐系统的“用户端 管理端 推荐引擎 可视化大屏”四个模块缺一不可这也是答辩时最能体现系统完整性的地方。用户端要覆盖完整的使用链路注册登录、浏览歌曲、搜索歌手或歌名、点击播放、收藏歌曲、点赞评论行为。这里每一项操作都不是白做的播放、收藏、点赞都会成为推荐算法的输入数据。你在界面上看到的“猜你喜欢”“相似歌曲推荐”模块就是推荐引擎的计算结果。管理端则给管理员提供歌曲管理、用户管理、行为数据统计、推荐结果配置等功能。这里有个容易被忽略但很加分的做法用 Django 自带的 Admin 做基础管理再写几个自定义管理页面比如查看每个用户的推荐列表、手动下架不合规歌曲、调整热门歌曲榜的权重系数这在答辩演示时能体现完整的后台运营思维。推荐引擎是算法核心独立成一个服务模块不直接跟视图层耦合。业务上我采用的是 ItemCF基于物品的协同过滤后面细讲。引擎通过读取用户行为数据离线计算歌曲间的相似度矩阵再为每个用户实时生成 TopN 推荐列表。可视化大屏单独做成一个 Dashboard 页面放在管理端入口下。用 Echarts 渲染四张主图加两个数字卡片数据全部通过 Django 的 JSON 接口输出。毕竟毕设答辩时间有限大屏一拉开评委一眼就知道你做了数据可视化比看一堆代码截图强太多了。1.2 架构设计思路为什么这么分层这个项目的典型分层结构是“浏览器 → Django 视图 → Service 层 → 数据层”。我特别想强调 Service 层的存在价值不要在视图函数里直接写相似度计算和推荐逻辑。因为推荐算法模块将来可能换成基于内容推荐、深度学习模型或者改用 Celery 异步执行如果算法粘连在 view 里改一次就要动一大片代码。分层的收益短期看是代码整洁长期看是可维护、可扩展这是答辩时能聊出深度的点。实际项目里我建议数据流向是歌曲表 行为表 - 离线相似度计算可定时任务触发 - 相似度结果存入 Redis/数据库 - 用户访问推荐接口 - 读取用户行为 - 加权计算 - 返回 TopN 歌曲列表这里有一个关键设计相似度矩阵是离线的推荐列表是在线的。离线计算可以接受耗时比如几百毫秒甚至几秒都行它算完存起来在线推荐必须快扣除网络延迟后接口响应要求控制在 300 毫秒以内。这样划分后就算歌曲数据涨到十万、行为数据涨到百万推荐服务的压力依然可控这也是项目叫“分布式计算”的真实含义——计算任务与在线服务解耦重型计算拆分到后台任务里执行。2. 技术选型解析为什么是 Django、协同过滤和 Echarts2.1 后端框架Django 的取舍经常有人问这种毕设用 Flask 不行吗行但 Django 更适合。核心原因是 Django 自带 Admin 后台、ORM、Auth 用户认证、模板引擎这些都能直接复用省掉大量底层代码。具体到音乐推荐系统Django 的 ORM 对多表关联查询非常友好。我的数据表有 User、Song、PlayRecord、Favorite、Comment 五张核心表统计用户播放时长、获取用户收藏列表、按歌曲热度聚合行为数据用 ORM 的annotate和aggregate几行就搞定。如果用 Flask SQLAlchemy虽然也能做但要自己配一堆扩展调试成本高不少。Django 的 Auth 系统还能直接支持用户注册登录和 Session 管理建议直接继承AbstractUser扩展自定义字段比如头像、偏好风格、是否接受推荐邮件等。这里提醒一句Django 默认的 User 表不够用扩展用户表要在settings.py里配置AUTH_USER_MODEL并且必须在第一次迁移之前配好否则后面改表结构极其痛苦。2.2 算法选型ItemCF 为什么比 UserCF 更贴合音乐场景协同过滤分两类UserCF基于用户相似度和 ItemCF基于物品相似度。教科书写得比较绕我用大白话解释UserCF 是“和你喜好相似的人喜欢的歌你也会喜欢”先找同类用户再找歌ItemCF 是“和你之前喜欢的歌相似的其他歌你也会喜欢”先找相似歌曲再给你推。选 ItemCF 的原因非常实际第一音乐用户的兴趣相对分散但歌曲的“邻居关系”稳定。一首《晴天》和《七里香》的相似度是客观事实不随用户变化而剧烈变化但一个用户的兴趣可能一周一变UserCF 要实时计算用户相似度代价更高。第二ItemCF 的相似度矩阵可以离线算好在线只需查表加聚合。这对于 Django 这种同步框架更友好不会出现“在线推荐时还在跑双重循环”的性能灾难。第三ItemCF 给用户推荐的解释性强——系统可以说“因为你喜欢《晴天》所以为你推荐《七里香》”这种解释对用户体验和答辩展示都非常直观。当然ItemCF 也有软肋冷启动问题。新用户没有任何行为数据相似度计算就是空中楼阁。这个我在第五章专门讲怎么兜底。2.3 可视化层Echarts 的制图思路Echarts 是百度开源的可视化库到今天仍然是我做毕设大屏的首选。它的优势在于中文文档完善、社区案例多、配置项灵活一个折线图从零配到能看二十分钟就能搞定。对于一个音乐系统最出效果的图我建议做六张总用户数、总播放量的数字卡片用 Echarts 数字动画或纯 CSS 实现都行热门歌曲 Top10 柱状图推荐横向柱状图歌名再长也不怕截断歌曲类型占比的环形饼图能直观看到“民谣 30%、流行 40%、摇滚 15%”的分布24 小时播放活跃量的渐变面积折线图这一个图最能体现平台运营视角热门歌手词云图用 Echarts 的wordCloud扩展或 2D canvas 自绘用户地域分布的地图如果爬到的数据里没有地域信息可以用模拟数据生成。2.4 “分布式计算”到底怎么体现很多同学看到“分布式”三个字就心虚怕答辩被追问。这里我给你一套合理的落地方案毕设里说的分布式不需要上 Hadoop、Spark那种规模对音乐推荐系统完全没必要。我们用业界真正在用的轻量方案用Celery Redis做异步任务队列把离线相似度计算、定时热度统计、数据爬虫全部丢到异步 Worker 里执行用multiprocessing多进程并行处理数据爬虫的分片任务用 Redis 缓存相似度矩阵和热门榜单减少数据库压力。这三个手段叠加就可以在答辩时说清楚你把重计算任务与在线服务解耦通过消息队列实现任务分发、异步执行、结果缓存这就是分布式计算思想在项目里的工程落地。这样说既诚实又有深度比吹嘘“用了 Hadoop”实在多了。3. 数据模型设计与协同过滤算法的核心实现3.1 数据库表结构设计实战我的表结构是经过三轮重构后稳定下来的你直接参考这个设计基本不会踩坑from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): avatar models.URLField(default, blankTrue) preferred_genre models.CharField(max_length50, blankTrue, default) class Meta: db_table music_user class Song(models.Model): title models.CharField(max_length200) singer models.CharField(max_length100) album models.CharField(max_length200, blankTrue, default) genre models.CharField(max_length50, blankTrue, default) duration models.IntegerField(help_text时长单位秒) play_count models.IntegerField(default0) cover_url models.URLField(default, blankTrue) audio_url models.URLField(default, blankTrue) class Meta: db_table music_song indexes [ models.Index(fields[genre]), models.Index(fields[singer]), ] class PlayRecord(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_nameplay_records) song models.ForeignKey(Song, on_deletemodels.CASCADE, related_nameplay_records) played_at models.DateTimeField(auto_now_addTrue) play_duration models.IntegerField(default0, help_text实际播放时长秒) class Meta: db_table music_play_record indexes [ models.Index(fields[user, played_at]), models.Index(fields[song, played_at]), ] class Favorite(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_namefavorites) song models.ForeignKey(Song, on_deletemodels.CASCADE, related_namefavorites) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table music_favorite unique_together (user, song) class Comment(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE) song models.ForeignKey(Song, on_deletemodels.CASCADE) content models.TextField() created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table music_comment几个关键点说明unique_together保证用户对同一首歌只能收藏一次避免重复数据污染推荐算法PlayRecord的play_duration是推荐权重的重要参考比单纯记录有没有播过更有区分度所有表都建了数据库索引因为后面行为数据涨到几十万条时没有索引的数据库查询能慢到让你怀疑人生。3.2 ItemCF 协同过滤算法手写实现网上能找到很多现成的推荐系统代码但毕设答辩一定会问算法细节。我建议你亲手实现一遍核心逻辑即使最后调优后用了别的库手写版本也能让你在答辩时游刃有余。ItemCF 的经典实现分三步第一步构建“用户-物品”倒排表。原始行为数据长这样用户 1 播放过《晴天》《七里香》用户 2 播放过《晴天》《夜曲》用户 3 播放过《七里香》《夜曲》《简单爱》。要把数据整理成每个用户对应哪些歌。第二步计算物品间共现矩阵。统计两首歌被同一个用户一起行为播放/收藏/点赞的次数。如果一个用户对两首歌都有行为它们之间的共同出现次数加一。C[i][j]表示歌i和歌j的共现次数。第三步用余弦相似度归一化。直接用共现次数有个问题热门歌的共现次数天然高会霸榜。所以要除以两个物品各自行为人数的几何平均数import numpy as np def itemcf_similarity(play_records): # 构建 用户 - 歌曲集合 的倒排表 user_items {} for record in play_records: user_items.setdefault(record[user_id], set()).add(record[song_id]) # 构建物品共现矩阵 C {} N {} for user, items in user_items.items(): for i in items: N[i] N.get(i, 0) 1 C.setdefault(i, {}) for j in items: if i j: continue C[i][j] C[i].get(j, 0) 1 # 余弦相似度归一化 W {} for i, related_items in C.items(): W.setdefault(i, {}) for j, cij in related_items.items(): W[i][j] cij / np.sqrt(N[i] * N[j]) return W这里有几个计算细节要注意。第一如果用户行为里同时有播放、收藏、点赞可以把不同行为赋予不同权重收藏权重 1.0、点赞权重 0.6、播放且听完 0.4、只点开听了几句 0.1。这样计算出来的共现矩阵更贴近真实偏好。第二当数据量到了一定量级纯 Python 的双重循环会非常慢建议把行为矩阵转成scipy.sparse.csr_matrix稀疏矩阵然后用矩阵乘法一步算出共现矩阵速度提升几十倍。第三相似度矩阵算完要存到 Rediskey 结构用item_sim:song_idvalue 用排序后的 JSON 字符串这样推荐时直接取不用重复计算。3.3 在线推荐怎么打分拿到相似度矩阵以后为用户生成推荐列表就是加权求和def recommend(user_id, W, user_items, top_n10): # user_items: 当前用户已经产生过行为的歌曲集合 rank_score {} for item in user_items: # 遍历目标物品的相似物品列表 for similar_item, sim_score in W.get(item, {}).items(): if similar_item in user_items: continue # 过滤掉已经行为过的歌曲 # 用该用户对 item 的行为权重加权 rank_score[similar_item] rank_score.get(similar_item, 0) sim_score # 排序取 TopN return sorted(rank_score.items(), keylambda x: x[1], reverseTrue)[:top_n]可以简单解释一下用户播放过歌曲 A而歌曲 B 和 A 的相似度很高那么 B 就会获得一个加分。用户行为过的歌越多被加权的相似歌就越多最终得分最高的就是最值得推荐的歌。实际项目中我会额外加一个“时间衰减因子”用户三个月前的行为权重设为 0.3一周内的行为权重设为 1.0这样推荐结果能反映用户当前口味变化。在线接口部分我建议做成 Django 的 JsonResponse 接口前端用 Ajax 拉取后渲染。接口内部逻辑是先查 Redis 缓存缓存命中直接返回没命中再从数据库加载用户最近 50 条行为记录调用推荐函数算完回填缓存。缓存时间设置 10 分钟即可既不会太陈旧又不会频繁失效导致压力过大。4. 可视化大屏与核心页面实操从接口到图表的完整链路4.1 Django 后端如何给 Echarts 喂数据Echarts 本身是纯前端图表库它只管“拿到数据画图”不管数据从哪来。所以在 Django 项目里核心工作是把数据库统计结果变成 JSON 接口。以“24 小时播放活跃量折线图”为例我给你完整代码。首先在 views 里写一个统计接口from django.http import JsonResponse from django.db.models import Count from django.db.models.functions import TruncHour from django.utils import timezone from datetime import timedelta def hour_activity_api(request): # 统计最近7天的每个小时播放次数 since timezone.now() - timedelta(days7) rows ( PlayRecord.objects.filter(played_at__gtesince) .annotate(hourTruncHour(played_at)) .values(hour) .annotate(cntCount(id)) .order_by(hour) ) hours [r[hour].strftime(%m-%d %H:00) for r in rows] counts [r[cnt] for r in rows] return JsonResponse({hours: hours, counts: counts})然后配置 URL在 urls.py 里加上path(api/hour-activity/, hour_activity_api)。前端模板里用 Ajax 请求这个接口拿到数据后灌进 Echarts 配置项即可。同理歌曲 Top10 榜单接口长这样def top_songs_api(request): top_songs Song.objects.order_by(-play_count)[:10] data { songs: [s.title for s in top_songs], artists: [s.singer for s in top_songs], play_counts: [s.play_count for s in top_songs], } return JsonResponse(data)这里就体现出 Django ORM 的方便了按热门程度排序的聚合统计几乎是白送的。所有图表接口走/api/前缀统一返回 JSON哪怕以后前端换成 Vue 或 React 也完全不用改后端。4.2 Echarts 大屏页面配置要点大屏页面我建议不要用框架一个普通的 Django 模板就够了。页面布局用 CSS Grid 分成上下两行第一行三个图表第二行两个图表。每张图用独立的div容器然后写对应的 Echarts 初始化脚本。以播放活跃时段折线图为例核心配置如下fetch(/api/hour-activity/) .then(response response.json()) .then(data { const chart echarts.init(document.getElementById(chartActivity)); chart.setOption({ tooltip: { trigger: axis }, grid: { left: 60, right: 20, top: 40, bottom: 40 }, xAxis: { type: category, data: data.hours, axisLabel: { rotate: 45, fontSize: 11 } }, yAxis: { type: value, name: 播放次数 }, series: [{ name: 播放活跃量, type: line, smooth: true, areaStyle: { color: { type: linear, x: 0, y: 0, x2: 0, y2: 1, colorStops: [ { offset: 0, color: rgba(61, 153, 255, 0.6) }, { offset: 1, color: rgba(61, 153, 255, 0.05) } ] } }, data: data.counts }] }); });areaStyle渐变是近几年很流行的大屏视觉效果我在热搜词里也看到不少同学搜“echarts areastyle 渐变色”这个配置就是标准答案。渐变色的原理很简单指定colorStops数组控制不同的offset位置对应的颜色和透明度图表的填充区域就会生成从上到下的平滑渐变。再补充一个容易被忽略的细节图表容器要有明确高度。Echarts 初始化时如果容器被 CSS 隐藏或者高度为 0图表画出来就是空白。我踩过的坑是写了height: 100%但父容器没给高度结果整个图表白屏了十分钟。稳妥做法是直接给每个图表容器写死高度比如height: 360px或者用 flex 布局让父容器有确定高度后再用100%。4.3 推荐结果页与歌曲详情页怎么串起来推荐系统最终要展示在页面上。我做了两个入口首页的“猜你喜欢”模块和歌曲详情页的“相似推荐”模块。首页“猜你喜欢”逻辑很简单后端调用推荐函数拿到 TopN 歌曲 ID然后查歌曲表返回完整信息。在模板里渲染def index(request): if request.user.is_authenticated: recommended_ids get_recommendations(request.user.id) recommended_songs Song.objects.filter(id__inrecommended_ids) else: # 未登录时给热门歌曲做冷启动兜底 recommended_songs Song.objects.order_by(-play_count)[:10] return render(request, index.html, {songs: recommended_songs})歌曲详情页的“相似推荐”本质是查这个歌曲的相似列表取相似度最高的前 5 首。这一步是纯 Redis 读取非常快用户体验很好。这里我额外说一个答辩杀手锏做一个“干预按钮”。有些同学做完推荐算法就结束了但如果能加一个“刷新推荐”和“反馈不感兴趣”按钮用户点击后当前歌曲进入过滤名单下次推荐不再出现这在答辩演示时非常加分因为它体现了“推荐系统可反馈、可优化”的完整闭环。5. 常见问题与排查技巧实录这些都是我实际踩过的坑5.1 Django 静态文件 404 的经典大坑热搜词里我看到“vscode写img标签 在django的static文件中显示不了”这个搜索这几乎是每个 Django 新手都会撞上的问题。症状是模板里写了img src{% static img/cover.jpg %}页面加载时图片 404。排查顺序如下确保项目目录下有 static 目录并且settings.py里配置了STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]确保模板最顶部加载了{% load static %}。开发环境用runserver时Django 会自动处理 static 路由不需要额外配 urls但如果部署到服务器用了 Nginx 或 Apache必须在 Nginx 里单独配一个location /static/的映射否则生产环境百分之百 404。这个我在部署线上演示环境时反复踩坑后来学乖了本地调试一律用python manage.py runserver部署时用collectstatic收集静态文件交给 Nginx 托管。5.2 用户行为数据不足推荐结果太“冷”毕设项目最大的数据问题是冷启动。一个新注册用户一个行为都没有算法不知道给他推什么。我的解决方案是分层兜底新用户推全站热门 Top10 随机换一批不同风格歌曲先积累行为行为少于 5 条基于已播放歌曲的 Artist 和 Genre 属性做内容匹配比如用户刚听了周杰伦就把周杰伦其他歌推过去行为大于 5 条进入 ItemCF 协同过滤核心推荐。这种“冷启动 → 热启动”的渐进策略在业界也是标准做法。答辩时能讲出这一层说明你理解了推荐系统在实际工程中面对的完整问题而不只是会跑一个算法。5.3 百万级数据的性能危机当我把爬虫数据灌到接近 10 万首歌、80 万条行为记录后发现两个性能瓶颈。第一相似度矩阵用纯 Python 字典存储内存直接飙升到好几个 GB算一次要几分钟第二在线推荐查数据库超慢接口响应经常超过 10 秒。解决方案分三步走行为矩阵转稀疏矩阵、相似度矩阵存 Redis、在线推荐加索引优化。下面这段是优化后的核心代码用 scipy 稀疏矩阵计算共现矩阵from scipy.sparse import csr_matrix def build_cooccurrence_matrix(rows, cols, data): # rows, cols, data 分别是用户ID、歌曲ID、行为权重 # 把用户-歌曲矩阵构建成稀疏矩阵然后一次矩阵乘法求共现矩阵 user_item csr_matrix((data, (rows, cols))) # item 共现 (user_item^T) * user_item item_occur user_item.T user_item return item_occur.toarray()矩阵乘法完成共现矩阵计算是线性代数帮我们优化掉的循环这一步能把原来几分钟的计算压缩到几十秒以内。如果你还有 1 亿条以上的数据再考虑用分块计算或者数仓工具毕设阶段到稀疏矩阵优化就完全够用了。5.4 中文数据乱码用爬虫爬到的歌曲名如果出现乱码十有八九是 HTTP 响应的encoding没设置对。比如某些页面requests.get()默认用了ISO-8859-1解析中文全变成麦。解决方法是获取响应后用response.apparent_encoding或者直接指定utf-8再response.text。如果数据源给的是 JSON API用response.json()并确保Content-Type里有charsetutf-8。这个坑在爬虫入库阶段就要排查干净否则脏数据进了数据库后患无穷。5.5 前后端调试时 Vue/JS 变量跨域问题如果你的大屏页面使用了分离开发比如前端单独跑在 8080 端口、Django 跑在 8000 端口那一定会遇到跨域问题。Django 解决跨域非常简单安装django-cors-headers在settings.py的MIDDLEWARE加入CorsMiddleware然后配置CORS_ALLOWED_ORIGINS [ http://127.0.0.1:8080, ]毕设阶段强烈建议别搞前后端分离一个 Django 模板页面什么都能做完省掉跨域和部署两层麻烦。这个经验带过多个学弟后我已经很确定了功能优先架构其次能在最短时间内交付完整的系统才是毕业设计的核心诉求。6. 答辩加分项与项目扩展方向6.1 怎么把推荐系统讲出深度答辩时最怕的不是算法不先进而是你讲不清楚“为什么这么做”。我建议准备一份 15 分钟的逻辑链用户行为数据长什么样 → 为什么要转成用户-物品矩阵 → 矩阵为什么稀疏 → 稀疏矩阵用什么方法计算相似度 → 相似度算出来后如何给用户生成 TopN → 推荐结果如何评估。评估推荐效果有两个常见指标虽然毕设不一定要做线上 A/B test但你能说出这两个指标答辩的档次立刻不一样。PrecisionK是推荐列表里用户真正喜欢产生行为的比例RecallK是用户所有喜欢的物品里被推荐出来的比例。你可以在离线数据集上把历史行为切成训练集和测试集算出这两个指标哪怕数字不惊艳也能证明系统可验证、可迭代。6.2 扩展方向一引入基于内容的推荐协同过滤有天然的冷启动缺陷但基于内容的推荐完全不需要用户历史行为。它提取歌曲的歌手、风格、歌词关键词作为特征用 TF-IDF 或 Word2Vec 向量化然后计算歌曲间的余弦相似度。我给你的建议是在原有 ItemCF 基础上加一个简单的内容推荐分支新用户没有行为时就走内容推荐这样整个系统的推荐覆盖率会大幅提升。6.3 扩展方向二把推荐做成异步实时任务我现在改项目都会把算法服务挂在 Redis 队列后面。用户产生一条播放记录后通过信号量自动触发update_user_rec_cache任务异步更新这个用户的推荐缓存下次打开页面时直接命中缓存响应时间压缩到几十毫秒。这种“事件驱动 异步计算 缓存”的架构在答辩时讲出来获得的关注度远高于一个简单同步请求处理。6.4 扩展方向三混合推荐策略最后的工程化进阶是混合推荐把 ItemCF 的推荐结果、热门歌曲榜、内容推荐、和编辑精选四路结果各占不同权重最后做一次综合排序。权重的调优可以用一个简单的线性公式final_score 0.5 * itemcf_score 0.2 * content_score 0.2 * popularity_score 0.1 * trending_bonus。业界所有推荐系统的真实形态都是多路召回 统一排序你可以把这个思路写进论文的“后续工作”章节很自然也很专业。写在最后我做完这个项目后的几点实在体会这套音乐推荐系统如果按我的步骤走一个月内完成主体功能是稳妥的节奏。我个人最大的体会是毕业设计不是做产品而是向评委证明一件事你具备独立完成一个完整软件系统的能力。所以代码能不能跑通、功能链路是否完整、有没有解决实际问题的细节远比“用了多新的技术”更重要。我自己踩过的最大弯路就是在前期纠结算法精度调了一个星期的参数后来才发现用户端体验和可视化大屏的完整度才是真正拉开差距的地方。最后分享一个很实用的小技巧开发阶段一定要用版本管理工具每完成一个功能模块就提交一次。因为推荐系统涉及数据结构调整、算法参数调优、可视化配置改崩的概率很高有 commit 在手随时可以回滚。我见过太多学弟写了两周代码一次改动让整个数据库迁移失败因为没有版本管理只能从头再来。这个习惯比任何框架选型都重要。
Django+协同过滤：构建音乐推荐系统与可视化大屏
每年到这个时间点总有一批同学为毕业设计选题挠头。如果你懂一点 Python又不想做烂大街的图书管理系统或商城那我强烈建议你看看这个方向做一个基于 Django 协同过滤的音乐推荐系统再配一套 Echarts 可视化大屏。这个组合既能展示后端开发能力又有算法含量还能把数据可视化做得非常漂亮答辩时亮点十足。这套毕设方案我已经带好几个学弟完整跑通过今天把这套系统的实现思路、核心代码、踩坑经验一次讲透想复用的可以直接照着抄。先把这个项目解决了什么问题说清楚。市面上的音乐 App 都在推歌但绝大多数校园毕设只是简单做一个“歌曲展示 搜索”完全没有个性化推荐。而这个项目的核心在于根据用户的历史播放、收藏、点赞行为用协同过滤算法算出“和你品味相似的人喜欢什么”然后从百万级歌曲库里给你挑出可能喜欢的歌。同时后台管理端配了一套可视化大屏用 Echarts 把用户活跃时间段、热门歌曲榜、歌曲类型分布、地域播放热度直接画成图表让整个系统的数据价值一眼可见。这个选题既适合计算机科学、软件工程专业的毕设也适合对数据分析和可视化方向感兴趣的同学。1. 项目整体设计毕设到底要做什么、怎么分模块1.1 核心功能拆解我拿到这类项目的第一个习惯就是先不看代码把功能模块画清楚。音乐推荐系统的“用户端 管理端 推荐引擎 可视化大屏”四个模块缺一不可这也是答辩时最能体现系统完整性的地方。用户端要覆盖完整的使用链路注册登录、浏览歌曲、搜索歌手或歌名、点击播放、收藏歌曲、点赞评论行为。这里每一项操作都不是白做的播放、收藏、点赞都会成为推荐算法的输入数据。你在界面上看到的“猜你喜欢”“相似歌曲推荐”模块就是推荐引擎的计算结果。管理端则给管理员提供歌曲管理、用户管理、行为数据统计、推荐结果配置等功能。这里有个容易被忽略但很加分的做法用 Django 自带的 Admin 做基础管理再写几个自定义管理页面比如查看每个用户的推荐列表、手动下架不合规歌曲、调整热门歌曲榜的权重系数这在答辩演示时能体现完整的后台运营思维。推荐引擎是算法核心独立成一个服务模块不直接跟视图层耦合。业务上我采用的是 ItemCF基于物品的协同过滤后面细讲。引擎通过读取用户行为数据离线计算歌曲间的相似度矩阵再为每个用户实时生成 TopN 推荐列表。可视化大屏单独做成一个 Dashboard 页面放在管理端入口下。用 Echarts 渲染四张主图加两个数字卡片数据全部通过 Django 的 JSON 接口输出。毕竟毕设答辩时间有限大屏一拉开评委一眼就知道你做了数据可视化比看一堆代码截图强太多了。1.2 架构设计思路为什么这么分层这个项目的典型分层结构是“浏览器 → Django 视图 → Service 层 → 数据层”。我特别想强调 Service 层的存在价值不要在视图函数里直接写相似度计算和推荐逻辑。因为推荐算法模块将来可能换成基于内容推荐、深度学习模型或者改用 Celery 异步执行如果算法粘连在 view 里改一次就要动一大片代码。分层的收益短期看是代码整洁长期看是可维护、可扩展这是答辩时能聊出深度的点。实际项目里我建议数据流向是歌曲表 行为表 - 离线相似度计算可定时任务触发 - 相似度结果存入 Redis/数据库 - 用户访问推荐接口 - 读取用户行为 - 加权计算 - 返回 TopN 歌曲列表这里有一个关键设计相似度矩阵是离线的推荐列表是在线的。离线计算可以接受耗时比如几百毫秒甚至几秒都行它算完存起来在线推荐必须快扣除网络延迟后接口响应要求控制在 300 毫秒以内。这样划分后就算歌曲数据涨到十万、行为数据涨到百万推荐服务的压力依然可控这也是项目叫“分布式计算”的真实含义——计算任务与在线服务解耦重型计算拆分到后台任务里执行。2. 技术选型解析为什么是 Django、协同过滤和 Echarts2.1 后端框架Django 的取舍经常有人问这种毕设用 Flask 不行吗行但 Django 更适合。核心原因是 Django 自带 Admin 后台、ORM、Auth 用户认证、模板引擎这些都能直接复用省掉大量底层代码。具体到音乐推荐系统Django 的 ORM 对多表关联查询非常友好。我的数据表有 User、Song、PlayRecord、Favorite、Comment 五张核心表统计用户播放时长、获取用户收藏列表、按歌曲热度聚合行为数据用 ORM 的annotate和aggregate几行就搞定。如果用 Flask SQLAlchemy虽然也能做但要自己配一堆扩展调试成本高不少。Django 的 Auth 系统还能直接支持用户注册登录和 Session 管理建议直接继承AbstractUser扩展自定义字段比如头像、偏好风格、是否接受推荐邮件等。这里提醒一句Django 默认的 User 表不够用扩展用户表要在settings.py里配置AUTH_USER_MODEL并且必须在第一次迁移之前配好否则后面改表结构极其痛苦。2.2 算法选型ItemCF 为什么比 UserCF 更贴合音乐场景协同过滤分两类UserCF基于用户相似度和 ItemCF基于物品相似度。教科书写得比较绕我用大白话解释UserCF 是“和你喜好相似的人喜欢的歌你也会喜欢”先找同类用户再找歌ItemCF 是“和你之前喜欢的歌相似的其他歌你也会喜欢”先找相似歌曲再给你推。选 ItemCF 的原因非常实际第一音乐用户的兴趣相对分散但歌曲的“邻居关系”稳定。一首《晴天》和《七里香》的相似度是客观事实不随用户变化而剧烈变化但一个用户的兴趣可能一周一变UserCF 要实时计算用户相似度代价更高。第二ItemCF 的相似度矩阵可以离线算好在线只需查表加聚合。这对于 Django 这种同步框架更友好不会出现“在线推荐时还在跑双重循环”的性能灾难。第三ItemCF 给用户推荐的解释性强——系统可以说“因为你喜欢《晴天》所以为你推荐《七里香》”这种解释对用户体验和答辩展示都非常直观。当然ItemCF 也有软肋冷启动问题。新用户没有任何行为数据相似度计算就是空中楼阁。这个我在第五章专门讲怎么兜底。2.3 可视化层Echarts 的制图思路Echarts 是百度开源的可视化库到今天仍然是我做毕设大屏的首选。它的优势在于中文文档完善、社区案例多、配置项灵活一个折线图从零配到能看二十分钟就能搞定。对于一个音乐系统最出效果的图我建议做六张总用户数、总播放量的数字卡片用 Echarts 数字动画或纯 CSS 实现都行热门歌曲 Top10 柱状图推荐横向柱状图歌名再长也不怕截断歌曲类型占比的环形饼图能直观看到“民谣 30%、流行 40%、摇滚 15%”的分布24 小时播放活跃量的渐变面积折线图这一个图最能体现平台运营视角热门歌手词云图用 Echarts 的wordCloud扩展或 2D canvas 自绘用户地域分布的地图如果爬到的数据里没有地域信息可以用模拟数据生成。2.4 “分布式计算”到底怎么体现很多同学看到“分布式”三个字就心虚怕答辩被追问。这里我给你一套合理的落地方案毕设里说的分布式不需要上 Hadoop、Spark那种规模对音乐推荐系统完全没必要。我们用业界真正在用的轻量方案用Celery Redis做异步任务队列把离线相似度计算、定时热度统计、数据爬虫全部丢到异步 Worker 里执行用multiprocessing多进程并行处理数据爬虫的分片任务用 Redis 缓存相似度矩阵和热门榜单减少数据库压力。这三个手段叠加就可以在答辩时说清楚你把重计算任务与在线服务解耦通过消息队列实现任务分发、异步执行、结果缓存这就是分布式计算思想在项目里的工程落地。这样说既诚实又有深度比吹嘘“用了 Hadoop”实在多了。3. 数据模型设计与协同过滤算法的核心实现3.1 数据库表结构设计实战我的表结构是经过三轮重构后稳定下来的你直接参考这个设计基本不会踩坑from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): avatar models.URLField(default, blankTrue) preferred_genre models.CharField(max_length50, blankTrue, default) class Meta: db_table music_user class Song(models.Model): title models.CharField(max_length200) singer models.CharField(max_length100) album models.CharField(max_length200, blankTrue, default) genre models.CharField(max_length50, blankTrue, default) duration models.IntegerField(help_text时长单位秒) play_count models.IntegerField(default0) cover_url models.URLField(default, blankTrue) audio_url models.URLField(default, blankTrue) class Meta: db_table music_song indexes [ models.Index(fields[genre]), models.Index(fields[singer]), ] class PlayRecord(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_nameplay_records) song models.ForeignKey(Song, on_deletemodels.CASCADE, related_nameplay_records) played_at models.DateTimeField(auto_now_addTrue) play_duration models.IntegerField(default0, help_text实际播放时长秒) class Meta: db_table music_play_record indexes [ models.Index(fields[user, played_at]), models.Index(fields[song, played_at]), ] class Favorite(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_namefavorites) song models.ForeignKey(Song, on_deletemodels.CASCADE, related_namefavorites) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table music_favorite unique_together (user, song) class Comment(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE) song models.ForeignKey(Song, on_deletemodels.CASCADE) content models.TextField() created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table music_comment几个关键点说明unique_together保证用户对同一首歌只能收藏一次避免重复数据污染推荐算法PlayRecord的play_duration是推荐权重的重要参考比单纯记录有没有播过更有区分度所有表都建了数据库索引因为后面行为数据涨到几十万条时没有索引的数据库查询能慢到让你怀疑人生。3.2 ItemCF 协同过滤算法手写实现网上能找到很多现成的推荐系统代码但毕设答辩一定会问算法细节。我建议你亲手实现一遍核心逻辑即使最后调优后用了别的库手写版本也能让你在答辩时游刃有余。ItemCF 的经典实现分三步第一步构建“用户-物品”倒排表。原始行为数据长这样用户 1 播放过《晴天》《七里香》用户 2 播放过《晴天》《夜曲》用户 3 播放过《七里香》《夜曲》《简单爱》。要把数据整理成每个用户对应哪些歌。第二步计算物品间共现矩阵。统计两首歌被同一个用户一起行为播放/收藏/点赞的次数。如果一个用户对两首歌都有行为它们之间的共同出现次数加一。C[i][j]表示歌i和歌j的共现次数。第三步用余弦相似度归一化。直接用共现次数有个问题热门歌的共现次数天然高会霸榜。所以要除以两个物品各自行为人数的几何平均数import numpy as np def itemcf_similarity(play_records): # 构建 用户 - 歌曲集合 的倒排表 user_items {} for record in play_records: user_items.setdefault(record[user_id], set()).add(record[song_id]) # 构建物品共现矩阵 C {} N {} for user, items in user_items.items(): for i in items: N[i] N.get(i, 0) 1 C.setdefault(i, {}) for j in items: if i j: continue C[i][j] C[i].get(j, 0) 1 # 余弦相似度归一化 W {} for i, related_items in C.items(): W.setdefault(i, {}) for j, cij in related_items.items(): W[i][j] cij / np.sqrt(N[i] * N[j]) return W这里有几个计算细节要注意。第一如果用户行为里同时有播放、收藏、点赞可以把不同行为赋予不同权重收藏权重 1.0、点赞权重 0.6、播放且听完 0.4、只点开听了几句 0.1。这样计算出来的共现矩阵更贴近真实偏好。第二当数据量到了一定量级纯 Python 的双重循环会非常慢建议把行为矩阵转成scipy.sparse.csr_matrix稀疏矩阵然后用矩阵乘法一步算出共现矩阵速度提升几十倍。第三相似度矩阵算完要存到 Rediskey 结构用item_sim:song_idvalue 用排序后的 JSON 字符串这样推荐时直接取不用重复计算。3.3 在线推荐怎么打分拿到相似度矩阵以后为用户生成推荐列表就是加权求和def recommend(user_id, W, user_items, top_n10): # user_items: 当前用户已经产生过行为的歌曲集合 rank_score {} for item in user_items: # 遍历目标物品的相似物品列表 for similar_item, sim_score in W.get(item, {}).items(): if similar_item in user_items: continue # 过滤掉已经行为过的歌曲 # 用该用户对 item 的行为权重加权 rank_score[similar_item] rank_score.get(similar_item, 0) sim_score # 排序取 TopN return sorted(rank_score.items(), keylambda x: x[1], reverseTrue)[:top_n]可以简单解释一下用户播放过歌曲 A而歌曲 B 和 A 的相似度很高那么 B 就会获得一个加分。用户行为过的歌越多被加权的相似歌就越多最终得分最高的就是最值得推荐的歌。实际项目中我会额外加一个“时间衰减因子”用户三个月前的行为权重设为 0.3一周内的行为权重设为 1.0这样推荐结果能反映用户当前口味变化。在线接口部分我建议做成 Django 的 JsonResponse 接口前端用 Ajax 拉取后渲染。接口内部逻辑是先查 Redis 缓存缓存命中直接返回没命中再从数据库加载用户最近 50 条行为记录调用推荐函数算完回填缓存。缓存时间设置 10 分钟即可既不会太陈旧又不会频繁失效导致压力过大。4. 可视化大屏与核心页面实操从接口到图表的完整链路4.1 Django 后端如何给 Echarts 喂数据Echarts 本身是纯前端图表库它只管“拿到数据画图”不管数据从哪来。所以在 Django 项目里核心工作是把数据库统计结果变成 JSON 接口。以“24 小时播放活跃量折线图”为例我给你完整代码。首先在 views 里写一个统计接口from django.http import JsonResponse from django.db.models import Count from django.db.models.functions import TruncHour from django.utils import timezone from datetime import timedelta def hour_activity_api(request): # 统计最近7天的每个小时播放次数 since timezone.now() - timedelta(days7) rows ( PlayRecord.objects.filter(played_at__gtesince) .annotate(hourTruncHour(played_at)) .values(hour) .annotate(cntCount(id)) .order_by(hour) ) hours [r[hour].strftime(%m-%d %H:00) for r in rows] counts [r[cnt] for r in rows] return JsonResponse({hours: hours, counts: counts})然后配置 URL在 urls.py 里加上path(api/hour-activity/, hour_activity_api)。前端模板里用 Ajax 请求这个接口拿到数据后灌进 Echarts 配置项即可。同理歌曲 Top10 榜单接口长这样def top_songs_api(request): top_songs Song.objects.order_by(-play_count)[:10] data { songs: [s.title for s in top_songs], artists: [s.singer for s in top_songs], play_counts: [s.play_count for s in top_songs], } return JsonResponse(data)这里就体现出 Django ORM 的方便了按热门程度排序的聚合统计几乎是白送的。所有图表接口走/api/前缀统一返回 JSON哪怕以后前端换成 Vue 或 React 也完全不用改后端。4.2 Echarts 大屏页面配置要点大屏页面我建议不要用框架一个普通的 Django 模板就够了。页面布局用 CSS Grid 分成上下两行第一行三个图表第二行两个图表。每张图用独立的div容器然后写对应的 Echarts 初始化脚本。以播放活跃时段折线图为例核心配置如下fetch(/api/hour-activity/) .then(response response.json()) .then(data { const chart echarts.init(document.getElementById(chartActivity)); chart.setOption({ tooltip: { trigger: axis }, grid: { left: 60, right: 20, top: 40, bottom: 40 }, xAxis: { type: category, data: data.hours, axisLabel: { rotate: 45, fontSize: 11 } }, yAxis: { type: value, name: 播放次数 }, series: [{ name: 播放活跃量, type: line, smooth: true, areaStyle: { color: { type: linear, x: 0, y: 0, x2: 0, y2: 1, colorStops: [ { offset: 0, color: rgba(61, 153, 255, 0.6) }, { offset: 1, color: rgba(61, 153, 255, 0.05) } ] } }, data: data.counts }] }); });areaStyle渐变是近几年很流行的大屏视觉效果我在热搜词里也看到不少同学搜“echarts areastyle 渐变色”这个配置就是标准答案。渐变色的原理很简单指定colorStops数组控制不同的offset位置对应的颜色和透明度图表的填充区域就会生成从上到下的平滑渐变。再补充一个容易被忽略的细节图表容器要有明确高度。Echarts 初始化时如果容器被 CSS 隐藏或者高度为 0图表画出来就是空白。我踩过的坑是写了height: 100%但父容器没给高度结果整个图表白屏了十分钟。稳妥做法是直接给每个图表容器写死高度比如height: 360px或者用 flex 布局让父容器有确定高度后再用100%。4.3 推荐结果页与歌曲详情页怎么串起来推荐系统最终要展示在页面上。我做了两个入口首页的“猜你喜欢”模块和歌曲详情页的“相似推荐”模块。首页“猜你喜欢”逻辑很简单后端调用推荐函数拿到 TopN 歌曲 ID然后查歌曲表返回完整信息。在模板里渲染def index(request): if request.user.is_authenticated: recommended_ids get_recommendations(request.user.id) recommended_songs Song.objects.filter(id__inrecommended_ids) else: # 未登录时给热门歌曲做冷启动兜底 recommended_songs Song.objects.order_by(-play_count)[:10] return render(request, index.html, {songs: recommended_songs})歌曲详情页的“相似推荐”本质是查这个歌曲的相似列表取相似度最高的前 5 首。这一步是纯 Redis 读取非常快用户体验很好。这里我额外说一个答辩杀手锏做一个“干预按钮”。有些同学做完推荐算法就结束了但如果能加一个“刷新推荐”和“反馈不感兴趣”按钮用户点击后当前歌曲进入过滤名单下次推荐不再出现这在答辩演示时非常加分因为它体现了“推荐系统可反馈、可优化”的完整闭环。5. 常见问题与排查技巧实录这些都是我实际踩过的坑5.1 Django 静态文件 404 的经典大坑热搜词里我看到“vscode写img标签 在django的static文件中显示不了”这个搜索这几乎是每个 Django 新手都会撞上的问题。症状是模板里写了img src{% static img/cover.jpg %}页面加载时图片 404。排查顺序如下确保项目目录下有 static 目录并且settings.py里配置了STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]确保模板最顶部加载了{% load static %}。开发环境用runserver时Django 会自动处理 static 路由不需要额外配 urls但如果部署到服务器用了 Nginx 或 Apache必须在 Nginx 里单独配一个location /static/的映射否则生产环境百分之百 404。这个我在部署线上演示环境时反复踩坑后来学乖了本地调试一律用python manage.py runserver部署时用collectstatic收集静态文件交给 Nginx 托管。5.2 用户行为数据不足推荐结果太“冷”毕设项目最大的数据问题是冷启动。一个新注册用户一个行为都没有算法不知道给他推什么。我的解决方案是分层兜底新用户推全站热门 Top10 随机换一批不同风格歌曲先积累行为行为少于 5 条基于已播放歌曲的 Artist 和 Genre 属性做内容匹配比如用户刚听了周杰伦就把周杰伦其他歌推过去行为大于 5 条进入 ItemCF 协同过滤核心推荐。这种“冷启动 → 热启动”的渐进策略在业界也是标准做法。答辩时能讲出这一层说明你理解了推荐系统在实际工程中面对的完整问题而不只是会跑一个算法。5.3 百万级数据的性能危机当我把爬虫数据灌到接近 10 万首歌、80 万条行为记录后发现两个性能瓶颈。第一相似度矩阵用纯 Python 字典存储内存直接飙升到好几个 GB算一次要几分钟第二在线推荐查数据库超慢接口响应经常超过 10 秒。解决方案分三步走行为矩阵转稀疏矩阵、相似度矩阵存 Redis、在线推荐加索引优化。下面这段是优化后的核心代码用 scipy 稀疏矩阵计算共现矩阵from scipy.sparse import csr_matrix def build_cooccurrence_matrix(rows, cols, data): # rows, cols, data 分别是用户ID、歌曲ID、行为权重 # 把用户-歌曲矩阵构建成稀疏矩阵然后一次矩阵乘法求共现矩阵 user_item csr_matrix((data, (rows, cols))) # item 共现 (user_item^T) * user_item item_occur user_item.T user_item return item_occur.toarray()矩阵乘法完成共现矩阵计算是线性代数帮我们优化掉的循环这一步能把原来几分钟的计算压缩到几十秒以内。如果你还有 1 亿条以上的数据再考虑用分块计算或者数仓工具毕设阶段到稀疏矩阵优化就完全够用了。5.4 中文数据乱码用爬虫爬到的歌曲名如果出现乱码十有八九是 HTTP 响应的encoding没设置对。比如某些页面requests.get()默认用了ISO-8859-1解析中文全变成麦。解决方法是获取响应后用response.apparent_encoding或者直接指定utf-8再response.text。如果数据源给的是 JSON API用response.json()并确保Content-Type里有charsetutf-8。这个坑在爬虫入库阶段就要排查干净否则脏数据进了数据库后患无穷。5.5 前后端调试时 Vue/JS 变量跨域问题如果你的大屏页面使用了分离开发比如前端单独跑在 8080 端口、Django 跑在 8000 端口那一定会遇到跨域问题。Django 解决跨域非常简单安装django-cors-headers在settings.py的MIDDLEWARE加入CorsMiddleware然后配置CORS_ALLOWED_ORIGINS [ http://127.0.0.1:8080, ]毕设阶段强烈建议别搞前后端分离一个 Django 模板页面什么都能做完省掉跨域和部署两层麻烦。这个经验带过多个学弟后我已经很确定了功能优先架构其次能在最短时间内交付完整的系统才是毕业设计的核心诉求。6. 答辩加分项与项目扩展方向6.1 怎么把推荐系统讲出深度答辩时最怕的不是算法不先进而是你讲不清楚“为什么这么做”。我建议准备一份 15 分钟的逻辑链用户行为数据长什么样 → 为什么要转成用户-物品矩阵 → 矩阵为什么稀疏 → 稀疏矩阵用什么方法计算相似度 → 相似度算出来后如何给用户生成 TopN → 推荐结果如何评估。评估推荐效果有两个常见指标虽然毕设不一定要做线上 A/B test但你能说出这两个指标答辩的档次立刻不一样。PrecisionK是推荐列表里用户真正喜欢产生行为的比例RecallK是用户所有喜欢的物品里被推荐出来的比例。你可以在离线数据集上把历史行为切成训练集和测试集算出这两个指标哪怕数字不惊艳也能证明系统可验证、可迭代。6.2 扩展方向一引入基于内容的推荐协同过滤有天然的冷启动缺陷但基于内容的推荐完全不需要用户历史行为。它提取歌曲的歌手、风格、歌词关键词作为特征用 TF-IDF 或 Word2Vec 向量化然后计算歌曲间的余弦相似度。我给你的建议是在原有 ItemCF 基础上加一个简单的内容推荐分支新用户没有行为时就走内容推荐这样整个系统的推荐覆盖率会大幅提升。6.3 扩展方向二把推荐做成异步实时任务我现在改项目都会把算法服务挂在 Redis 队列后面。用户产生一条播放记录后通过信号量自动触发update_user_rec_cache任务异步更新这个用户的推荐缓存下次打开页面时直接命中缓存响应时间压缩到几十毫秒。这种“事件驱动 异步计算 缓存”的架构在答辩时讲出来获得的关注度远高于一个简单同步请求处理。6.4 扩展方向三混合推荐策略最后的工程化进阶是混合推荐把 ItemCF 的推荐结果、热门歌曲榜、内容推荐、和编辑精选四路结果各占不同权重最后做一次综合排序。权重的调优可以用一个简单的线性公式final_score 0.5 * itemcf_score 0.2 * content_score 0.2 * popularity_score 0.1 * trending_bonus。业界所有推荐系统的真实形态都是多路召回 统一排序你可以把这个思路写进论文的“后续工作”章节很自然也很专业。写在最后我做完这个项目后的几点实在体会这套音乐推荐系统如果按我的步骤走一个月内完成主体功能是稳妥的节奏。我个人最大的体会是毕业设计不是做产品而是向评委证明一件事你具备独立完成一个完整软件系统的能力。所以代码能不能跑通、功能链路是否完整、有没有解决实际问题的细节远比“用了多新的技术”更重要。我自己踩过的最大弯路就是在前期纠结算法精度调了一个星期的参数后来才发现用户端体验和可视化大屏的完整度才是真正拉开差距的地方。最后分享一个很实用的小技巧开发阶段一定要用版本管理工具每完成一个功能模块就提交一次。因为推荐系统涉及数据结构调整、算法参数调优、可视化配置改崩的概率很高有 commit 在手随时可以回滚。我见过太多学弟写了两周代码一次改动让整个数据库迁移失败因为没有版本管理只能从头再来。这个习惯比任何框架选型都重要。
