【毕业设计】智能音乐评分与交流系统：把"评分"做成推荐、榜单和社区的共同支点

技术栈：Vue 3 + Vite + Element Plus + Pinia + Vue Router + Spring Boot 3 + Java 17 + MyBatis-Plus + MySQL + JWT + ECharts + echarts-wordcloud

功能关键词：双角色认证、音乐资源维护、歌曲筛选排序、评分评论、点赞收藏、试听记录、混合推荐、协同过滤、相似歌曲、冷启动推荐、高分榜、热度榜、新歌榜、榜单参数配置、ECharts 数据看板、评论热词云

一开始想做音乐类毕设，我其实有点犹豫，因为"音乐播放器"这个方向太容易做浅了——歌能放、列表能翻，就没了。答辩的时候老师一句"这跟网上的播放器有啥区别"就能问住。

后来我想明白一件事：音乐平台真正值钱的不是"能放歌"，而是它懂不懂你，以及陌生人之间能不能聊起来。这两个问题的交集，恰好就是"评分"。所以我给自己定了个主线：把评分当成整个系统的支点——推荐要用它、榜单要用它、社区互动也围着它转。这篇文章就把这套系统的设计思路和实现要点完整讲一遍，希望能给同样在找选题的同学一点参考。

一、选题背景与系统定位

先把要解决的问题说清楚。音乐类内容在线上主要有三个尴尬：

• 发现成本高：歌太多了，用户不知道听什么，平台给不出"像那么回事"的推荐；
• 互动留不住：听完就走，没有一个让人愿意留下痕迹的地方，评分、评论、收藏全都形同虚设；
• 榜单不可信：如果只按平均分排，"3 个人打 5 分"的歌能压过"1000 人打 4.8 分"的好歌，榜单就没人信了。

我想做的，是把这三个问题用系统的方式逐个解决：

• 发现成本高 → 做"猜你喜欢"混合推荐，协同过滤、相似歌曲、偏好内容三路合并，每条推荐都带理由；
• 互动留不住 → 把评分、评论回复、评论点赞、收藏、试听做成一套完整的互动记录，个人中心可查可管；
• 榜单不可信 → 高分榜用贝叶斯加权评分，把"评分人数"这个因素算进去，人数少的歌不会轻易冲顶。

系统采用前后端分离架构，一共两个角色：

二、技术选型与整体架构

技术选型上，我尽量让每一层都"有理由"，而不是堆名词：

有几个设计取舍想特别说明一下：

第一，为什么用余弦相似度算"相似的人"。每个用户对一批歌的评分，可以看成一个向量。两个人如果都对同一批歌打过高分，这两个向量的方向就接近，余弦相似度就高。我要求双方至少共同评分 2 首、且相似度大于 0.3才算有效邻居，最多取 5 个——门槛太低会引入噪声，太高又凑不出人。

第二，为什么榜单要"参数化"。一开始我想把参数写死在代码里，但后来发现不同阶段的运营需求不一样：歌少的时候门槛要低，歌多了门槛就得抬。于是我抽了一张榜单参数配置，最低评分人数、评分与人数权重、热度权重、新歌天数这些都能在后台改，刷新榜单时按最新参数重算。

第三，为什么高分榜要用贝叶斯加权而不是平均分。这是我觉得最能体现"想清楚了"的地方。纯平均分对评分人数少的歌极其不友好——一首歌只要 3 个粉丝打 5 分就是 5.0，能压过 1000 人打出来的 4.8。贝叶斯加权把全站平均分和最低评分人数门槛引入公式，评分人数少的时候会向全站均值"回拉"，人多了才让真实平均分说话。

三、数据库与核心表设计

系统围绕"资源维护 → 用户互动 → 推荐生成 → 榜单产出 → 数据统计"这条主数据链来建表，核心表大致分成四组：

第一组：音乐资源主体

• 歌曲表：名称、所属歌手、专辑、流派、时长、封面、简介、试听链接、试听来源、发布时间、平均评分、评分人数、评论数、收藏数、试听点击数、加权评分、热度分值
• 专辑表：专辑名、所属歌手、发行时间、封面、简介
• 歌手表：姓名、头像、简介、国籍、出道时间
• 音乐流派表：流派名称、描述、排序
• 风格标签表 / 歌曲标签关联表：标签名称、描述；歌曲与标签的多对多关联

第二组：用户互动

• 评分表：用户、歌曲、分值（1–5）、更新时间、异常标记
• 评论表：评论用户、歌曲、内容、父评论（parentId）、点赞数、审核状态（待审核/已通过/已拒绝）
• 评论点赞表：用户、评论，去重
• 收藏表：用户、歌曲，去重
• 试听点击记录表：用户、歌曲、点击时间

