Django配合协同过滤做校园音乐推荐系统，这词儿在毕业设计题目里出现的频率真的不低。我第一次拿到这个题目的时候就有个判断：题目看似是个音乐网站，但它真正值钱的地方在“推荐”两个字上。很多同学把精力花在页面好不好看、列表整不整齐，结果到答辩时推荐模块一个像样的展示都没有，那这个题目就白做了。下面我会把这个系统的设计思路、数据库模型、协同过滤的代码实现、前后端数据流和踩坑经验按实际开发顺序拆一遍，适合准备拿这个题目做毕设的人，也适合想练手Django和推荐算法的开发者。

1. 项目概述与整体设计思路

1.1 校园音乐推荐系统到底要解决什么问题

一个合格的系统，首先要回答“它解决什么问题”，而不是“它堆了什么功能”。这个项目的典型场景是：校园环境里用户群体相对固定，大家听歌的偏好既有共性也有差异。传统音乐平台把歌曲摆在那里让用户自己挑，这对新用户并不友好；而校园用户更希望平台能猜到自己的口味，打开首页就能看到想听的歌。推荐系统就是这里的核心增值点。

我从需求角度把系统拆成四块。第一块是用户端基础功能：注册、登录、个人信息维护、听歌、打分、收藏。这些看似常规，其实是行为数据的入口。你想想，如果用户连打分按钮都找不到，推荐算法后面拿什么做计算？第二块是音乐资源管理：管理员要能录入歌曲、歌手、流派分类，还要维护音频地址和封面，毕竟平台需要有内容可推。第三块是推荐模块：根据用户历史行为生成个性化列表，至少要包含“猜你喜欢”和“相似歌曲推荐”两个区域。第四块是数据统计与后台管理，方便开发者自己测试和准备答辩数据。

实际做的时候，我建议把推荐模块作为整个系统的主线，其他所有功能都围绕它来设计。一个特别推荐的做法是：用户登录后随便点几首歌，一两分钟后首页推荐列表就发生变化。这种“操作后有反馈”的体验，比单独展示一个算法计算过程直观得多，也是答辩演示时可以拿出来讲的东西。

1.2 技术选型思考：Django搭协同过滤的合理性

这个项目用Django，在我看来说是性价比最高的选择也不为过。Django自带ORM、Admin后台、用户认证和模板引擎，不需要你额外搭建一套前后端分离的复杂架构。对于毕业设计来说时间有限，Django这种“短时间内快速产出可展示成果”的特质非常宝贵。

协同过滤算法属于典型的Python生态玩法，NumPy处理矩阵运算非常方便。你完全可以用纯Python手写相似度计算，但那会绕进循环优化的坑里，没必要。Django的视图函数可以直接调用这些算法模块，不需要额外的服务间通信，整个项目就是单机Web应用加算法模块的组合，简单直接。

有人会问，为什么不直接用现成的推荐系统框架？我的观点很明确：毕业设计阶段，自己动手实现一遍协同过滤，才能把原理讲清楚，论文和答辩才能有干货。框架可以提，但手写核心代码是明显加分项。如果老师在答辩时追问算法推导，你临时翻文档是来不及的。

1.3 推荐算法选型：协同过滤对比内容推荐的优势

推荐系统常见的方案有基于内容的推荐、协同过滤推荐和混合推荐。这个题目选协同过滤，有很实际的原因。

基于内容推荐依赖歌曲的丰富标签：曲风、节奏、歌词主题、歌手气质等。如果做内容推荐，你要么给每首歌人工打大量标签，要么接入外部音乐数据平台的API，这些对项目来说数据准备成本很高。而且歌曲库小的时候，标签覆盖率和质量难以保证，很容易推荐出风马牛不相及的内容。

协同过滤就不一样，它只依赖用户的评分、播放、收藏这些行为。只要有行为数据，算法会自动把目标用户和一批口味相似的“邻居”关联起来。校园场景用户行为相对集中，推荐效果一般都不错。我选协同过滤还有一个答辩层面的考虑：当老师问“为什么不用内容推荐”时，你可以把数据准备成本、推荐效果对比讲得头头是道，这本身就是亮点。

