做毕业设计这几年“音乐畅听系统”这个题目几乎每年都有人选但绝大多数人做出来只是个“换皮播放器”——能放歌、能搜索、能注册登录然后就没有然后了。真正拉开差距的是你有没有把“智能音乐播放与互动平台”这个副标题里的水做出来文件能不能断点续传聊天室能不能扛住几十人同时发言点赞和播放量在并发下会不会乱掉这些才是老师答辩时盯着问的点也是你写在简历上能站住脚的东西。这篇就把我这套Java音乐畅听系统的完整设计思路、表结构、核心代码和踩坑过程拆开讲透适合正在做毕业设计、或者想拿一个完整Java Web项目去面试的人参考。1. 项目整体设计与思路拆解1.1 从题目看真正的需求标题一共给了三个关键词Java、音乐畅听系统、线上音乐分享与聊天室系统。拆开看它其实要求的是这样一个东西一个 B/C 架构的 Web 应用后端用 Java 生态必须有音乐上传、播放、搜索、收藏等常规功能这是“畅听”的底座必须有用户互动能力比如实时聊天室这是“互动平台”的加分项整体要像一个“线上下载/分享平台”而不是一个本地播放器。很多同学一开始把精力花在播放器界面皮肤上HTML 页面抄了一个特别炫酷的网易云风格结果一问播放进度条用的什么协议答不上来一问聊天消息怎么从一台机器推到另外一台机器的浏览器答不上来。这种“皮厚瓤空”的毕设中期检查就会被批成筛子。所以我定的核心设计原则是功能和交互未必多花哨但每个模块的深度要足够答辩。音乐存储用本地文件但保留换对象存储的接口聊天室用 WebSocket不用轮询这种糊弄人的方案播放量统计用数据库原子更新配合 Redis 缓存不写一个裸的count。这些都是有真实工程价值的取舍。1.2 功能模块划分与耦合方式系统按用户的动作路径拆成四个大模块模块核心功能技术重点用户中心注册、登录、个人主页JWT 令牌密码加盐哈希音乐管理上传、列表、搜索、播放FFmpeg 处理音频Range 流式响应互动中心收藏、评论、点赞、播放量异步计数唯一索引防重复聊天室公共房间、消息实时收发WebSocket 全双工通信模块之间不是完全独立的。“播放”这个动作会触发“播放量 1”聊天室里的热门歌曲可以链接回“播放页”用户收藏的歌曲会在个人中心聚合。我在设计时就刻意避免了循环依赖比如播放量计数不直接写在播放接口里而是发送一个异步事件由独立的统计服务消费。这个点答辩时特别能体现你对“低耦合”的理解。1.3 技术选型为什么这么定后端用的是Spring Boot 2.7 MyBatis MySQL 8.0这是目前校园里最不冒险、也最能说清的一组合Spring Boot约定优于配置能快速把 Web 服务、静态资源、数据源全拉起来MyBatisSQL 可控写复杂联表和统计查询比 JPA 直白答辩时手写 SQL 也更有说服力WebSocket聊天室这种高频双向通信场景如果用 HTTP 轮询会给服务器压力还不实时WebSocket 一次握手、持续推送是行业标准做法FFmpeg用于处理上传的音频提取时长、转码成统一格式、生成波形或封面信息。很多同学不知道这个工具但其实它是多媒体项目的“隐藏功臣”。前端我没有引入太重的框架用原生 JavaScript HTML5 的audio标签搭配简单的 Vue 风格模板渲染。这样既不会让毕业论文里多出一堆难以解释的陌生名词又能把后端能力展示得明明白白。如果你想吹得再高一点把 Vue3 集成进来完全没问题但后端才是毕设的命根子。2. 数据库设计与核心模型2.1 表结构怎么设计才不臃肿我总共建了 6 张核心表外加一张聊天记录表。很多同学喜欢把所有信息塞进一张大表后面查询必然炸。我这边直接给出实际可用的建表核心结构CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password CHAR(64) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE song ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, singer VARCHAR(100), cover_path VARCHAR(255), file_path VARCHAR(255) NOT NULL, duration INT DEFAULT 0, -- 秒 play_count BIGINT DEFAULT 0, upload_user_id BIGINT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE favorite ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, song_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_song (user_id, song_id) ); CREATE TABLE comment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, song_id BIGINT NOT NULL, user_id BIGINT NOT NULL, content VARCHAR(500), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE chat_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id VARCHAR(50) DEFAULT default, user_id BIGINT NOT NULL, content VARCHAR(500), created_at DATETIME DEFAULT CURRENT_TIMESTAMP );要注意几个关键点favorite表必须加UNIQUE(user_id, song_id)这样用户对同一首歌点两次收藏第二次会报错或命中重复索引你只需要在代码里捕获DuplicateKeyException转成“已收藏”的友好提示这是防重复点赞、收藏最干净的方案duration字段存的是秒不存格式化字符串。前端播放器拿到秒数后自己转mm:ss格式化逻辑放前端比放后端更合理password存的是加盐后的 SHA-256别存明文。这个没得商量。2.2 播放量统计与数据一致性播放量很容易出现并发问题。比如 100 人同时点播放如果代码写的是song.setPlayCount(song.getPlayCount() 1)然后updateById脏读几乎必然发生。我在项目里用了一层 Redis 做缓冲public void incrementPlayCount(Long songId) { // 先写入 Redis 的 Hash 结构 String key song:play: songId; redisTemplate.opsForValue().increment(key); // 每 5 秒由定时任务批量刷进 MySQL }定时任务用 Spring 自带的Scheduled每 5 秒把 Redis 里的增量合并进数据库Scheduled(fixedDelay 5000) public void flushPlayCount() { SetString keys redisTemplate.keys(song:play:*); for (String key : keys) { Long songId Long.parseLong(key.substring(song:play:.length())); Integer delta Integer.parseInt(redisTemplate.opsForValue().get(key).toString()); songMapper.increasePlayCount(songId, delta); redisTemplate.delete(key); } }这样既扛住了高峰值又不至于让 MySQL 每秒钟面对几百次写请求。答辩时如果被问“数据库和缓存如何保证一致性”你就说“允许短窗口内播放量轻微不准确但最终会通过定时任务保持一致”这个权衡本身就是加分项。3. 核心细节解析与实操要点3.1 歌曲上传与 FFmpeg 元数据提取音乐上传不能只做一个MultipartFile直接存。用户传一个 100MB 的无损音频你的网页谁能直接放所以上传环节要做两件事存原文件和生成服务器可播放的副本。我这里的做法是接收文件后先用 UUID 重命名存入服务器临时目录然后调用 FFmpeg 转成 320kbps 的 MP3 文件放在song文件夹下同时截取默认封面ffmpeg -i input.flac -b:a 320k output.mp3 -y ffmpeg -i output.mp3 -vf scale300:300 cover.jpg -y然后在 Java 里用ProcessBuilder调用 FFmpeg读取输出信息里的时间长度ProcessBuilder pb new ProcessBuilder(ffprobe, -v, error, -show_entries, formatduration, -of, defaultnoprint_wrappers1:nokey1, outputFilePath); Process process pb.start(); BufferedReader reader new BufferedReader(new InputStreamReader(process.getInputStream())); double seconds Double.parseDouble(reader.readLine()); int duration (int) Math.ceil(seconds);这里有一个坑一定要先拿到 FFmpeg 的安装路径确保它已经出现在环境变量里否则ProcessBuilder会抛IOException。而且 FFmpeg 处理大文件时会卡几十秒前端必须用异步请求别让上传按钮一直转圈。我前端用的是XMLHttpRequest监听upload.onprogress显示进度条后端接口返回一个任务 ID前端再轮询“任务状态接口”。3.2 流式播放、Range 请求与播放进度HTML5 的audio标签在播放网络音频时浏览器会自动分块拉取数据。你如果接口返回的是整个文件用户拖进度条时服务器会重新发送整个文件流量浪费到崩溃。正确姿势是支持 HTTP 的Range头。Spring Boot 里我写了一个下载接口核心逻辑如下GetMapping(/play/{songId}) public ResponseEntityResource play(PathVariable Long songId, RequestHeader(value Range, required false) String range) throws IOException { Song song songService.getById(songId); File file new File(song.getFilePath()); long start 0, end file.length() - 1; if (range ! null range.startsWith(bytes)) { String[] parts range.substring(6).split(-); start Long.parseLong(parts[0]); if (parts.length 1) { end Long.parseLong(parts[1]); } } // 构造分块响应 }配合HttpServletResponse直接写流设置Content-Range和Content-Length状态码设 206。这里最容易出错的是end不能超过文件长度否则浏览器会认为资源损坏。我当时为了验证这个故意把文件长度算错结果 Chrome 控制台报了一个MEDIA_ELEMENT_ERROR排查了一下午才发现是Range的 end 越界了。3.3 聊天室 WebSocket 通信与心跳聊天室用 WebSocket 并不是配置好一个端点就完事。要考虑的问题包括谁在房间里、消息要不要入库、连不上怎么办。我后端用的是 Spring 的WebSocketHandler自定义一个ChatWebSocketHandler维护一个静态的ConcurrentHashMapString, WebSocketSessionkey 是 session idvalue 是 session。用户进入房间后广播一条“XX 进入了聊天室”发言时把消息内容做一次过滤然后写入 MySQL再广播给所有人。Override public void handleMessage(WebSocketSession session, WebSocketMessage? message) { String payload (String) message.getPayload(); JSONObject json JSONObject.parseObject(payload); String type json.getString(type); if (chat.equals(type)) { String content filterSensitiveWord(json.getString(content)); ChatMessage msg new ChatMessage(); msg.setUserId(json.getLong(userId)); msg.setContent(content); chatMessageMapper.insert(msg); // 广播 sendToAll(msg); } }这里的敏感词过滤我用了一个简单的前缀树Trie把常见的敏感词汇表加载进内存命中后替换为*。答辩时不用展开到“深度学习审核”只要说“基于前缀树实现 O(n) 级别匹配比循环 list 高效”就够亮眼了。前端要维护心跳。WebSocket 有时会被路由器或 Docker 内网代理静默断开但前端感知不到。我每隔 30 秒发一个{type:ping}后端回{type:pong}。如果 60 秒没收到 pong就重连。这个细节放在论文里可以单独写一小节非常实用。3.4 点赞、收藏、评论的防重与防刷互动功能看着简单实际最考验细节。点赞不能无限点收藏不能重复评论不能为空也不能超过 500 字。我的统一做法是点赞记录表加唯一索引第二次点击时判断已有记录则执行删除实现“取消点赞”评论接口做参数校验content为空直接返回 400但注意前端也要同步限制因为接口可以被 POST 直接调用为了防止刷播放量同一个sessionId对同一首歌 10 分钟内只能计入一次播放量。这块我在 Redis 里用SETNX一个song:once:{sessionId}:{songId}过期时间 10 分钟。虽然用户换浏览器可以绕过但这个量级的防刷在毕设项目中完全够用。4. 实操过程与核心环节实现4.1 列表接口与前端渲染前端页面我做了两个核心页面发现页和聊天室。发现页展示歌曲卡片带播放按钮、收藏按钮、评论按钮。列表接口是后端写的GetMapping(/song/list) public Result list(int page, int size) { ListSongVO list songMapper.selectPage((page - 1) * size, size); return Result.success(list); }这里别用LIMIT 1000000 OFFSET这种写法顶多演示页够用实际页深了会出现巨大的性能回落。我在项目中用PageHelper插件写起来是PageHelper.startPage(page, size)逻辑清晰。前端渲染时我用audio :srcplayUrl控制播放拿到songId后拼接http://ip:8080/api/play/{id}。这里有个大坑如果把本地服务器地址写死成localhost教师评审时用的电脑连的是你电脑的 IP音频根本无法播放。我建议动态获取当前域名拼上/api/play/const baseUrl window.location.origin; audio.src baseUrl /api/play/ songId;4.2 聊天消息收发与滚动展示聊天室页面的消息列表是一个纵向容器新消息到来时往底部插入然后scrollTop scrollHeight保持显示最新。这个问题很小但很多同学忘记做导致消息一多就看不到最新条。前端 WebSocket 连接代码const ws new WebSocket(ws:// window.location.host /ws/chat); ws.onmessage function(event) { const msg JSON.parse(event.data); if (msg.type chat) { addMessage(msg.userName, msg.content); } };注意ws 协议和 http 协议不要写混。如果网页是https你要用wss否则浏览器会阻止陌生连接。我当时部署到云服务器上忘改这个F12 看到 WebSocket 一直 failed。后端handleTextMessage收到消息后把用户信息塞进 session attributes 里。每个 session 一连接就在 map 里按房间分组这样每个房间互不干扰。如果想做私聊再存一份roomId - userId - session的映射。4.3 登录状态与跨域问题前端和后端如果分开跑在两个端口比如前端 8081后端 8080就必须处理跨域。我后端加了一个全局配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true); } }但毕业设计如果直接用 Spring Boot 同时托管静态页面和后端接口就不存在跨域问题还能少一个坑。我推荐把打出的 Vue 构建产物或 HTML 丢到src/main/resources/static下这样一个 Tomcat 端口全搞定。注意allowCredentials与*共存会有浏览器兼容问题所以用了allowedOriginPatterns(*)。登录接口用 JWT 返回令牌前端存到localStorage每次请求都放到Authorization头。WebSocket 握手时也要带这个令牌不然谁都能匿名登进聊天室。握手拦截器里从Sec-WebSocket-Protocol或者 query 里取token验证不通过直接返回 false。这块能从“能跑”提升到“有安全设计”。5. 部署、演示与常见问题排查5.1 本地打包流程后端用 Maven 打包我习惯直接打成一个可执行 jarmvn clean package -DskipTests java -jar music-platform.jar --server.port8080还要配置外部化的文件路径。我不建议把上传的歌曲存到 jar 包内不然每次重启都会丢。配置文件里设置music.upload-dir/data/music动态读取Value(${music.upload-dir}) private String uploadDir;本地演示时如果老师电脑在同一个局域网你用电脑 IP 加上 8080 端口访问即可。如果不在同一个局域网可以用内网穿透工具打一个临时域名方便远程评审。但内网穿透延迟较高用于演示还是可以接受的。5.2 常见问题速查表现象原因解决办法点击播放没声音Network 提示406 Not Acceptable返回的音频没有设置正确的Content-Type设置response.setContentType(audio/mpeg)上传大文件转码卡死后端请求体大小默认 1MB在application.yml中设置spring.servlet.multipart.max-file-size: 200MB播放到一半断了Range 的 end 越界或响应长度不对用file.length()-1作为默认 end并校验 end 不能大于文件长度WebSocket 连接成功但收不到消息前后端消息 JSON 字段名不一致用JSONObject.parseObject解析前后端字段名统一为小写驼峰聊天室消息乱码Tomcat 和 MySQL 编码不是 UTF-8连接字符串加?useUnicodetruecharacterEncodingutf8service.xml 里设置 URIEncodingUTF-8重启应用后上传的文件消失文件存在默认临时目录把上传目录改成磁盘持久目录别用System.getProperty(java.io.tmpdir)5.3 我在实际项目中踩过的坑第一个坑是FFmpeg 的转码进度阻塞了请求线程。我用同步调用导致 100MB 音频上传后浏览器卡了 40 秒才返回。后来改成多线程上传接口立刻返回任务 ID后台线程异步转码前端轮询任务状态用户看到“转码中请稍候”。这个体验提升极其显著。第二个坑是MySQL 时间字段和数据类型的类型不匹配。created_at我用了DATETIME但在 Java 里映射成LocalDateTime时 MyBatis 一直报内部异常折腾了很久才发现是 JDBC 驱动版本与 MySQL 8 认证协议不对换成最新mysql-connector-j就正常了。建议一开始就把驱动版本和数据库版本对应关系查清楚别拿 5.x 驱动去连 MySQL 8。第三个坑是WebSocket 消息不能直接向已关闭的 session 发送。广播前判断session.isOpen()否则会抛出IllegalStateException。我的sendToAll方法里会先遍历复制一个快照再逐个尝试发送失败就移除 session。这个就是生产环境要有的“容错逃逸”答辩可以重点讲。第四个坑是上传文件名不能用中文。中文文件名在不同系统的编码规则不一致很容易出现文件存到服务器上但读取不到的情况。我统一用 UUID 重命名再把原始文件名写进数据库的title字段。这样既解决了存储安全问题也避免了下载时文件名不正确的怪问题。6. 答辩亮点与后续扩展建议6.1 三个能打动老师的点第一播放量统计的异步刷盘。直接从“同步写入数据库”改成“Redis 计数 定时批量刷库”体现了缓存性能和可靠性的平衡。老师问到“丢了怎么办”你可以答“允许小概率丢失非关键数据可容忍关键数据可加 MQ 保证最终一致”。第二Range 流式播放支持拖动进度条。这个比很多同学直接下载整个文件再播放高级得多。你可以现场演示播放到一半随意拖动看后台日志显示206 Partial Content说明请求被正确拆分为多个分块。第三WebSocket 心跳与断线重连。聊天室不是建个连接就完事还处理了网络间断问题。连着手机热点来回切聊天室依然能自动恢复。这个细节能让评委产生“这个学生是从工程里走出来的”感觉。6.2 还能往上加什么功能如果时间充裕还可以加三个有意思的扩展方向歌词滚动歌词按时间戳切分播放器通过timeupdate事件计算当前到第几句实现卡拉 OK 效果热门榜单根据播放量前 10 生成榜单SQL 用ORDER BY play_count DESC LIMIT 10再配合 Redis 缓存 30 秒减少数据库压力二次筛选搜索接口加 Tag 分类古风、纯音乐、电子用WHERE column LIKE或者 MyBatis 的foreach动态拼接条件能充分展示你的动态 SQL 能力。我手里另外一个学生就是把歌词和热门榜单做进去答辩时老师对他印象很深因为这两个功能直接把作品从“也是网上模板”升级成了“有自己思考的完整产品”。最后想说的是毕业设计系统不是越复杂越好而是每一个功能点都要能回答“为什么这么做”。你如果能把Range请求、WebSocket 心跳、缓存与数据库的一致性这几件事讲透哪怕界面朴素一点分数都不会低。这一路踩坑的意义也正在于此——你可以照着文档做出来一次但真正知道为什么会有这么多坑是下一份工作在等你。
做毕业设计这几年“音乐畅听系统”这个题目几乎每年都有人选但绝大多数人做出来只是个“换皮播放器”——能放歌、能搜索、能注册登录然后就没有然后了。真正拉开差距的是你有没有把“智能音乐播放与互动平台”这个副标题里的水做出来文件能不能断点续传聊天室能不能扛住几十人同时发言点赞和播放量在并发下会不会乱掉这些才是老师答辩时盯着问的点也是你写在简历上能站住脚的东西。这篇就把我这套Java音乐畅听系统的完整设计思路、表结构、核心代码和踩坑过程拆开讲透适合正在做毕业设计、或者想拿一个完整Java Web项目去面试的人参考。1. 项目整体设计与思路拆解1.1 从题目看真正的需求标题一共给了三个关键词Java、音乐畅听系统、线上音乐分享与聊天室系统。拆开看它其实要求的是这样一个东西一个 B/C 架构的 Web 应用后端用 Java 生态必须有音乐上传、播放、搜索、收藏等常规功能这是“畅听”的底座必须有用户互动能力比如实时聊天室这是“互动平台”的加分项整体要像一个“线上下载/分享平台”而不是一个本地播放器。很多同学一开始把精力花在播放器界面皮肤上HTML 页面抄了一个特别炫酷的网易云风格结果一问播放进度条用的什么协议答不上来一问聊天消息怎么从一台机器推到另外一台机器的浏览器答不上来。这种“皮厚瓤空”的毕设中期检查就会被批成筛子。所以我定的核心设计原则是功能和交互未必多花哨但每个模块的深度要足够答辩。音乐存储用本地文件但保留换对象存储的接口聊天室用 WebSocket不用轮询这种糊弄人的方案播放量统计用数据库原子更新配合 Redis 缓存不写一个裸的count。这些都是有真实工程价值的取舍。1.2 功能模块划分与耦合方式系统按用户的动作路径拆成四个大模块模块核心功能技术重点用户中心注册、登录、个人主页JWT 令牌密码加盐哈希音乐管理上传、列表、搜索、播放FFmpeg 处理音频Range 流式响应互动中心收藏、评论、点赞、播放量异步计数唯一索引防重复聊天室公共房间、消息实时收发WebSocket 全双工通信模块之间不是完全独立的。“播放”这个动作会触发“播放量 1”聊天室里的热门歌曲可以链接回“播放页”用户收藏的歌曲会在个人中心聚合。我在设计时就刻意避免了循环依赖比如播放量计数不直接写在播放接口里而是发送一个异步事件由独立的统计服务消费。这个点答辩时特别能体现你对“低耦合”的理解。1.3 技术选型为什么这么定后端用的是Spring Boot 2.7 MyBatis MySQL 8.0这是目前校园里最不冒险、也最能说清的一组合Spring Boot约定优于配置能快速把 Web 服务、静态资源、数据源全拉起来MyBatisSQL 可控写复杂联表和统计查询比 JPA 直白答辩时手写 SQL 也更有说服力WebSocket聊天室这种高频双向通信场景如果用 HTTP 轮询会给服务器压力还不实时WebSocket 一次握手、持续推送是行业标准做法FFmpeg用于处理上传的音频提取时长、转码成统一格式、生成波形或封面信息。很多同学不知道这个工具但其实它是多媒体项目的“隐藏功臣”。前端我没有引入太重的框架用原生 JavaScript HTML5 的audio标签搭配简单的 Vue 风格模板渲染。这样既不会让毕业论文里多出一堆难以解释的陌生名词又能把后端能力展示得明明白白。如果你想吹得再高一点把 Vue3 集成进来完全没问题但后端才是毕设的命根子。2. 数据库设计与核心模型2.1 表结构怎么设计才不臃肿我总共建了 6 张核心表外加一张聊天记录表。很多同学喜欢把所有信息塞进一张大表后面查询必然炸。我这边直接给出实际可用的建表核心结构CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password CHAR(64) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE song ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, singer VARCHAR(100), cover_path VARCHAR(255), file_path VARCHAR(255) NOT NULL, duration INT DEFAULT 0, -- 秒 play_count BIGINT DEFAULT 0, upload_user_id BIGINT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE favorite ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, song_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_song (user_id, song_id) ); CREATE TABLE comment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, song_id BIGINT NOT NULL, user_id BIGINT NOT NULL, content VARCHAR(500), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE chat_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id VARCHAR(50) DEFAULT default, user_id BIGINT NOT NULL, content VARCHAR(500), created_at DATETIME DEFAULT CURRENT_TIMESTAMP );要注意几个关键点favorite表必须加UNIQUE(user_id, song_id)这样用户对同一首歌点两次收藏第二次会报错或命中重复索引你只需要在代码里捕获DuplicateKeyException转成“已收藏”的友好提示这是防重复点赞、收藏最干净的方案duration字段存的是秒不存格式化字符串。前端播放器拿到秒数后自己转mm:ss格式化逻辑放前端比放后端更合理password存的是加盐后的 SHA-256别存明文。这个没得商量。2.2 播放量统计与数据一致性播放量很容易出现并发问题。比如 100 人同时点播放如果代码写的是song.setPlayCount(song.getPlayCount() 1)然后updateById脏读几乎必然发生。我在项目里用了一层 Redis 做缓冲public void incrementPlayCount(Long songId) { // 先写入 Redis 的 Hash 结构 String key song:play: songId; redisTemplate.opsForValue().increment(key); // 每 5 秒由定时任务批量刷进 MySQL }定时任务用 Spring 自带的Scheduled每 5 秒把 Redis 里的增量合并进数据库Scheduled(fixedDelay 5000) public void flushPlayCount() { SetString keys redisTemplate.keys(song:play:*); for (String key : keys) { Long songId Long.parseLong(key.substring(song:play:.length())); Integer delta Integer.parseInt(redisTemplate.opsForValue().get(key).toString()); songMapper.increasePlayCount(songId, delta); redisTemplate.delete(key); } }这样既扛住了高峰值又不至于让 MySQL 每秒钟面对几百次写请求。答辩时如果被问“数据库和缓存如何保证一致性”你就说“允许短窗口内播放量轻微不准确但最终会通过定时任务保持一致”这个权衡本身就是加分项。3. 核心细节解析与实操要点3.1 歌曲上传与 FFmpeg 元数据提取音乐上传不能只做一个MultipartFile直接存。用户传一个 100MB 的无损音频你的网页谁能直接放所以上传环节要做两件事存原文件和生成服务器可播放的副本。我这里的做法是接收文件后先用 UUID 重命名存入服务器临时目录然后调用 FFmpeg 转成 320kbps 的 MP3 文件放在song文件夹下同时截取默认封面ffmpeg -i input.flac -b:a 320k output.mp3 -y ffmpeg -i output.mp3 -vf scale300:300 cover.jpg -y然后在 Java 里用ProcessBuilder调用 FFmpeg读取输出信息里的时间长度ProcessBuilder pb new ProcessBuilder(ffprobe, -v, error, -show_entries, formatduration, -of, defaultnoprint_wrappers1:nokey1, outputFilePath); Process process pb.start(); BufferedReader reader new BufferedReader(new InputStreamReader(process.getInputStream())); double seconds Double.parseDouble(reader.readLine()); int duration (int) Math.ceil(seconds);这里有一个坑一定要先拿到 FFmpeg 的安装路径确保它已经出现在环境变量里否则ProcessBuilder会抛IOException。而且 FFmpeg 处理大文件时会卡几十秒前端必须用异步请求别让上传按钮一直转圈。我前端用的是XMLHttpRequest监听upload.onprogress显示进度条后端接口返回一个任务 ID前端再轮询“任务状态接口”。3.2 流式播放、Range 请求与播放进度HTML5 的audio标签在播放网络音频时浏览器会自动分块拉取数据。你如果接口返回的是整个文件用户拖进度条时服务器会重新发送整个文件流量浪费到崩溃。正确姿势是支持 HTTP 的Range头。Spring Boot 里我写了一个下载接口核心逻辑如下GetMapping(/play/{songId}) public ResponseEntityResource play(PathVariable Long songId, RequestHeader(value Range, required false) String range) throws IOException { Song song songService.getById(songId); File file new File(song.getFilePath()); long start 0, end file.length() - 1; if (range ! null range.startsWith(bytes)) { String[] parts range.substring(6).split(-); start Long.parseLong(parts[0]); if (parts.length 1) { end Long.parseLong(parts[1]); } } // 构造分块响应 }配合HttpServletResponse直接写流设置Content-Range和Content-Length状态码设 206。这里最容易出错的是end不能超过文件长度否则浏览器会认为资源损坏。我当时为了验证这个故意把文件长度算错结果 Chrome 控制台报了一个MEDIA_ELEMENT_ERROR排查了一下午才发现是Range的 end 越界了。3.3 聊天室 WebSocket 通信与心跳聊天室用 WebSocket 并不是配置好一个端点就完事。要考虑的问题包括谁在房间里、消息要不要入库、连不上怎么办。我后端用的是 Spring 的WebSocketHandler自定义一个ChatWebSocketHandler维护一个静态的ConcurrentHashMapString, WebSocketSessionkey 是 session idvalue 是 session。用户进入房间后广播一条“XX 进入了聊天室”发言时把消息内容做一次过滤然后写入 MySQL再广播给所有人。Override public void handleMessage(WebSocketSession session, WebSocketMessage? message) { String payload (String) message.getPayload(); JSONObject json JSONObject.parseObject(payload); String type json.getString(type); if (chat.equals(type)) { String content filterSensitiveWord(json.getString(content)); ChatMessage msg new ChatMessage(); msg.setUserId(json.getLong(userId)); msg.setContent(content); chatMessageMapper.insert(msg); // 广播 sendToAll(msg); } }这里的敏感词过滤我用了一个简单的前缀树Trie把常见的敏感词汇表加载进内存命中后替换为*。答辩时不用展开到“深度学习审核”只要说“基于前缀树实现 O(n) 级别匹配比循环 list 高效”就够亮眼了。前端要维护心跳。WebSocket 有时会被路由器或 Docker 内网代理静默断开但前端感知不到。我每隔 30 秒发一个{type:ping}后端回{type:pong}。如果 60 秒没收到 pong就重连。这个细节放在论文里可以单独写一小节非常实用。3.4 点赞、收藏、评论的防重与防刷互动功能看着简单实际最考验细节。点赞不能无限点收藏不能重复评论不能为空也不能超过 500 字。我的统一做法是点赞记录表加唯一索引第二次点击时判断已有记录则执行删除实现“取消点赞”评论接口做参数校验content为空直接返回 400但注意前端也要同步限制因为接口可以被 POST 直接调用为了防止刷播放量同一个sessionId对同一首歌 10 分钟内只能计入一次播放量。这块我在 Redis 里用SETNX一个song:once:{sessionId}:{songId}过期时间 10 分钟。虽然用户换浏览器可以绕过但这个量级的防刷在毕设项目中完全够用。4. 实操过程与核心环节实现4.1 列表接口与前端渲染前端页面我做了两个核心页面发现页和聊天室。发现页展示歌曲卡片带播放按钮、收藏按钮、评论按钮。列表接口是后端写的GetMapping(/song/list) public Result list(int page, int size) { ListSongVO list songMapper.selectPage((page - 1) * size, size); return Result.success(list); }这里别用LIMIT 1000000 OFFSET这种写法顶多演示页够用实际页深了会出现巨大的性能回落。我在项目中用PageHelper插件写起来是PageHelper.startPage(page, size)逻辑清晰。前端渲染时我用audio :srcplayUrl控制播放拿到songId后拼接http://ip:8080/api/play/{id}。这里有个大坑如果把本地服务器地址写死成localhost教师评审时用的电脑连的是你电脑的 IP音频根本无法播放。我建议动态获取当前域名拼上/api/play/const baseUrl window.location.origin; audio.src baseUrl /api/play/ songId;4.2 聊天消息收发与滚动展示聊天室页面的消息列表是一个纵向容器新消息到来时往底部插入然后scrollTop scrollHeight保持显示最新。这个问题很小但很多同学忘记做导致消息一多就看不到最新条。前端 WebSocket 连接代码const ws new WebSocket(ws:// window.location.host /ws/chat); ws.onmessage function(event) { const msg JSON.parse(event.data); if (msg.type chat) { addMessage(msg.userName, msg.content); } };注意ws 协议和 http 协议不要写混。如果网页是https你要用wss否则浏览器会阻止陌生连接。我当时部署到云服务器上忘改这个F12 看到 WebSocket 一直 failed。后端handleTextMessage收到消息后把用户信息塞进 session attributes 里。每个 session 一连接就在 map 里按房间分组这样每个房间互不干扰。如果想做私聊再存一份roomId - userId - session的映射。4.3 登录状态与跨域问题前端和后端如果分开跑在两个端口比如前端 8081后端 8080就必须处理跨域。我后端加了一个全局配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true); } }但毕业设计如果直接用 Spring Boot 同时托管静态页面和后端接口就不存在跨域问题还能少一个坑。我推荐把打出的 Vue 构建产物或 HTML 丢到src/main/resources/static下这样一个 Tomcat 端口全搞定。注意allowCredentials与*共存会有浏览器兼容问题所以用了allowedOriginPatterns(*)。登录接口用 JWT 返回令牌前端存到localStorage每次请求都放到Authorization头。WebSocket 握手时也要带这个令牌不然谁都能匿名登进聊天室。握手拦截器里从Sec-WebSocket-Protocol或者 query 里取token验证不通过直接返回 false。这块能从“能跑”提升到“有安全设计”。5. 部署、演示与常见问题排查5.1 本地打包流程后端用 Maven 打包我习惯直接打成一个可执行 jarmvn clean package -DskipTests java -jar music-platform.jar --server.port8080还要配置外部化的文件路径。我不建议把上传的歌曲存到 jar 包内不然每次重启都会丢。配置文件里设置music.upload-dir/data/music动态读取Value(${music.upload-dir}) private String uploadDir;本地演示时如果老师电脑在同一个局域网你用电脑 IP 加上 8080 端口访问即可。如果不在同一个局域网可以用内网穿透工具打一个临时域名方便远程评审。但内网穿透延迟较高用于演示还是可以接受的。5.2 常见问题速查表现象原因解决办法点击播放没声音Network 提示406 Not Acceptable返回的音频没有设置正确的Content-Type设置response.setContentType(audio/mpeg)上传大文件转码卡死后端请求体大小默认 1MB在application.yml中设置spring.servlet.multipart.max-file-size: 200MB播放到一半断了Range 的 end 越界或响应长度不对用file.length()-1作为默认 end并校验 end 不能大于文件长度WebSocket 连接成功但收不到消息前后端消息 JSON 字段名不一致用JSONObject.parseObject解析前后端字段名统一为小写驼峰聊天室消息乱码Tomcat 和 MySQL 编码不是 UTF-8连接字符串加?useUnicodetruecharacterEncodingutf8service.xml 里设置 URIEncodingUTF-8重启应用后上传的文件消失文件存在默认临时目录把上传目录改成磁盘持久目录别用System.getProperty(java.io.tmpdir)5.3 我在实际项目中踩过的坑第一个坑是FFmpeg 的转码进度阻塞了请求线程。我用同步调用导致 100MB 音频上传后浏览器卡了 40 秒才返回。后来改成多线程上传接口立刻返回任务 ID后台线程异步转码前端轮询任务状态用户看到“转码中请稍候”。这个体验提升极其显著。第二个坑是MySQL 时间字段和数据类型的类型不匹配。created_at我用了DATETIME但在 Java 里映射成LocalDateTime时 MyBatis 一直报内部异常折腾了很久才发现是 JDBC 驱动版本与 MySQL 8 认证协议不对换成最新mysql-connector-j就正常了。建议一开始就把驱动版本和数据库版本对应关系查清楚别拿 5.x 驱动去连 MySQL 8。第三个坑是WebSocket 消息不能直接向已关闭的 session 发送。广播前判断session.isOpen()否则会抛出IllegalStateException。我的sendToAll方法里会先遍历复制一个快照再逐个尝试发送失败就移除 session。这个就是生产环境要有的“容错逃逸”答辩可以重点讲。第四个坑是上传文件名不能用中文。中文文件名在不同系统的编码规则不一致很容易出现文件存到服务器上但读取不到的情况。我统一用 UUID 重命名再把原始文件名写进数据库的title字段。这样既解决了存储安全问题也避免了下载时文件名不正确的怪问题。6. 答辩亮点与后续扩展建议6.1 三个能打动老师的点第一播放量统计的异步刷盘。直接从“同步写入数据库”改成“Redis 计数 定时批量刷库”体现了缓存性能和可靠性的平衡。老师问到“丢了怎么办”你可以答“允许小概率丢失非关键数据可容忍关键数据可加 MQ 保证最终一致”。第二Range 流式播放支持拖动进度条。这个比很多同学直接下载整个文件再播放高级得多。你可以现场演示播放到一半随意拖动看后台日志显示206 Partial Content说明请求被正确拆分为多个分块。第三WebSocket 心跳与断线重连。聊天室不是建个连接就完事还处理了网络间断问题。连着手机热点来回切聊天室依然能自动恢复。这个细节能让评委产生“这个学生是从工程里走出来的”感觉。6.2 还能往上加什么功能如果时间充裕还可以加三个有意思的扩展方向歌词滚动歌词按时间戳切分播放器通过timeupdate事件计算当前到第几句实现卡拉 OK 效果热门榜单根据播放量前 10 生成榜单SQL 用ORDER BY play_count DESC LIMIT 10再配合 Redis 缓存 30 秒减少数据库压力二次筛选搜索接口加 Tag 分类古风、纯音乐、电子用WHERE column LIKE或者 MyBatis 的foreach动态拼接条件能充分展示你的动态 SQL 能力。我手里另外一个学生就是把歌词和热门榜单做进去答辩时老师对他印象很深因为这两个功能直接把作品从“也是网上模板”升级成了“有自己思考的完整产品”。最后想说的是毕业设计系统不是越复杂越好而是每一个功能点都要能回答“为什么这么做”。你如果能把Range请求、WebSocket 心跳、缓存与数据库的一致性这几件事讲透哪怕界面朴素一点分数都不会低。这一路踩坑的意义也正在于此——你可以照着文档做出来一次但真正知道为什么会有这么多坑是下一份工作在等你。