第三组：推荐与榜单

• 用户偏好表：偏好流派、偏好风格标签
• 榜单参数表：最低评分人数、评分权重、人数权重、热度权重、新歌天数、新歌综合权重等
• 榜单条目表：歌曲、榜单类型（高分/热度/新歌）、排名、榜单分数、生成时间

第四组：账号与审计

• 用户表：账号、密码、昵称、头像、邮箱、手机号、角色
• 操作日志表：操作用户、模块、请求地址、参数、IP、执行时间

这里有两个小设计我觉得挺关键：

一是评论为什么用 parentId 而不是单独建"回复表"。前台的评论是树形展示的：一条主评论下面挂若干回复。我把回复也存成一条评论记录，只是它的 parentId 指向主评论，加载时按 parentId 组装成树。这样一张表就够，不用维护两套结构。

二是统计字段为什么冗余在歌曲表上。歌曲表里存了平均评分、评分人数、评论数、收藏数、试听点击数、热度分值。这些数据严格来说都能从互动表算出来，但每次列表查询都去 join 聚合，性能会很差。所以我的做法是——用户每次评分、评论、收藏、试听，都同步更新歌曲表的对应统计字段，查询时直接读。

四、核心功能与实现要点

4.1 双角色登录、账号维护与页面访问控制

系统设置管理员和用户两类角色。用户登录后，服务端签发 JWT，前端在后续请求中通过 Authorization 请求头携带 Bearer Token；当前用户拦截器解析 Token 中的用户标识和角色信息，并写入当前请求上下文。前端路由根据角色区分管理工作台与用户服务端，未登录用户访问后台页面时跳转至登录页。系统同时提供注册、找回密码、修改密码、重置密码和个人资料维护能力；管理员可按账号、昵称、邮箱、手机号和角色分页查询账号，并提供账号导出入口。

注册或登录 → 服务端签发 JWT → 前端保存登录状态 → 请求携带 Bearer Token → 拦截器解析当前用户与角色 → 前端按角色进入用户页面或管理工作台

这里的重点是"当前用户从哪来"。我没有让前端传 userId，而是让拦截器统一从 Token 里解出来写进上下文。这样后台业务代码要拿"当前用户"直接取就行，也避免了前端伪造 userId 越权操作别人数据的风险。

4.2 音乐资源分类、内容维护与歌曲展示

平台以歌曲为核心资源。管理员维护音乐流派、风格标签、歌手和专辑后，可为歌曲配置所属歌手、专辑、流派、时长、封面、简介、试听链接、试听来源和发布时间，并通过歌曲标签关联补充风格标签。歌手记录保存头像、简介、国籍和出道时间，专辑记录保存所属歌手、发行时间、封面和简介。前台"发现音乐"页面按关键词、流派和歌手筛选歌曲，并支持按平均评分、热度分值和发布时间切换排序；歌曲、歌手和专辑详情页展示相互关联的资源信息。

维护流派、标签、歌手与专辑 → 录入歌曲并关联资源信息 → 配置封面、简介和试听链接 → 用户在发现音乐页筛选排序 → 进入歌曲、歌手或专辑详情查看关联内容

为什么歌手、专辑要单独建表？因为它们是天然可复用的实体——一个歌手有很多歌，一张专辑有很多首歌。如果全塞进歌曲表当字符串字段，改一次歌手简介要改几十条记录，还容易写错。拆出来后，歌曲详情页点歌手名能跳到歌手主页，点专辑能进专辑页，资源之间就有了"关联"而不只是"列表"。

4.3 评分评论、收藏点赞与个人互动记录

歌曲详情页提供评分、收藏、评论和评论点赞入口。评分记录以用户和歌曲为关联，分值范围为 1 至 5 分；新增或修改评分后，服务端重新计算歌曲的平均评分及评分人数。评论记录保存评论用户、歌曲、内容、父评论、点赞数和审核状态，前台按树形结构加载评论并支持回复；审核状态包括待审核、已通过和已拒绝。评论点赞和歌曲收藏均采用存在则取消、不存在则新增的切换方式，并同步更新歌曲评论、点赞或收藏相关统计。用户可在个人中心查看自己的评分、收藏和评论，并对评分、收藏或自己的评论执行相应维护操作。

用户评分、评论、收藏或试听 → 写入对应互动记录 → 更新歌曲及评论统计字段 → 个人中心按当前用户加载互动记录 → 后台统一查询和维护社区数据