2. 数据库设计与核心业务落地

2.1 基础数据模型：四张表把系统串起来

数据库设计决定了后面所有功能是否顺手。我这次使用Django的ORM定义模型，核心其实就是四张表：用户表、歌曲表、流派分类表、评分记录表。用户表可以直接继承Django自带的AbstractUser，用户名、密码、邮箱、登录状态全都不用自己写，只需要扩展学号、专业、头像这些校园属性字段。

歌曲表保存歌名、歌手、所属分类、音频地址、封面地址、播放次数。流派分类表单独建一张，歌曲表通过外键关联它。为什么要单独建分类表而不是在歌曲表里写个字符串？因为字符串会出现“民谣”“Folk”“folk”这种同义不同名的脏数据，后面做分类筛选时会非常痛苦。

评分记录表是推荐系统的绝对核心，它关联用户和歌曲，记录评分值和收藏状态。我给这个表加上了一个(user, song)唯一约束，避免同一用户对同一首歌产生多条记录。这个约束一定要在一开始就加上，否则后面调试推荐结果时，你面对的将是一堆重复且互相矛盾的评分数据。

2.2 用户行为记录如何转化为推荐信号

推荐算法真正需要的输入，不是长篇大论的日志，而是“用户对歌曲打了多少分”这种明确信号。所以设计上要保证播放、收藏、评分三种行为都能转化成评分值。播放一次记1分，同一用户对同一首歌累加，上限5分；收藏直接记5分；打分就记用户填的分数。action_type字段用来保存行为来源，后期排查推荐结果时，你能知道某条评分是靠播放还是打分积累的。

这里有一个非常关键的产品细节：新用户进来往往不会马上打分，但他一定会点播歌曲。如果系统只收集打分数据，推荐模块很可能大量出现空白。所以播放行为也必须转成分，这样新用户才会发现“我多听了会儿歌，推荐就变了”。行为记录设计得越细，推荐系统介入用户体验的时间就越早。

2.3 用好Django Admin让测试造数更轻松

Django Admin不是摆设，在毕业设计里它是造数和验证数据的最好工具。把模型注册进Admin之后，歌曲、用户、评分都能在后台可视化增删改查。你可以先给两个测试账号分别打上不同歌曲的高分，再切换到前端看推荐结果是否符合预期。

我建议在Admin配置三个关键点：列表页显示的字段、顶部搜索、右侧筛选。歌曲管理按分类和歌手筛选，评分管理按用户和评分值筛选，用户管理按学号搜索。这样造数效率会高很多。给评分表加一个列表视图，还能直接观察到评分有没有被错误累加。后面写论文时，后台管理页面的截图也可以直接用在“系统功能模块”章节里，省得临时补图。

3. 协同过滤算法原理与代码实现

3.1 基于用户的协同过滤：找口味相近的人

基于用户的协同过滤，核心逻辑可以浓缩成一句：找到和你打分最像的那批用户，把他们喜欢而你还没听过的歌推荐给你。流程分三步：构造用户×歌曲评分矩阵，计算用户之间的相似度，再找K个最近邻预测你对未评分歌曲的评分。

举个例子。小明喜欢《南方车站》《深夜书店》，小红也喜欢这两首，同时小红还收藏了《凌晨三点的风》。算法会把小明和小红判定为口味相似的用户，如果小明没听过《凌晨三点的风》，系统就把它推荐给小明。这个模式在行为数据里非常直观，也容易在小范围内验证。

相似度计算我用的是余弦相似度。两个用户的评分向量越接近，余弦值越接近1；没有任何交集时趋于0。计算过程用NumPy实现，天然向量化。需要注意两个点：一是没评分的歌要补0；二是全零向量不能参与相似度计算，否则会产生除零错误。初学的时候很容易忽略这个细节。

3.2 基于物品的协同过滤：找风格相近的歌

