智能音乐评分与交流系统（基于用户评分、歌曲相似度和偏好标签的混合推荐，ECharts分析，歌曲评分、评论、点赞、收藏与试听互动，高分榜、热度榜和新歌榜）

【毕业设计】智能音乐评分与交流系统把评分做成推荐、榜单和社区的共同支点技术栈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 分的好歌榜单就没人信了。我想做的是把这三个问题用系统的方式逐个解决发现成本高 → 做猜你喜欢混合推荐协同过滤、相似歌曲、偏好内容三路合并每条推荐都带理由互动留不住 → 把评分、评论回复、评论点赞、收藏、试听做成一套完整的互动记录个人中心可查可管榜单不可信 → 高分榜用贝叶斯加权评分把评分人数这个因素算进去人数少的歌不会轻易冲顶。系统采用前后端分离架构一共两个角色角色主要使用范围普通用户按关键词、流派、歌手筛选歌曲并按综合/评分/热度/发布时间排序查看歌曲、歌手、专辑与流派详情进行评分、收藏、评论回复、评论点赞与试听查看相似歌曲、排行榜与个性化推荐在个人中心维护资料、密码、我的评分、我的收藏和我的评论管理员维护账号、歌曲、专辑、歌手、音乐流派、风格标签及歌曲标签关联管理评分、评论、评论点赞、收藏、试听点击记录、榜单参数与榜单条目通过控制台、音乐资源分析和社区互动分析查看平台数据二、技术选型与整体架构技术选型上我尽量让每一层都有理由而不是堆名词层级主要技术与职责用户服务端基于 Vue 3、Vite、Element Plus、Pinia、Vue Router 和 Axios 构建提供音乐发现、歌曲详情、歌手与专辑详情、评分、评论、收藏、试听、排行榜、个性化推荐和个人中心等功能管理工作台基于 Vue 3、Element Plus、ECharts 和 echarts-wordcloud 实现。管理员可维护账号、音乐资源、互动记录和榜单数据并查看控制台汇总、音乐资源分析及社区互动分析服务端基于 Spring Boot 3、Java 17、Spring MVC、MyBatis-Plus、MySQL 和 JWT 提供接口服务包含分页查询、文件上传、当前用户身份解析、统一响应、异常处理和数据持久化能力推荐与榜单能力推荐模块组合用户协同过滤、相似歌曲和偏好内容推荐榜单模块根据可配置参数生成高分榜、热度榜和新歌榜并保存对应榜单条目有几个设计取舍想特别说明一下第一为什么用余弦相似度算相似的人。每个用户对一批歌的评分可以看成一个向量。两个人如果都对同一批歌打过高分这两个向量的方向就接近余弦相似度就高。我要求双方至少共同评分 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 → 拦截器解析当前用户与角色 → 前端按角色进入用户页面或管理工作台业务场景系统处理结果身份认证登录接口返回 JWT拦截器从 Authorization 请求头读取 Bearer Token解析其中的用户 ID 和角色并建立当前请求的用户上下文账号服务系统提供用户注册、登录、找回密码、修改密码和管理员重置密码接口用户可在个人中心修改头像、昵称、邮箱和手机号等资料角色路由前端路由将管理端页面标记为管理员页面。管理员登录后进入管理工作台普通用户进入前台功能页面账号与操作记录后台账号列表支持条件分页查询、维护和导出AOP 切面会对控制器中的新增、修改、删除及批量删除等操作记录用户、模块、请求地址、参数、IP 和执行时间这里的重点是当前用户从哪来。我没有让前端传 userId而是让拦截器统一从 Token 里解出来写进上下文。这样后台业务代码要拿当前用户直接取就行也避免了前端伪造 userId 越权操作别人数据的风险。4.2 音乐资源分类、内容维护与歌曲展示平台以歌曲为核心资源。管理员维护音乐流派、风格标签、歌手和专辑后可为歌曲配置所属歌手、专辑、流派、时长、封面、简介、试听链接、试听来源和发布时间并通过歌曲标签关联补充风格标签。歌手记录保存头像、简介、国籍和出道时间专辑记录保存所属歌手、发行时间、封面和简介。前台发现音乐页面按关键词、流派和歌手筛选歌曲并支持按平均评分、热度分值和发布时间切换排序歌曲、歌手和专辑详情页展示相互关联的资源信息。维护流派、标签、歌手与专辑 → 录入歌曲并关联资源信息 → 配置封面、简介和试听链接 → 用户在发现音乐页筛选排序 → 进入歌曲、歌手或专辑详情查看关联内容资源场景系统处理结果流派与风格标签音乐流派和风格标签均保存名称、描述和排序歌曲通过流派字段及歌曲标签关联记录对应的分类信息歌手与专辑歌手可维护头像、简介、国籍和出道时间专辑可关联歌手并维护发行时间、封面和简介歌曲详情可跳转至关联歌手或专辑页面歌曲资源歌曲保存名称、关联资源、时长、封面、简介、试听链接和发布时间并维护平均评分、评分人数、评论数、收藏数、试听点击数、加权评分和热度分值等统计字段试听入口用户点击歌曲详情页的试听操作时前端提交试听点击记录存在试听链接时页面会在新窗口打开该链接为什么歌手、专辑要单独建表因为它们是天然可复用的实体——一个歌手有很多歌一张专辑有很多首歌。如果全塞进歌曲表当字符串字段改一次歌手简介要改几十条记录还容易写错。拆出来后歌曲详情页点歌手名能跳到歌手主页点专辑能进专辑页资源之间就有了关联而不只是列表。4.3 评分评论、收藏点赞与个人互动记录歌曲详情页提供评分、收藏、评论和评论点赞入口。评分记录以用户和歌曲为关联分值范围为 1 至 5 分新增或修改评分后服务端重新计算歌曲的平均评分及评分人数。评论记录保存评论用户、歌曲、内容、父评论、点赞数和审核状态前台按树形结构加载评论并支持回复审核状态包括待审核、已通过和已拒绝。评论点赞和歌曲收藏均采用存在则取消、不存在则新增的切换方式并同步更新歌曲评论、点赞或收藏相关统计。用户可在个人中心查看自己的评分、收藏和评论并对评分、收藏或自己的评论执行相应维护操作。用户评分、评论、收藏或试听 → 写入对应互动记录 → 更新歌曲及评论统计字段 → 个人中心按当前用户加载互动记录 → 后台统一查询和维护社区数据互动场景系统处理结果歌曲评分评分记录保存用户、歌曲、分值、更新时间和异常标记用户可在歌曲详情提交评分也可在我的评分中修改或删除记录评论与回复评论以 parentId 表示父评论详情页按树形结构展示评论及回复用户可删除自己的评论后台可查看和维护评论审核状态点赞与收藏评论点赞按用户和评论记录去重并支持取消歌曲收藏按用户和歌曲记录去重并支持取消个人中心可分页查看收藏的歌曲试听记录试听点击记录关联用户和歌曲并保存点击时间后台提供试听点击记录的分页查询与维护入口切换式互动这块值得单说。点赞和收藏我做成了存在就取消、不存在就新增只用一个接口搞定两种操作。好处是前端不用判断当前状态该调哪个接口坏处是服务端要多查一次。我的取舍是用一个唯一索引兜底用户和评论、用户和歌曲的组合加唯一约束重复插入直接失败从数据库层面保证不会出现同一个人点赞两次。另一个细节是评分要重算。用户改了评分之后歌曲的平均分和评分人数都得跟着变。我是放在同一个事务里做的——先更新评分记录再重新聚合歌曲的统计字段要么都成要么都不成避免出现评分改了但平均分没变的脏数据。4.4 混合推荐、相似歌曲与冷启动推荐猜你喜欢使用混合推荐策略。对于已有评分记录的用户系统将用户协同过滤、基于已高分歌曲的相似歌曲推荐以及用户偏好流派和风格标签的内容推荐按 0.4、0.35、0.25 的权重合并排除当前用户已评分或已收藏的歌曲后按得分排序。用户协同过滤以评分向量计算余弦相似度要求双方至少共同评分 2 首歌曲且相似度大于 0.3最多选取 5 名相似用户相似歌曲计算则综合标签 Jaccard 重合度、同流派、同歌手以及共同评分用户的皮尔逊相关性。当用户没有评分记录时系统基于其已维护的偏好流派或标签推荐加权评分较高的歌曲结果不足时再以热度歌曲补充。读取用户评分、收藏与偏好记录 → 计算相似用户和相似歌曲 → 结合流派、标签偏好生成候选歌曲 → 按权重汇总、去重和排序 → 输出带推荐理由的歌曲列表推荐场景系统处理结果用户协同过滤系统从其他非管理员用户的评分中计算余弦相似度将相似用户评分不低于 4 分且当前用户未互动的歌曲作为候选并按相似度和评分贡献累加得分相似歌曲歌曲相似度由标签重合度0.4、同流派0.25、同歌手0.2和评分相关性0.15构成歌曲详情页可展示相似歌曲及对应推荐理由偏好内容推荐系统读取用户偏好流派和风格标签向未互动歌曲匹配对应内容并结合歌曲平均评分形成内容推荐得分冷启动补充用户没有评分记录时优先按偏好流派和标签选择加权评分较高的歌曲推荐数量不足时按热度分值补充热门歌曲三路推荐为什么按 0.4 / 0.35 / 0.25 合并我的排序逻辑是这样的协同过滤最懂人因为它参考的是跟你口味相近的人的真实行为所以权重最高0.4相似歌曲是顺着你喜欢的这首往下找也很准但覆盖面窄一点0.35偏好内容推荐是最粗的一层按流派和标签匹配起兜底和补充作用0.25。三路分数归一化后加权相加再排除你已经评过、藏过的歌避免推你喜欢过的。歌曲相似度为什么要四个维度加权单看任何一维都有偏只看标签重合同标签但风格差很远的歌会被算成相似只看同歌手一个歌手所有歌都相似太粗暴。所以我做了加权——标签 Jaccard 重合度0.4、同流派0.25、同歌手0.2、再看共同给这两首歌打分的用户评分是不是一致皮尔逊相关0.15。最后一维其实是在用真实用户行为校验算法觉得像和人觉得像是否一致。冷启动怎么处理新用户一条评分都没有上面那套全跑不起来。我的兜底方案是读他注册时维护的偏好流派和标签推荐对应流派里加权评分高的歌如果还不够就按热度分值补热门歌。反正不能给他一个空页面。4.5 高分榜、热度榜、新歌榜与参数配置排行榜模块包含高分榜、热度榜和新歌榜三类。刷新榜单时服务端读取榜单参数配置重新计算歌曲分数后删除原榜单类型的旧条目并写入新的排名结果每类榜单最多保存 20 条。高分榜以贝叶斯加权评分为基础综合平均评分、评分人数、最低评分人数门槛及全站平均评分热度榜对试听点击数、评论数和收藏数归一化后按配置权重计算热度分新歌榜筛选配置天数范围内发布的歌曲并按热度分和平均评分的配置权重计算综合分。前台排行榜页面支持切换三类榜单和手动刷新。维护榜单参数 → 读取歌曲评分和互动统计 → 分别计算高分、热度与新歌分值 → 清除同类型历史条目 → 保存新的排名、分数和生成时间 → 前台切换查看榜单榜单类型系统处理结果高分榜采用贝叶斯加权评分公式默认最低评分人数为 10默认按平均评分 0.7 和归一化评分人数 0.3 合成最终分值相关参数可在榜单配置中维护热度榜按试听、评论和收藏的数量分别归一化后计算热度分默认权重为 0.4、0.3、0.3参数可配置新歌榜默认筛选近 90 天发布的歌曲将热度分和平均评分按默认各 0.5 的权重合成综合分天数和权重可配置榜单条目榜单条目保存歌曲、榜单类型、排名、榜单分数和生成时间后台可查询并维护榜单参数与条目三个榜单为什么要重新生成而不是实时算因为榜单计算要扫全站评分和互动数据如果每个用户打开排行页都实时算一遍数据库扛不住。所以我的做法是——管理员或定时任务触发刷新时才算一次算完把结果作为榜单条目存下来前台读的就是这张表。每类榜单只留 20 条旧条目先删再写保证数据不会越积越多。热度为什么要归一化试听数是几万量级评论数是几百量级收藏数介于中间。如果直接把三个数加权相加试听数会完全碾压其他两项热度榜就变成了试听榜。所以我对每一项做了归一化除以该项的最大值让它们都落在 0 到 1 之间再按权重合成这样三个指标才真正势均力敌。4.6 数据看板、资源分析与社区互动分析管理端控制台以 ECharts 展示用户、歌曲、专辑、歌手、评论、评分、收藏和试听总量并提供近 30 天用户注册趋势、热门歌曲 TOP10、流派歌曲分布、近 30 天评论评分收藏趋势和最新 10 条评论。音乐资源分析页面展示歌曲、专辑、歌手、流派和标签总量并提供流派歌曲数量、歌手歌曲数量排行、近 30 天专辑发行趋势、歌曲平均评分区间及歌曲时长分布。社区互动分析页面统计评论、点赞、评分、收藏、试听和活跃用户展示近 30 天评论趋势、1 至 5 分评分分布、各流派的评论评分收藏互动总量、互动用户雷达图和评论关键词词云。后台菜单还提供对账号、资源、互动记录、榜单及操作日志的统一维护入口。加载资源与互动记录 → 汇总数量和时间趋势 → 按流派、歌手、评分或时长聚合 → 返回图表数据 → 管理端使用 ECharts 与词云组件展示管理与分析能力系统处理结果控制台概览展示平台资源与互动总量、近 30 天用户注册趋势、热门歌曲 TOP10、流派歌曲分布、近 30 天互动趋势及最新评论音乐资源分析按流派统计歌曲数量按歌曲数量统计歌手排行按日期统计近 30 天专辑发行量并统计歌曲评分区间和时长区间社区互动分析统计评论、点赞、评分、收藏、试听及活跃用户按流派汇总评论、评分和收藏量并对互动较多的用户展示评论、评分、收藏、点赞和试听五个维度评论热词服务端从评论内容中提取关键词及频次管理端通过 echarts-wordcloud 绘制评论热词云词云这块我自己挺喜欢。评论看多了其实能看出用户在想什么——有人夸唱功、有人聊歌词、有人单纯说循环一整天。我把评论内容抽关键词和频次用 echarts-wordcloud 画成词云管理员一眼就能看出最近大家在聊什么。这比单纯列一条条评论直观多了。五、界面展示以下为系统主要界面截图共 17 张。系统总览音乐平台主视觉入口用户可进入音乐发现、排行榜与个人中心。用户端首页热门歌曲、猜你喜欢与品味相似的人集中呈现推荐结果带推荐理由。发现音乐按关键词、流派和歌手筛选歌曲支持按综合、评分、热度或发布时间排序。音乐详情查看歌曲、歌手、专辑与流派信息进行评分、收藏、评论、试听并查看相似歌曲推荐。排行榜切换高分榜、热度榜、新歌榜并支持手动刷新展示排名与榜单分数。我的收藏个人中心集中查看已收藏歌曲支持分页浏览与取消收藏。我的评分查看并维护自己的评分记录修改或删除后服务端同步重算歌曲评分。我的评论查看自己的评论与回复记录可删除本人评论并在详情页继续互动。管理员端歌曲管理维护歌曲名称、所属歌手专辑、流派、时长、封面、简介与试听链接支持条件查询与批量删除。专辑管理维护专辑封面、发行时间、所属歌手与简介歌曲详情可跳转至关联专辑。歌手管理维护歌手头像、简介、国籍与出道时间并与专辑、歌曲建立关联。音乐流派维护流派名称、描述与排序作为歌曲分类与推荐的内容依据。数据分析控制台汇总用户、歌曲、专辑、歌手、评论、评分、收藏与试听总量并展示近 30 天注册趋势与热门歌曲 TOP10。用户偏好按流派与风格标签统计用户偏好分布为内容推荐与冷启动补充提供依据。歌曲评论查看与维护歌曲评论及回复管理评论审核状态与点赞情况。试听点击记录查询用户试听点击明细作为热度榜分值与音乐资源分析的统计来源。榜单条目查看高分榜、热度榜与新歌榜的排名、榜单分数与生成时间配合榜单参数统一维护。六、这套系统适合谁想做算法向选题的毕设协同过滤、相似度计算、混合权重、贝叶斯加权都有具体公式和参数论文算法章节有东西可写想体现推荐冷启动思路的同学有评分走协同过滤与相似歌曲没评分走偏好与热度补充能把两种情况怎么处理讲清楚想练榜单与参数化设计的同学高分榜、热度榜、新歌榜共用一套参数配置改参数即可重算逻辑统一想加数据可视化落点的同学ECharts 多图表 echarts-wordcloud 词云看板、资源分析、互动分析三块都有图想讲清互动与统计联动的同学评分改一次就要重算平均分点赞收藏切换要同步统计边界处理有讲头需要前后端分离 JWT 权限落地的场景双角色路由控制、拦截器解析当前用户权限链路完整。七、说明文档展示 17 张截图需要了解更多请联系我。