"切换式"互动这块值得单说。点赞和收藏我做成了"存在就取消、不存在就新增"，只用一个接口搞定两种操作。好处是前端不用判断当前状态该调哪个接口，坏处是服务端要多查一次。我的取舍是：用一个唯一索引兜底，用户和评论、用户和歌曲的组合加唯一约束，重复插入直接失败，从数据库层面保证不会出现"同一个人点赞两次"。

另一个细节是评分要重算。用户改了评分之后，歌曲的平均分和评分人数都得跟着变。我是放在同一个事务里做的——先更新评分记录，再重新聚合歌曲的统计字段，要么都成要么都不成，避免出现"评分改了但平均分没变"的脏数据。

4.4 混合推荐、相似歌曲与冷启动推荐

"猜你喜欢"使用混合推荐策略。对于已有评分记录的用户，系统将用户协同过滤、基于已高分歌曲的相似歌曲推荐，以及用户偏好流派和风格标签的内容推荐按 0.4、0.35、0.25 的权重合并，排除当前用户已评分或已收藏的歌曲后按得分排序。用户协同过滤以评分向量计算余弦相似度，要求双方至少共同评分 2 首歌曲且相似度大于 0.3，最多选取 5 名相似用户；相似歌曲计算则综合标签 Jaccard 重合度、同流派、同歌手以及共同评分用户的皮尔逊相关性。当用户没有评分记录时，系统基于其已维护的偏好流派或标签推荐加权评分较高的歌曲，结果不足时再以热度歌曲补充。

读取用户评分、收藏与偏好记录 → 计算相似用户和相似歌曲 → 结合流派、标签偏好生成候选歌曲 → 按权重汇总、去重和排序 → 输出带推荐理由的歌曲列表

三路推荐为什么按 0.4 / 0.35 / 0.25 合并？我的排序逻辑是这样的：协同过滤最"懂人"，因为它参考的是跟你口味相近的人的真实行为，所以权重最高（0.4）；相似歌曲是"顺着你喜欢的这首往下找"，也很准，但覆盖面窄一点（0.35）；偏好内容推荐是最粗的一层，按流派和标签匹配，起兜底和补充作用（0.25）。三路分数归一化后加权相加，再排除你已经评过、藏过的歌，避免"推你喜欢过的"。

歌曲相似度为什么要四个维度加权？单看任何一维都有偏：只看标签重合，同标签但风格差很远的歌会被算成"相似"；只看同歌手，一个歌手所有歌都相似，太粗暴。所以我做了加权——标签 Jaccard 重合度（0.4）、同流派（0.25）、同歌手（0.2）、再看"共同给这两首歌打分的用户，评分是不是一致"（皮尔逊相关，0.15）。最后一维其实是在用真实用户行为校验"算法觉得像"和"人觉得像"是否一致。

冷启动怎么处理？新用户一条评分都没有，上面那套全跑不起来。我的兜底方案是：读他注册时维护的偏好流派和标签，推荐对应流派里加权评分高的歌；如果还不够，就按热度分值补热门歌。反正不能给他一个空页面。

4.5 高分榜、热度榜、新歌榜与参数配置

排行榜模块包含高分榜、热度榜和新歌榜三类。刷新榜单时，服务端读取榜单参数配置，重新计算歌曲分数后删除原榜单类型的旧条目并写入新的排名结果，每类榜单最多保存 20 条。高分榜以贝叶斯加权评分为基础，综合平均评分、评分人数、最低评分人数门槛及全站平均评分；热度榜对试听点击数、评论数和收藏数归一化后按配置权重计算热度分；新歌榜筛选配置天数范围内发布的歌曲，并按热度分和平均评分的配置权重计算综合分。前台排行榜页面支持切换三类榜单和手动刷新。

维护榜单参数 → 读取歌曲评分和互动统计 → 分别计算高分、热度与新歌分值 → 清除同类型历史条目 → 保存新的排名、分数和生成时间 → 前台切换查看榜单

三个榜单为什么要"重新生成"而不是"实时算"？因为榜单计算要扫全站评分和互动数据，如果每个用户打开排行页都实时算一遍，数据库扛不住。所以我的做法是——管理员（或定时任务）触发刷新时才算一次，算完把结果作为榜单条目存下来，前台读的就是这张表。每类榜单只留 20 条，旧条目先删再写，保证数据不会越积越多。