基于物品的协同过滤换了角度思考：不找相似的人，而是找相似的歌。它的依据是，如果很多用户都喜欢A歌和B歌，那么这两首歌就算相似；当用户喜欢A时，系统就把B推荐出来。

这个方案有一个很大的好处：推荐结果解释性特别强。你看到页面写着“因为你收藏了《南方车站》，所以推荐《深夜书店》”，这种理由用户一看就懂，展示起来非常自然。对答辩来说，“推荐解释”也是重要加分项。

实现上，基于物品的协同过滤只需要把评分矩阵转置，让每首歌变成一行用户向量，再算歌曲之间的余弦相似度。工程上有个优化技巧：歌曲之间的相似度矩阵可以离线预先算好并缓存，因为歌曲数量通常远小于用户数量，矩阵更小、更新频率也可以更低。你在答辩时提这个优化思路，老师会认为你具备了工程意识。

3.3 推荐核心代码：从评分矩阵到推荐歌单

接下来是核心推荐代码，我会把方案按“建矩阵、算相似度、生成推荐”的顺序写清楚，目标是可以直接跑通。

# recommend/utils.py import numpy as np from music.models import Song, Rating def build_matrix(): """ 构建用户-歌曲评分矩阵，返回矩阵及ID索引映射。 """ ratings = Rating.objects.all().values("user_id", "song_id", "score") user_ids = sorted(set(r["user_id"] for r in ratings)) song_ids = sorted(set(r["song_id"] for r in ratings)) u_index = {uid: i for i, uid in enumerate(user_ids)} s_index = {sid: i for i, sid in enumerate(song_ids)} matrix = np.zeros((len(user_ids), len(song_ids))) for r in ratings: matrix[u_index[r["user_id"]], s_index[r["song_id"]]] = r["score"] return matrix, u_index, s_index, user_ids, song_ids def cosine_similarity(a, b): norm_a = np.linalg.norm(a) norm_b = np.linalg.norm(b) if norm_a == 0 or norm_b == 0: return 0 return float(np.dot(a, b) / (norm_a * norm_b)) def recommend(user_id, top_n=10): matrix, u_index, s_index, user_ids, song_ids = build_matrix() if user_id not in u_index: # 冷启动：新用户直接给热门歌曲 return list(Song.objects.order_by("-play_count")[:top_n].values_list("id", flat=True)) target_row = matrix[u_index[user_id]] sims = [] for uid, row in zip(user_ids, matrix): if uid == user_id: continue sims.append((uid, cosine_similarity(target_row, row))) sims.sort(key=lambda x: x[1], reverse=True) neighbors = sims[:5] # 取K=5个邻居 predict_scores = {} for j, sid in enumerate(song_ids): if target_row[j] != 0: continue total_sim = 0 total_score = 0 for uid, sim in neighbors: score = matrix[u_index[uid], j] if score > 0: total_sim += sim total_score += sim * score if total_sim > 0: predict_scores[sid] = total_score / total_sim ranked = sorted(predict_scores.items(), key=lambda x: x[1], reverse=True)[:top_n] return [sid for sid, _ in ranked]

这段代码有几处细节值得展开。构建矩阵时，用户ID和歌曲ID要被映射到连续的整数索引，因为NumPy下标只能是整数。计算相似度前要排除当前用户自己，同时避免除以零。预测评分时只处理目标用户没有评过分歌，避免重复推荐。如果用户没有任何评分记录，recommend函数会直接返回热门榜兜底。

提示：上面的recommend返回歌曲ID列表。视图函数拿到这些ID后，用Song.objects.filter(id__in=ids)查询完整对象，再传给模板。不过需要注意，Django按ID查询的结果顺序不保证与传入顺序一致，简单做法是查询后按原推荐顺序手动重排，否则前端展示的“优先级”会错乱。

3.4 推荐结果的新鲜度与多样性优化

协同过滤做到后面会遇到一个典型问题：推荐列表被头部热门歌曲长期霸占。因为高播放、高打分的歌在相似度计算里天然占优势，导致大家推来推去都是那几首。同时用户还可能反复看到自己已经听过的歌，体验非常差。

