SpringBoot在线音乐播放系统：从数据库设计到文件上传实战-北京尧图网络

1. 这个毕设到底在做什么先说结论这是一个基于 SpringBoot 的在线音乐播放系统主要面向计算机相关专业的毕业设计场景但绝不是那种“交差就行”的玩具项目。它的功能完整度、代码规范性和可扩展性完全可以作为求职简历上的项目经验来写。我见过太多毕设选题踩坑的案例要么选了个过于冷门的技术栈答辩时老师一问三不知要么选了个满大街都是的 CRUD毫无亮点。这个项目比较聪明的地方在于它踩在了“音乐播放”这个大众都熟悉、但技术上又有一定门槛的点上——用户能听懂、老师能看懂、你也能讲清楚。从功能角度看一个合格的在线音乐播放系统至少要覆盖三端能力用户端负责注册登录、浏览歌单、搜索歌曲、在线播放、收藏歌曲管理端负责歌曲上传、歌手管理、专辑归类、用户状态管理系统层还要处理音频文件的存储、流式加载、播放次数统计这类偏后端的逻辑。很多人以为“播放音乐”就是把audio标签塞到页面上其实放到后端工程里事情就复杂多了。音频文件怎么存播放请求怎么响应分页怎么做歌单和歌曲的关系表怎么设计这些都是要落地的真问题。这篇博文我会把我实际做这类项目的完整思路、表结构设计、核心接口实现、以及那些在文档里找不到的坑全部梳理出来希望能给正在做类似毕设或者想用 SpringBoot 练手的朋友一个可以作为参考的完整路径。这个系统适合谁如果你是 SpringBoot 刚入门、想通过一个完整项目把框架串起来的学生它会是一个很好的实战载体。如果你已经在做这个选题、卡在某个功能上那直接翻到后面的排查章节就行。如果你只是单纯想看看一个完整的后台管理系统该怎么搭它同样有价值。2. 技术选型为什么是 SpringBoot而不是别的2.1 生态成熟度决定开发效率选 SpringBoot 不是因为“大家都在用所以我也用”而是它在做这种业务系统时确实有不可替代的优势。先看基础架构。一个在线音乐系统本质是“内容管理内容展示多媒体处理”的复合体。SpringBoot 提供了非常完整的 Web 开发能力内置 Tomcat一个可执行的 jar 包就能跑起来这对毕设场景来说太重要了——你不用像以前用 SSM 那样折腾一堆 XML 配置也不用像用 Node.js 那样需要额外选择合适的框架组合。我个人的体会是SpringBoot 最核心的价值在于它的自动配置机制。你做用户管理Spring Data JPA 或 MyBatis-Plus 可以帮你省掉大量重复的 DAO 代码你做参数校验Validation 注解直接标在实体类上你做统一异常处理RestControllerAdvice一个类解决。这些东西叠加起来一个单机版在线音乐系统核心代码量可以控制得很精简而且每一条代码逻辑你都能看懂、都能在答辩时讲清楚。2.2 数据库设计与 ORM 的配合这个系统我用的是 MySQL 8.0持久层框架选的 MyBatis-Plus。为什么不用 JPA不是 JPA 不好而是对于毕设场景MyBatis-Plus 的代码直观性更强。JPA 的懒加载、级联操作、Session 管理这些概念对新手来说理解成本偏高。而 MyBatis-Plus 你就把它当成“增强版 MyBatis”SQL 该怎么写还是怎么写它只是帮你把单表 CRUD、分页、条件构造这些重复劳动省掉。尤其分页这个场景MyBatis-Plus 的Page对象配合selectPage方法两行代码就能搞定分页查询而传统 MyBatis 你得手写LIMIT #{offset}, #{pageSize}还得自己算总数。做毕设时时间本来就紧能少写就少写。2.3 前端方案的取舍前端我用的方案是 Thymeleaf 模板引擎加 Bootstrap 框架配合少量原生 JavaScript 和 HTML5 Audio 组件。这个选择也是反复权衡后的结果。有一种思路是做前后端分离Vue SpringBoot 纯接口模式。这在生产环境中是大势所趋但在毕设场景下我要给一个明确的建议如果你的时间预算不超过三周不要碰前后端分离。原因很简单前后端分离意味着你要同时调通两套工程、处理跨域、管理 Token 认证、还要写接口文档任何一个环节出问题都会拖慢你的进度。Thymeleaf 方案下页面和后端在同一个工程里用户点击播放按钮JavaScript 直接拿音频 URL 丢给 Audio 对象播放不需要考虑跨域问题代码逻辑链路短非常容易调试。而且答辩时老师问起来你可以说“我用了模板引擎渲染页面保证了首屏加载速度同时保留了后续扩展为前后端分离架构的空间”——这句话在答辩时是有分量的。3. 核心功能模块拆解把需求变成可落地的设计3.1 用户端与管理端的边界划分这个系统我建议按两种角色来设计权限模型普通用户和管理员。落地上是两张表user和admin不要搞成一张表加 role 字段。原因有两点一是两个角色的字段本身就有差异用户要存昵称、头像、个人歌单管理员要存操作日志关联二是答辩时分开两张表讲权限设计会轻松很多——凡是涉及“为什么这样设计”的问题你都可以说“因为两者的核心领域模型不同强行合并会增加表结构的冗余和耦合”。用户端的核心功能是注册/登录用户名密码验证码浏览歌曲列表、按歌手/专辑筛选关键词搜索歌曲名、歌手名播放/暂停/上一曲/下一曲收藏歌曲、查看收藏列表个人歌单创建与管理加分项管理端的核心功能是歌曲管理添加、编辑、下架、删除歌手管理专辑管理用户管理查看用户列表、禁用/启用账号数据统计歌曲总数、用户总数、播放总量3.2 数据库表结构五张核心表整个项目的数据库我设计了 9 张表但核心的只有 5 张把这 5 张表的结构讲清楚你的数据库设计这一关就过了。用户表字段有id、username、password、nickname、avatar、create_time。密码必须加密存储用 MD5 加盐或者 BCrypt我会在后面代码部分给出具体实现。歌手表id、name、avatar、intro、create_time。歌手信息和歌曲分开存符合“歌手一对多歌曲”的模型关系。专辑表id、name、cover、publish_time、singer_id。专辑有封面图这个字段后面要映射到静态资源路径。歌曲表这是全项目最核心的表字段包括id、song_name、singer_id、album_id、duration、audio_url、cover_url、play_count、status、create_time。audio_url存的是音频文件的访问路径不是二进制数据本身。这一点要特别注意很多新手会把音频转成 Base64 存到数据库里这是极其糟糕的做法——数据库会急剧膨胀查询效率下降播放前还得先解码。正确做法是文件存磁盘或者对象存储数据库只存一个可访问的 URL。收藏表id、user_id、song_id、create_time。联合唯一索引要加在(user_id, song_id)上防止重复收藏。表之间的关联关系用外键逻辑约束就好不要在数据库层面强制建物理外键。物理外键在删除关联数据时会非常麻烦而且毕设这种单机应用根本用不到数据库层面的外键完整性保障靠应用代码去控制逻辑就够了。3.3 为什么播放次数要单独设计播放次数在页面上只是一个数字实现上可以做成每次播放就UPDATE play_count play_count 1。这种实现简单但有一个容易被问到的问题你在列表页看到的播放次数不准确。为什么因为列表查询走的是索引查询和缓存每次播放时的更新操作是异步的。真正的生产系统会用消息队列异步削峰但毕设阶段你只需要做到“页面展示的播放次数与数据库最终一致”也就是延迟更新可接受。我的建议是做一个独立的接口play前端在切换歌曲时调用后端只做自增并清理缓存列表查询永远走缓存。这样既能保证性能答辩时又能体现你对读写分离、缓存一致性的理解。4. 落地上手从环境搭建到核心代码实现4.1 开发环境与工程结构用 IDEA 开发JDK 用 1.8 或 11 都可以SpringBoot 版本选 2.7.x这个版本比较稳定和 MyBatis-Plus 的兼容性也很好。Maven 做依赖管理用阿里云镜像加速依赖下载。工程结构按照标准的 Controller-Service-Mapper 三层来做不要额外加花活。src/main/java/com/example/music ├── controller # 控制层 │ ├── UserController.java │ ├── SongController.java │ ├── AdminSongController.java │ └── FileController.java ├── service # 业务层 │ ├── UserService.java │ ├── SongService.java │ └── impl/ ├── mapper # 数据访问层 │ ├── UserMapper.java │ └── SongMapper.java ├── entity # 实体类 ├── common # 公共响应封装、异常处理 └── config # 配置类静态资源映射、拦截器前端页面放在src/main/resources/templates下Thymeleaf 默认从这里解析 HTML。静态资源放在src/main/resources/static包括 CSS、JS、图片和上传后的音频文件。4.2 音频文件上传与静态资源映射这是整个系统最容易出问题的地方。人家说的“附源码”里的代码能不能跑关键就看这一块。你需要先做一个文件上传功能接收前端传过来的音频文件保存到服务端磁盘的某个目录并生成一段可访问的 URL。我的做法是这样。首先在application.yml里配置本地存储路径spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB web: resources: static-locations: classpath:/static/,file:${music.upload-path} music: upload-path: /Users/yourname/music-upload/这里有个关键点spring.web.resources.static-locations配置里加了file:前缀意思是把本机磁盘目录也加入到静态资源映射中。这样你就能通过http://localhost:8080/audio/xxx.mp3直接访问上传的音频文件了。然后写文件上传接口。保存文件的文件名不要用原始文件名因为可能包含中文和特殊字符在 URL 拼接时会出问题。我用UUID.randomUUID()生成新文件名后缀取原始文件的后缀。PostMapping(/upload) public ResultString uploadAudio(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(文件不能为空); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String filename UUID.randomUUID().toString().replace(-, ) ext; File dest new File(uploadPath filename); try { file.transferTo(dest); } catch (IOException e) { return Result.error(文件上传失败); } String url /audio/ filename; return Result.success(url); }这个/audio/前缀是虚拟路径实际的映射要在配置类里加一个WebMvcConfigurer。注意如果你上面已经用static-locations映射了整个目录那访问http://localhost:8080/audio/xxx.mp3时Spring 会去/Users/yourname/music-upload/audio/xxx.mp3找文件所以上传保存时要把文件实际存到uploadPath/audio/目录下。我的习惯是单独加资源映射不依赖static-locations的全局配置Configuration public class WebConfig implements WebMvcConfigurer { Value(${music.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/audio/**) .addResourceLocations(file: uploadPath audio/); } }这样写更直观也更好排查问题。4.3 分页与搜索一个通用列表接口的写法歌曲列表页是流量最大的页面既要分页又要支持关键字搜索。用 MyBatis-Plus 的Page和LambdaQueryWrapper配合最省事。public ResultPageSinger getSongPage(int pageNum, int pageSize, String keyword) { PageSinger page new Page(pageNum, pageSize); LambdaQueryWrapperSong wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(keyword)) { wrapper.like(Song::getSongName, keyword) .or() .like(Song::getSingerName, keyword); } wrapper.orderByDesc(Song::getPlayCount); songMapper.selectPage(page, wrapper); return Result.success(page); }LambdaQueryWrapper是 MyBatis-Plus 对条件构造器的 Lambda 封装用方法引用代替字段字符串好处是编译期就能发现字段名拼写错误。分页插件记得在配置类里注册Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }4.4 登录认证拦截器 Token 的方式毕设场景用 Session 是最简单的JWT 是加分项。我用 JWT 是因为答辩时“为什么不用 Session”这个问题几乎是必问的。方案选型上我用 JWT 拦截器的组合前端登录成功后后端签发一个有效期为 2 小时的 Token 返回给前端前端把 Token 存到 localStorage在后续请求中通过请求头Authorization: Bearer xxx带上。后端写一个 HandlerInterceptor只拦截需要认证的接口。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (!StringUtils.hasText(token) || !token.startsWith(Bearer )) { response.setStatus(401); return false; } token token.substring(7); // 解析token验证合法性 Claims claims JwtUtil.parseToken(token); if (claims null) { response.setStatus(401); return false; } // 把用户信息放到request属性里后续业务方法可以直接取 request.setAttribute(userId, claims.get(userId)); return true; } }JWT 的核心价值在于无状态服务端不需要保存会话记录这在分布式部署时特别有用。毕设虽然用不到分布式但你把这个扩展价值讲清楚就比单纯写一个 Session 登录更有说服力。密码加密我用 BCrypt。BCryptPasswordEncoder是 Spring Security 全家桶里的组件但单独引进来用也没问题它比 MD5 强的地方在于每次加密生成的密文都不同自动加盐即使两个用户密码一样存储的哈希值也不一样。注册时对密码做一个 encode登录时用matches方法比对明文和密文。4.5 在线播放前端 Audio 与后端接口的配合播放的核心是 HTML5 的audio标签。页面放一个隐藏的 audio 元素通过 JavaScript 控制播放。切歌时修改audio.src然后调用audio.play()。audio idplayer preloadmetadata/audiofunction playSong(songId, audioUrl) { const player document.getElementById(player); player.src audioUrl; player.play(); // 通知后端播放次数1 fetch(/api/song/play/${songId}, { method: POST }); }播放次数接口后端实现很简单PostMapping(/api/song/play/{id}) public ResultString play(PathVariable Integer id) { Song song songMapper.selectById(id); if (song ! null) { song.setPlayCount(song.getPlayCount() 1); songMapper.updateById(song); } return Result.success(ok); }这里有一个可以扩展的设计点播放次数上传前可以先在前端做一个本地累积比如一首播了 5 秒以上才算一次有效播放连续切歌不超过 2 秒不计入播放量。这种逻辑生产环境会做防刷你在答辩的时候可以主动提出来老师会看到你考虑了实际业务问题。4.6 管理端歌曲添加的完整流程管理端添加歌曲前端表单涉及三部分歌曲信息歌名、歌手、专辑、时长、音频文件、封面图片。一次提交两个文件用multipart/form-data格式。Controller 方法里接受两个MultipartFile参数分别处理后再保存到数据库。PostMapping(/admin/song/add) public ResultString addSong(RequestParam(songName) String songName, RequestParam(singerId) Integer singerId, RequestParam(audio) MultipartFile audio, RequestParam(value cover, required false) MultipartFile cover) { String audioUrl uploadFile(audio, audio); String coverUrl cover ! null ? uploadFile(cover, cover) : /img/default-cover.png; // 封装实体插入数据库 Song song new Song(); song.setSongName(songName); song.setSingerId(singerId); song.setAudioUrl(audioUrl); song.setCoverUrl(coverUrl); songMapper.insert(song); return Result.success(添加成功); }接口写完后记得处理异常。文件超过大小上限、文件名不合法、歌手不存在这些都要有对应的异常信息和响应码。前端把Result响应体解析出来弹出相应的提示这个闭环就完整了。5. 常见问题与排查技巧实录5.1 音频文件访问 404这个问题的出现率极高。核心原因通常是静态资源映射配置没生效或者目录不存在。排查步骤我一般按顺序来先确认磁盘目录存在且文件已经在里面。如果文件还在上传接口里就返回失败先排查 FileOutputStream 或 MultipartFile.transferTo 的路径问题。确认配置文件里的路径拼写file:前缀不能少路径后面audio/目录是否存在。浏览器直接访问http://localhost:8080/audio/xxx.mp3看服务器返回的响应头。如果返回 404 但不是 Spring 的 404 页面而是 Tomcat 默认的那就是资源处理器没匹配到。如果配置了spring.web.resources.static-locations和addResourceHandlers两处可能产生冲突我的建议是只保留addResourceHandlers这一种全局的那份注释掉。5.2 跨域问题使用 Thymeleaf 模板渲染时后端渲染出来的页面和静态资源同源基本不会遇到跨域。如果你改成了前后端分离请求端口不同就会触发跨域。SpringBoot 解决跨域有三种方式CrossOrigin注解、CorsFilter、实现 WebMvcConfigurer。毕设场景我推荐 GlobalCorsConfig 这个统一配置的方式因为你在 Controller 上一个个加注解太散而且CrossOrigin在拦截器链中可能因为排序问题失效。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns和allowedOrigins的区别后者不能配合allowCredentials(true)使用通配符前者可以。5.3 播放过程中偶发卡顿或无法播放首要排查后端返回的 URL 用浏览器直接打开能不能播。能打开但页面上卡多半是前端逻辑问题。用浏览器开发者工具的 Network 面板看音频请求的响应时间和状态码。另外一种情况是后端缓存了旧文件你重新上传了同名音频但文件名没变浏览器端帮忙缓存了。解决方法是上传文件时文件名用 UUID 重新生成不要复用旧名。这个在代码里已经处理了如果你从网上拉的别人的源码注意看他的文件名生成逻辑如果直接用file.getOriginalFilename()那播放更新后的音频会命中浏览器缓存造成播放的还是旧文件的假象。5.4 数据库连接和中文编码MySQL 8.0 的驱动类换成了com.mysql.cj.jdbc.Driver连接 URL 里要加serverTimezoneAsia/Shanghai和characterEncodingutf8不然时间字段和中文可能会出现乱码。完整配置spring: datasource: url: jdbc:mysql://localhost:3306/music_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver5.5 启动报端口被占用SpringBoot 默认跑在 8080如果你本机的其他服务比如某管理软件、某中间件占用了端口启动时直接报错。临时解决方案是在启动参数加--server.port8081或者改配置。如果你想做成一键启动可以用一条命令后台启动并指定端口nohup java -jar music-system.jar --server.port8080 music.log 21 6. 关于源码复用和二次开发的几点意见很多拿到源码的朋友直接解压、改个数据库名、启动就完事。我不建议这样。如果源码不是你写的那你至少要通读关键的几个类至少要做到随便指一个 Controller 方法你能说出它的调用链是怎么走到 Mapper 的。答辩老师看你源码时问的第一句话几乎都是“这一块的执行流程是什么”。通读源码有一个技巧从请求入口开始追。比如你打开用户登录页面提交表单去 Controller 里找接收登录请求的方法然后看它调了什么 Service、Service 又调了什么 Mapper、SQL 是查的哪张表。把一个完整链路追完这个项目你就有底了。如果你想在上面做二次开发我建议优先加“歌单功能”。现在的核心表里没有歌单表加一张playlist表和一张playlist_song关联表实现创建歌单、往歌单里加歌、查看歌单详情。这个功能贴近真实业务场景音乐 App 的核心就是歌单工作量不大两张表加两个接口但在答辩时是一个能体现你独立思考的加分项。另一个加分方向是展示层优化。现在的列表页如果只是表格视觉上会很朴素。你可以用卡片样式来展示歌曲封面鼠标悬浮显示播放按钮这种前端小优化不需要后端做任何改动视觉效果却提升非常明显。答辩时打开页面第一眼的印象分很重要。7. 从毕设到面试这个项目怎么讲出亮点项目做完了只是第一步会讲才是关键。面试官不会问你“这个项目用了哪些技术”而是会问“这个项目你负责的部分有哪些难点怎么解决的”。结合这个系统我总结了三类经典问题为什么选择这个做毕设而不是用现成的开源音乐网站你要回答的是开源项目功能臃肿、代码复杂不适合学习。而自己从零搭建可以完整理解业务模型、表结构设计、认证授权、文件存储的每一步并且在此基础上做了哪些自己的改进。播放次数高频更新为什么不用 Redis这道题的逻辑是这样的先承认这个场景确实适合用 Redis再分析毕设场景里的数据量。单机用户量级下MySQL 的原子自增完全够用引入 Redis 反而引入缓存一致性维护成本属于过度设计。但你可以说明自己知道 Redis 的解决方案并且未来在用户量增长时会如何演进Redis 计数定时落库。如果让你把这个项目部署到生产环境你会做哪些改进思路方向Nginx 反向代理做动静分离静态资源不走后端、HTTPS 加密传输、数据库读写分离、日志采集、监控告警、对象存储代替本地磁盘存音频、CDN 加速音频访问。你能说出其中两三个具体方案并且说清楚改动机和落地步骤这个项目在你简历上的价值就远不止一个毕设了。我个人在实际操作中的体会是毕设项目很像一个完整的软件工程训练场——需求分析、技术选型、表设计、编码调试、部署上线每个环节都会暴露问题而解决问题的过程比项目本身更有价值。如果你现在正卡在某个功能上别急着换方案先把日志打出来把请求链路追一遍多数问题都不是真问题只是线索还没找全。

SpringBoot在线音乐播放系统：从数据库设计到文件上传实战

相关推荐

用 rea 逆向网站之前，先看这四条合规红线

AI编程助手省Token实战：上下文管理与精准投喂的系统性优化

PHP借贷源码部署避坑指南：从业务模型到安全上线

更多资讯

从OpenClaw到Moltbook：让纸质书变身AI可调用的个人知识库

Spring单例注入多例Bean失效？四种方案彻底搞懂Bean作用域

C++内存管理实战：从RAII到内存池，根治泄漏与性能问题

Python+HTML四足机器人DIY：舵机抖动与步态调参实战

开源AI助理OpenClaw接入飞书：从零搭建省下年费几百元

AI写作工具怎么选？从产品思路到真实体验的千笔AI评测

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？