热度为什么要归一化？试听数是几万量级，评论数是几百量级，收藏数介于中间。如果直接把三个数加权相加，试听数会完全碾压其他两项，热度榜就变成了"试听榜"。所以我对每一项做了归一化（除以该项的最大值），让它们都落在 0 到 1 之间，再按权重合成，这样三个指标才真正"势均力敌"。

4.6 数据看板、资源分析与社区互动分析

管理端控制台以 ECharts 展示用户、歌曲、专辑、歌手、评论、评分、收藏和试听总量，并提供近 30 天用户注册趋势、热门歌曲 TOP10、流派歌曲分布、近 30 天评论评分收藏趋势和最新 10 条评论。音乐资源分析页面展示歌曲、专辑、歌手、流派和标签总量，并提供流派歌曲数量、歌手歌曲数量排行、近 30 天专辑发行趋势、歌曲平均评分区间及歌曲时长分布。社区互动分析页面统计评论、点赞、评分、收藏、试听和活跃用户，展示近 30 天评论趋势、1 至 5 分评分分布、各流派的评论评分收藏互动总量、互动用户雷达图和评论关键词词云。后台菜单还提供对账号、资源、互动记录、榜单及操作日志的统一维护入口。

加载资源与互动记录 → 汇总数量和时间趋势 → 按流派、歌手、评分或时长聚合 → 返回图表数据 → 管理端使用 ECharts 与词云组件展示

词云这块我自己挺喜欢。评论看多了其实能看出用户在想什么——有人夸唱功、有人聊歌词、有人单纯说"循环一整天"。我把评论内容抽关键词和频次，用 echarts-wordcloud 画成词云，管理员一眼就能看出最近大家在聊什么。这比单纯列一条条评论直观多了。

五、界面展示

以下为系统主要界面截图，共 17 张。

系统总览

音乐平台主视觉入口，用户可进入音乐发现、排行榜与个人中心。

用户端

首页：热门歌曲、猜你喜欢与"品味相似的人"集中呈现，推荐结果带推荐理由。

发现音乐：按关键词、流派和歌手筛选歌曲，支持按综合、评分、热度或发布时间排序。

音乐详情：查看歌曲、歌手、专辑与流派信息，进行评分、收藏、评论、试听，并查看相似歌曲推荐。

排行榜：切换高分榜、热度榜、新歌榜并支持手动刷新，展示排名与榜单分数。

我的收藏：个人中心集中查看已收藏歌曲，支持分页浏览与取消收藏。

我的评分：查看并维护自己的评分记录，修改或删除后服务端同步重算歌曲评分。

我的评论：查看自己的评论与回复记录，可删除本人评论并在详情页继续互动。

管理员端

歌曲管理：维护歌曲名称、所属歌手专辑、流派、时长、封面、简介与试听链接，支持条件查询与批量删除。

专辑管理：维护专辑封面、发行时间、所属歌手与简介，歌曲详情可跳转至关联专辑。

歌手管理：维护歌手头像、简介、国籍与出道时间，并与专辑、歌曲建立关联。

音乐流派：维护流派名称、描述与排序，作为歌曲分类与推荐的内容依据。

数据分析：控制台汇总用户、歌曲、专辑、歌手、评论、评分、收藏与试听总量，并展示近 30 天注册趋势与热门歌曲 TOP10。

用户偏好：按流派与风格标签统计用户偏好分布，为内容推荐与冷启动补充提供依据。

歌曲评论：查看与维护歌曲评论及回复，管理评论审核状态与点赞情况。

试听点击记录：查询用户试听点击明细，作为热度榜分值与音乐资源分析的统计来源。

榜单条目：查看高分榜、热度榜与新歌榜的排名、榜单分数与生成时间，配合榜单参数统一维护。

六、这套系统适合谁

• 想做算法向选题的毕设：协同过滤、相似度计算、混合权重、贝叶斯加权都有具体公式和参数，论文算法章节有东西可写；
• 想体现推荐冷启动思路的同学：有评分走协同过滤与相似歌曲，没评分走偏好与热度补充，能把"两种情况怎么处理"讲清楚；
• 想练榜单与参数化设计的同学：高分榜、热度榜、新歌榜共用一套参数配置，改参数即可重算，逻辑统一；
• 想加数据可视化落点的同学：ECharts 多图表 + echarts-wordcloud 词云，看板、资源分析、互动分析三块都有图；
• 想讲清互动与统计联动的同学：评分改一次就要重算平均分，点赞收藏切换要同步统计，边界处理有讲头；
• 需要前后端分离 + JWT 权限落地的场景：双角色路由控制、拦截器解析当前用户，权限链路完整。

七、说明

文档展示 17 张截图，需要了解更多，请联系我。