我的处理方案是给最终得分乘一个新鲜度系数。比如记录每个用户最近7天已经推荐的歌曲ID，在计算最终排序时对这些歌曲做降权。这个改动代码量不大，但推荐列表的更新感会明显变强。答辩时主动提一句“我通过曝光降权避免了推荐结果单一”，能体现你的完整工程思维，而不只是“调了一个算法”。

4. 实操过程与关键代码演示

4.1 搭建Django项目与基础配置

环境部分很简单，Python 3.10以上、Django 4.x、NumPy。创建项目也只需要两条命令：

pip install django numpy django-admin startproject music_sys cd music_sys python manage.py startapp music

创建完成后，打开settings.py，把music应用注册进INSTALLED_APPS。开发阶段用SQLite就足够，如果想要正式部署，再切换MySQL即可，修改DATABASES配置就行。这里有个原因需要说清楚：SQLite不需要额外装服务，对毕业设计演示非常友好，切换数据库只影响配置不影响业务代码。

这里一个反复出现的坑是：一定要先写好模型，再执行makemigrations和migrate。如果中途改模型，改完后直接重新迁移，不要手动去改数据库表结构。Django的迁移机制会跟踪模型和迁移文件的关系，手动改表会造成迁移状态不一致，项目启动时会报一堆字段缺失或多余的奇怪错误。

4.2 用户、歌曲、评分三个核心模型的代码实现

# models.py from django.db import models from django.contrib.auth.models import AbstractUser class UserProfile(AbstractUser): student_id = models.CharField(max_length=20, blank=True) major = models.CharField(max_length=50, blank=True) class Category(models.Model): name = models.CharField(max_length=20) class Song(models.Model): title = models.CharField(max_length=100) singer = models.CharField(max_length=50) category = models.ForeignKey(Category, on_delete=models.SET_NULL, null=True) audio_url = models.CharField(max_length=200) cover_url = models.CharField(max_length=200) play_count = models.IntegerField(default=0) class Rating(models.Model): user = models.ForeignKey(UserProfile, on_delete=models.CASCADE) song = models.ForeignKey(Song, on_delete=models.CASCADE) score = models.IntegerField(default=0) # 1~5 is_favorite = models.BooleanField(default=False) action_type = models.CharField(max_length=10, default="score") created_at = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ("user", "song")

这段模型代码里面，我认为最重要的设计点就是unique_together。它保证了同一个用户和同一首歌之间只可能有一条评分记录，这是后续协同过滤矩阵能够正确构建的前提。如果没有唯一约束，用户每次播放都会新建一条记录，评分矩阵会迅速膨胀且互相矛盾，推荐结果基本不可用。

另外，歌曲表的play_count和评分表的score要分开存储。play_count用于展示热门榜和冷启动兜底，score用于协同过滤计算。二者职责不同，混在一起会让逻辑混乱，比如用户播放次数和打分权重就无法区分。

4.3 播放与评分接口的完整逻辑

# views.py from django.shortcuts import get_object_or_404 from django.views.decorators.http import require_POST from django.http import JsonResponse from .models import Song, Rating @require_POST def record_play(request, song_id): song = get_object_or_404(Song, id=song_id) rating, created = Rating.objects.get_or_create( user=request.user, song=song, defaults={"score": 1, "action_type": "play"} ) if not created: rating.score = min(rating.score + 1, 5) rating.save() song.play_count += 1 song.save() return JsonResponse({"status": "ok"})

这个接口处理播放行为：第一次点播创建评分为1的记录，之后每次点播累加，但上限是5分，同时更新歌曲总播放次数。用get_or_create可以避免并发时产生重复记录，逻辑非常简洁。

评分接口的思路类似，用户提交分数后直接更新score字段，把action_type改为score。我建议把播放、收藏、评分分开记录，不要觉得多此一举。后面调试推荐结果时，如果出现一条评分来源不明，查看action_type就能定位问题，排查效率会高很多。

4.4 推荐页面的数据流转链路解析

从用户打开首页到看到推荐歌单，完整的数据流程是：视图函数先获取当前用户ID，调用推荐工具函数，函数内部构建评分矩阵、计算相似度、得到歌曲ID列表，再回到视图层查询歌曲完整信息，最后通过模板渲染到页面。

我在这里给一个工程建议：所有推荐逻辑统一放到独立的utils.py模块里，视图只负责调用和传数据。很多同学喜欢把所有代码堆在视图函数里，结果一个视图几百行，有Bug根本不好排查。拆分以后，视图代码短，算法代码集中在工具模块，老师翻代码时也能一眼看到规范的工程结构。

5. 常见问题排查与避坑经验

5.1 推荐结果不对：先排查数据再排查算法

调试中遇到最多的情况是代码没毛病，但推荐结果就是不对劲。最典型的原因是评分矩阵稀疏或者有重复数据。排查顺序应该是：先看评分表里有多少条记录，再看是否存在重复的(user, song)组合，最后再检查预测分数有没有异常值。

这里分享一个最小验证方法：在后台给两个测试账号分别打几首不同歌曲的高分，然后登录其中一个账号，看推荐列表里是否出现了另一个账号的高分歌曲。如果没出现，就打印相似度和预测分数，一步步定位是相似度计算的问题还是邻居选择的问题。这个方法比对着控制台反复猜测要高效得多。

5.2 冷启动与新歌曝光问题的处理思路

冷启动是协同过滤绕不开的痛点。新用户没有行为数据，无法计算相似度，我的策略是先展示热门歌曲榜；等用户产生几次播放或评分后，再切换成个性化推荐。新歌由于没有用户行为，协同过滤不会主动带它，处理办法是后台模拟几条评分，或者管理员把它手动挂到对应分类推广位。

这个处理方案直接服务于毕业设计演示。你可以开场先展示热门推荐，再给测试账号打几首歌的分，刷新页面展示个性化推荐发生的变化。这个前后对比本身就是很有说服力的演示逻辑，也表明你在设计时考虑过冷启动这类现实问题。

5.3 演示与答辩前的功能包装建议

答辩演示不能只展示静态页面。我强烈建议准备两个行为数据差异明显的测试账号，现场登录后直接展示“推荐结果不同”这一事实。这个对比最能直观证明协同过滤在起作用，比口头解释算法原理更高效。

再准备一页简洁的系统架构图或功能结构图，不需要花哨，但要把数据流向标清楚。答辩时老师问到任何技术问题，你都可以顺着这张图去讲，不容易乱。诸如“为什么不用基于内容的推荐”“相似度为什么选余弦而不是欧几里得距离”“算法时间和空间复杂度怎么样”这类问题，团队准备时要有清晰的答案，提前写在纸上都比现场想好。

5.4 实操中反复踩过的坑和应急方案

除了这张表里的问题，我特别想强调：算法实现不要一步到位追求完美，先跑通最简单的“热门推荐”，再换成“协同过滤”。每个阶段都有可验证结果，出问题也容易定位是哪一步引入的。直接一上来就上协同过滤，一旦推荐不符合预期，你很难分清是数据问题、算法问题还是前端展示问题。

做这个毕业设计项目，说实话最耗时的不是算法，而是把数据链路整理顺。我见过太多同学把时间花在看各种高深推荐系统资料上，结果连数据库模型都没建对。只要把用户、歌曲、评分这三张表理清楚，让用户能产生真实行为数据，协同过滤那部分代码其实很短。用最笨的方法先跑通，再谈优化，是我一直坚持的开发路线。

最后再分享一个小技巧：把测试过程录下来，尤其是从热门推荐变成个性化推荐的那一瞬间，视频素材放到论文和答辩PPT里，说服力比任何文字截图都强。这个项目做完之后如果还想扩展，可以继续加歌单推荐、按院系社群推荐，甚至换成基于深度学习的推荐模型。但现阶段，先把一条主链路打磨好，就是最好的成果。