SSM+Vue音乐系统毕设实战：从登录鉴权到项目部署全流程-平芜编程栈

1. 毕设选题那一刻，我为什么押注了SSM+Vue做音乐系统

每年到了毕设季，最纠结的其实不是代码写不写得出来，而是选题那一刻的患得患失。平台推荐Spring Boot+Vue，网上又是铺天盖地的若依管理系统，图书馆里全是图书管理、宿舍管理、班级管理系统，看得人心里发慌。我当时定下"SSM+Vue乐音乐系统"这个方向，核心考虑就三条。

第一，技术栈足够"承重"。SSM（Spring+SpringMVC+MyBatis）在高校课程里几乎是标配，答辩组的老师对这个框架天然熟悉，你说到IOC、AOP、Mapper映射，他们能迅速get到你在做什么，不用费劲解释为什么用这个技术。第二，音乐系统有天然的展示空间。图书管理类的项目界面做出来就是一张表，而音乐系统有播放器、歌单封面、评论互动、排行榜，前端能发挥的余地大得多，页面一打开视觉冲击力就不一样，这在答辩时是很加分的"第一印象"。第三，扩展点足够多。登录注册、文件上传、搜索分页、权限控制、数据统计，毕设评审里常被追问的点，这个项目全都能覆盖到，不愁没东西讲。

有用Java背景想选的也可以参考一个技巧：把"SSM+Vue"这套理解透以后，理解Spring Boot真的只是换了一层壳。我后来自学Spring Boot的时候，几乎没花太多额外精力，因为核心的IOC容器、AOP切面、MyBatis整合思路完全相通。这也是为什么很多毕业设计平台至今还在用SSM做后端——它虽然不是最新最热的技术，但作为"教学载体"确实够成熟。对于普通本科毕设，与其追求新奇技术栈，不如把一个经典的架构摸透，做出一个完整的、能跑、能讲、能演示的项目，这才是毕设的核心评分逻辑。

选定了方向以后，我做的第一件事不是敲代码，而是花了一整个晚上把"乐音乐"的需求拆了一遍。后面的事实证明，这个晚上省下的时间远超想象。

1.1 音乐系统的需求拆解：别一上来就写表结构

很多人拿到项目就开始建表，这是最大的坑。建表的前提是搞清楚角色，角色不同，功能完全不同。

我最初列的角色就两个：普通用户和管理员。用户侧的核心诉求是：听歌、搜歌、建歌单、收藏、评论。管理侧的核心诉求是：管理歌曲资源、管理用户、管理评论、查看统计数据。就这么一拆，整个系统的功能模块就浮出水面了：

用户模块：注册、登录、个人信息、头像上传、密码修改
音乐模块：歌曲列表、歌曲搜索、分类筛选、排行榜、歌曲详情
播放模块：播放/暂停、上一首/下一首、播放模式、播放列表
歌单模块：创建歌单、编辑歌单、添加歌曲、收藏歌单
评论模块：发表评论、回复评论、评论列表、删除评论
管理后台：歌曲管理、用户管理、评论管理、数据统计

功能清单出来后，我开始估算工作量。每个模块都有增删改查的影子，但重点不在这个"影子"，而在于模块之间怎么联系起来。比如歌曲和歌单是多对多关系，用户和收藏是多对多关系，评论挂在歌曲和用户之下。理清楚了关联，表结构的设计就水到渠成。

1.2 "论文+程序"双线并行：避免最后一个月赶工到崩溃

毕设最怕的就是程序写完才发现论文没素材，论文写完发现程序还得改。我采用的做法是"一个功能模块对应一个论文章节"——每完成一个模块，立刻整理该模块的设计思路、核心代码截图、遇到的问题和解决方案，当天整理成文字扔进论文素材库。

比如做登录模块的时候，我整理了：登录流程的设计思路（前端表单校验→后端参数校验→业务层验证→session/token返回）、密码加密方案的选型过程、前端Axios拦截器的处理逻辑。这些内容后面直接就是论文章节的原材料，真实且不重复。

论文的骨架我提前就定好了：绪论、相关技术介绍、系统分析、系统设计、系统实现、系统测试、总结展望。程序做到哪一步，论文就同步写到哪一步。最后一个月我只做了一件事：把素材串成正式论文，调整格式，查重。没有那种"程序完了论文一笔没动"的绝望状态。

2. SSM后端的核心难点：模型设计、登录鉴权与文件上传

后端如果只是把Controller、Service、Mapper三个层搭起来跑通流程，其实两天就能搞定。真正花时间的，是那些"看起来很常见、做起来全踩坑"的细节。

2.1 数据库设计：乐音乐系统的五张核心表

我设计的核心表一共五张，外加两张关联表。第一张是用户表user，字段包括id、username、password、nickname、avatar、role、create_time。第二张是歌手/艺术家表singer，字段包括id、name、introduction、avatar——音乐系统光有歌不行，得有歌手维度，否则分类和检索做出来很单薄。第三张是歌曲表song，字段包括id、singer_id、name、duration、url、lyric、play_count、create_time。第四张是歌单表song_list，字段包括id、user_id、title、cover、intro。第五张是评论表comment，字段包括id、user_id、song_id、content、reply_id、create_time。

下面给出一段我实际用到的建表SQL，方便参考：

CREATE TABLE `song` ( `id` int(11) NOT NULL AUTO_INCREMENT, `singer_id` int(11) DEFAULT NULL COMMENT '歌手id', `name` varchar(100) NOT NULL COMMENT '歌曲名', `duration` varchar(20) DEFAULT NULL COMMENT '时长 mm:ss', `url` varchar(255) NOT NULL COMMENT '歌曲文件地址', `lyric` text COMMENT '歌词', `play_count` int(11) DEFAULT '0' COMMENT '播放次数', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_singer_id` (`singer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='歌曲表';

这里有个连表查询要注意的点：歌曲列表页需要显示歌手名，不能每次都在业务层循环查歌手。我直接写了关联查询，在Mapper里join singer表，一次拿回组装好的VO对象。MyBatis的resultMap要定义好关联映射，不是所有场景都适合用嵌套select，那样会产生N+1查询问题。我踩过这个坑之后才意识到，虽然MyBatis写SQL麻烦了一点，但恰恰是这种"麻烦"逼着你思考查询方案的最优解。

另外强烈建议在字段命名上统一用驼峰转下划线的兼容策略。我的做法是数据库字段用下划线（如create_time），实体类属性用驼峰（如createTime），并在mybatis-config.xml里开启：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

这样轻松解决映射问题，避免每一个字段都写resultMap列映射的繁重劳动。

2.2 登录鉴权：Session方案在毕设里完全够用

毕设的登录鉴权，网上主流的声音是JWT，但我的建议是分情况。展示型毕设、没有微服务拆分需求、单机部署，用Session其实完全可以，而且逻辑更直观，答辩老师更容易理解。如果硬上JWT，你还得回答"token过期怎么处理""token如何在请求头传递""前端刷新token怎么办"这些问题，增加了答辩的不确定性。我最终用的是Session方案，配合SpringMVC拦截器做访问控制。

登录整体流程是这么设计的：

前端Vue页面收集用户名密码，通过Axios提交到后端/user/login
后端Controller接收参数，调用Service层验证
MyBatis根据username查询用户，比对密码（MD5加盐后对比，不是明文存储）
验证通过后，将用户对象放入Session
拦截器放行后续所有请求，每次从Session中取用户信息

拦截器是我的核心代码之一，效果很好：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object user = session.getAttribute("loginUser"); if (user == null) { // 未登录，重定向或者返回JSON提示 response.setContentType("application/json;charset=utf-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录\"}"); return false; } return true; } }

这里有一个很细节的点：前端请求被拦截后返回401，Axios的响应拦截器要统一处理跳转到登录页。我的做法是在响应拦截器中判断status是否等于401，如果等于就清除本地用户信息并用Router跳回登录页。这个联动逻辑论文里一定要写，属于亮点。

密码加密选型这件事也要说一下。很多初学的同学直接明文存密码，这在论文里会被老师挑刺。我用的方案是MD5加盐，具体做法是用户注册时生成一个随机salt，存到数据库里，保存的密码是 MD5(password + salt) 的结果。校验时再次拼接+计算，比对是否一致。当然现在业界的主流是BCrypt，毕设用BCrypt也不难，导入spring-security-crypto依赖就行。我当时选MD5加盐，主要考虑到答辩时讲起来简单，一个拼接公式就解释了。

2.3 文件上传与静态资源映射：音乐文件存储方案的取舍

音乐系统必然涉及音频文件上传。管理员后台需要上传歌曲文件（MP3格式），用户需要上传头像。这里第一个问题是文件存到哪。

方案无非两种：本地磁盘、云存储（OSS/COS）。毕设我推荐本地磁盘，因为云存储需要配置AccessKey等敏感信息，答辩时容易被认为"有安全风险"，而且教学项目没太大必要依赖外部服务。具体做法是配置一个上传路径，比如D:/music-data/（Windows下）或/home/music/（Linux下），然后通过SpringMVC把文件保存到指定目录。

上传接口的核心逻辑如下：

@PostMapping("/admin/song/upload") public Result uploadSong(@RequestParam("file") MultipartFile file) { // 1. 获取原始文件名，处理中文与空格 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); // 2. 生成唯一文件名，避免覆盖 String newFilename = UUID.randomUUID().toString().replace("-", "") + ext; // 3. 保存文件到磁盘 String savePath = uploadDir + newFilename; file.transferTo(new File(savePath)); // 4. 返回可访问的URL（后续存入song表） return Result.success("/music/" + newFilename); }

接下来一个必须解决的问题是静态资源映射。文件保存到了磁盘目录，但HTTP请求/music/xxx.mp3默认是访问不到磁盘上的文件的。必须在SpringMVC配置里加上资源映射：

<mvc:resources mapping="/music/**" location="file:D:/music-data/" />

如果你用的JavaConfig方式，代码如下：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/music/**") .addResourceHandler("/music/**") .addResourceMapping("file:" + uploadDir); }

这块我踩过一个特别隐蔽的坑：Windows下Linux路径分隔符不兼容。我在本地用D:/music-data/没问题，部署到服务器Linux后路径写成了D:/music-data/，文件永远404。最后排查是小写斜杠和路径前缀的问题，改成/home/ubuntu/music/立刻就好了。所以上传路径最好配置在配置文件里（properties或yml），不要硬编码在代码中，部署时环境变了直接改配置。

2.4 SSM常用注解冷热知识：除了@Autowired你还得会这些

毕设答辩时，老师最喜欢随手指一个地方问："这个注解是干什么的？"所以SSM常用的注解，不能只是会标注，得能脱口而出讲清楚。我整理了自己项目中用到的注解清单，做了分类汇总：

层	注解	作用说明
控制层	@Controller	标记该类是SpringMVC控制器
控制层	@RequestMapping	映射URL路径到处理方法
控制层	@ResponseBody	返回JSON数据（配合Jackson转换）
控制层	@RequestParam	接收请求参数并绑定方法参数
控制层	@PathVariable	接收URL路径中的参数
业务层	@Service	标记该类是Service层组件
业务层	@Autowired	依赖注入（byType）
持久层	@Repository	标记Mapper接口（也可不加）
配置类	@Configuration	标识该类是配置类
配置类	@Bean	把方法返回值注册为Bean
配置类	@EnableTransactionManagement	开启事务管理

有一个点值得特别说明：@Autowired的注入方式在构造器注入和字段注入之间怎么选。严格来说，Spring官方推荐构造器注入，因为在Bean初始化时就完成依赖绑定，方便测试，也能避免字段注入可能产生的循环依赖。但在毕设这种场景，字段注入代码更简洁，绝大多数人都在用，答辩也不会被扣分。我自己用的是字段注入，然后把"依赖注入的几种方式"作为论文里的小节内容写进去了，反而显得有深度。

3. Vue前端实战：环境配置、路由守卫与播放器组件的设计智慧

如果说后端是骨架，前端就是脸面。音乐系统的前端体验直接决定答辩演示的效果。我从环境搭起，一路走到组件设计，主要踩过的坑集中在三个地方：环境版本、路由权限、播放器逻辑。

3.1 Vue环境配置：Node版本、npm镜像和脚手架版本的故事

Vue环境配置看着是"按文档装就行"，实际上版本问题能让人装到怀疑人生。我第一次装Vue就卡在node版本上——脚手架的webpack依赖要求Node版本不能太低，而系统自带的Node又太旧，装一半就报ECONNRESET之类的网络错误。

我最终的做法是这样的：

# 1. 确认Node版本，建议16.x及以上 node -v npm -v # 2. 配置国内npm镜像（这一步能救很多人的命） npm config set registry https://registry.npmmirror.com npm config get registry # 3. 安装Vue CLI npm install -g @vue/cli # 4. 创建项目 vue create music-front

创建项目的时候，Vue CLI会让你选预设：Vue 2还是Vue 3、要不要Router、要不要Vuex/Pinia。我当时选的是Vue 2 + Router + Vuex的组合，因为SSM后端是Java系，Vue 2配合webpack生态的成熟度最高，网上的资料也是最全的。Vue 3虽然更先进，但Composition API在答辩时反而要多解释一层概念。选Vue 2不是说Vue 3不好，而是"在毕设这个场景下选最稳妥的"。

安装依赖的时候还有个常见报错：项目创建后npm install卡住或者报peer dependency冲突。很多情况是依赖版本相互不对付，最简单的方案是删掉node_modules和package-lock.json后重新安装。我遇到过两次，都是这么解决的，别在装依赖上死磕太久，不值得。

热搜词里提到的"vue安装依赖"确实是个高频问题，大家遇到的坑都差不多，无非是网络、缓存、版本三大类。先试镜像，再试清缓存，最后再考虑升降版本，排查顺序不要乱。

3.2 路由设计：静态路由+动态路由的那些坑

音乐系统的前端页面不少，我一开始全部用静态路由：登录页、注册页、首页、歌单页、排行榜、个人中心、后台管理。做了几个页面以后发现，后台管理这块不应该对普通用户开放，这一下子就引出"路由权限控制"的需求。

我的方案是"动态路由"：登录成功后，前端根据用户角色动态添加路由。Vue Router 2的addRoutes方法可以做到：

// 动态添加管理员路由 if (role === 'admin') { router.addRoutes([ { path: '/admin', component: () => import('@/views/admin/AdminHome.vue'), children: [...] } ]); }

这里有个细节很容易忽略：动态添加的路由在页面刷新后会消失，因为整个前端应用会重新加载。解决思路是把用户的角色信息存在localStorage中，刷新后重新读取角色，再重新addRoutes。如果你没做这一步，刷新后 admin 页面立刻404，演示的时候被问到就尴尬了。

路由守卫是另一个必写的点。我用的全局前置守卫：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.path === '/login') { next(); } else if (!token) { next('/login'); } else { next(); } });

路由传参这块，音乐系统的场景是：从歌单列表页跳到歌单详情页，需要传递歌单ID。我使用的是query方式（this.$router.push({ path: '/listdetail', query: { id: listId } })），跳转后通过this.$route.query.id取出。query方式的好处是参数在URL中可见，刷新后不会丢失；缺点是不够"优雅"（有的老师会问为什么不用动态路由参数）。另一种是params+动态路径的方式，如/listdetail/:id，URL更美观。我两个都用了：列表跳详情用params方式，因为更自然；需要分享的链接用query方式，因为不容易丢参。

3.3 播放器组件设计：一个audio全局单例的自我修养

音乐播放器是整个系统的灵魂组件。我第一版是在每个歌曲列表页都写一个audio标签，后来发现一个致命问题：你从排行榜切到歌单页，播放就断了。原因是当前组件被销毁了，audio也被销毁了。

要解决"全局播放不中断"，正确做法是把audio元素放到App.vue根组件里，或者放到一个全局唯一的播放条组件中，再用状态管理保存播放列表、当前歌曲、播放状态。我用Vuex管理了这些状态：

// store/modules/player.js const state = { playList: [], // 播放列表 currentIndex: -1, // 当前播放索引 isPlaying: false, // 播放状态 currentTime: 0 // 当前播放进度 }; const mutations = { SET_PLAYLIST(state, list) { state.playList = list; }, SET_CURRENT_INDEX(state, index) { state.currentIndex = index; }, SET_IS_PLAYING(state, status) { state.isPlaying = status; }, SET_CURRENT_TIME(state, time) { state.currentTime = time; } };

播放条组件则监听Vuex里的currentIndex变化，动态切换audio的src。这里有一个实用的快进/快退逻辑：SeekBar使用原生audio的currentTime属性，用户拖动进度条时更新audio.currentTime，同时监听timeupdate事件同步进度条位置。双向联动做起来不难，但如果没理清"以谁为数据源"就会遇到回跳问题。我的经验是：用户拖动时以拖动产生的值为准，播放中更新时以audio的currentTime为准，两个方向互不覆盖。

顺带说一个播放MP3的细节：很多同学的歌曲文件是mp3格式，直接用audio播放没问题。但有个别歌曲文件编码格式特殊（比如某些高采样率的音频，浏览器不支持），会卡住不播放。我处理的办法是：测试时优先使用标准的44.1kHz、128kbps码率的MP3文件，避免格式兼容性问题影响演示效果。

热搜词里提到"vue播放m3u8免安装"的问题，这个是直播/视频流方向的需求，音乐系统一般用不到。但如果你的系统里需要做视频MV展示，那就得用hls.js处理m3u8格式了。这里简述一下思路：安装hls.js依赖，在组件中动态实例化Hls对象，把video元素绑定上去就能播放了。原因在于浏览器原生不支持HLS流格式（Mac Safari除外），必须借助MSE（Media Source Extensions）转码成浏览器能识别的格式——本质上hls.js做的是"把流协议翻译给浏览器听"这件事。需要MV功能的话，这个点也可以作为论文的技术亮点提一笔。

3.4 Axios封装与跨域问题：别让你的网络请求裸奔

Vue项目里每个页面都在调接口，如果你每次都是this.$http.get(...)这种写法，代码会非常散。我统一封装了一个request.js模块，核心是三件事：统一baseURL、统一请求拦截器（带token）、统一响应拦截器（处理code状态）。

// src/utils/request.js import axios from 'axios'; import router from '@/router'; const request = axios.create({ baseURL: '/api', timeout: 10000 }); // 请求拦截器：附加token request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; }); // 响应拦截器：统一处理业务状态码 request.interceptors.response.use( response => { const code = response.data.code; if (code === 401) { localStorage.removeItem('token'); router.push('/login'); return Promise.reject(new Error('未登录')); } return response.data; }, error => { if (error.response && error.response.status === 401) { router.push('/login'); } return Promise.reject(error); } );

说完Axios封装，必须讲清楚跨域是怎么回事，因为这是毕设里几乎必被问到的问题。开发阶段，前端跑在http://localhost:8080，后端跑在http://localhost:8081，端口不同，浏览器会判定为跨域，直接请求会被拦截。我在开发环境下用Vue CLI的proxy代理解决：

// vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } } };

这个配置的意思是：前端请求/api/user/login，代理转发到后端http://localhost:8081/user/login，同时把/api前缀去掉。注意pathRewrite的用法，如果不写，后端接到的URL仍然是/api/user/login，如果没有对应@RequestMapping就404了。

生产环境的跨域是另一种解法：前端打包出来的静态文件放在后端的静态资源目录里，或者用Nginx统一反向代理。同域名同端口下就不存在跨域问题，这是真正的"根治"。后面我会在第4部分展开。

4. 联调、打包与部署：把程序和论文一起"跑起来"

4.1 前端打包放进SpringBoot的两种主要方式

开发完成后，最激动也最容易出问题的一步就是把Vue打包产物放到后端里，让它变回一个"单体应用"。这一步网上的方案大同小异，核心就是处理好前端静态文件和后端接口的"同居关系"。

方式一：把Vue打包后生成的dist目录直接拷贝到SpringBoot项目的src/main/resources/static下。SpringBoot默认会从classpath下的static目录寻找静态资源，所以这个方法基本零配置，放进去就能访问首页。但有几个细节要注意：

Vite/Vue CLI的打包配置里，publicPath要设置为相对路径或./，否则资源路径会是绝对的/assets/xxx，部署到子路径下就白屏。
前端路由如果是history模式，刷新页面会404。因为SpringBoot不知道路由/songlist/3对应哪个静态资源，返回404。解决方式有两种：路由改成hash模式（URL中带#），或者后端加一个fallback配置，将所有非接口路径都转发到index.html。

方式二：把dist目录放到服务器上，用Nginx托管前端，用后端接口服务和数据。Nginx配置的核心逻辑是：请求静态资源由Nginx直接返回，请求/api开头的路径反向代理到Java后端。这种方式更贴近真实企业部署，也是我在论文里"软件部署"章节重点写的内容。

分享一段我实际用过的Nginx配置：

server { listen 80; server_name your-domain.com; # 前端静态文件 root /home/ubuntu/music-front/dist; index index.html; # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # history模式路由回退 location / { try_files $uri $uri/ /index.html; } }

这个配置里有个细节：location /api/的proxy_pass如果带了末尾/（如http://127.0.0.1:8081/），实际转发过去的时候会把/api替换掉；如果不带/，路径会原样带过去。两种行为会导致后端接口路径不同，当时我在这个地方调试了半天，后来才算明白Nginx的URI替换机制。

4.2 按键自检清单：答辩前一夜我一定过一遍的检查项

为避免答辩现场翻车，我整理了一份"答辩前自检清单"，程序部署完成后逐项检查：

后端启动无异常：确认端口没有冲突，日志输出正常
首页加载速度：静态资源是否走了缓存，图片是否过重
登录注册流程：注册新用户、登录老用户、退出登录，三件事全流程走一遍
音频播放：当前列表连续播放三首歌，检查切歌逻辑无报错
搜索功能：中文模糊搜索、空关键词搜索、特殊字符搜索，至少各测试一次
文件上传：上传一个5MB左右的音频文件，确认路径正确、文件名无乱码
管理员界面：登录管理员账号，进入后台，删除一条测试数据再恢复（或直接删除一条无关联数据）
部署环境与本地环境一致性：数据库连接配置、上传路径配置、端口配置逐一核对

这份清单我打印了一份放在手边，答辩前一天晚上按顺序过一遍，整个过程大概20分钟，但能挡掉绝大多数现场问题。强烈建议你也这么做，不要觉得"开发的时候测过了就没事"，环境一变、数据一变，问题就会出现。

4.3 完成后端jar包构建：SpringBoot还是传统SSM的差异化部署

如果你用的是Spring Boot整合SSM（也就是用Spring Boot作为启动器，底下还是Spring+SpringMVC+MyBatis），打包发布非常轻松，Maven打包命令：

mvn clean package -DskipTests

打出来的jar包直接运行：

java -jar music-server.jar

但如果你用的是经典Web工程的SSM（war包方式），就需要部署到Tomcat的webapps目录下。这也是SSM的一个"老"的地方——配web.xml、配springmvc.xml、配applicationContext.xml，三份配置文件缺一不可。我当时用的就是war包方式，部署步骤是：把war包扔进Tomcat/webapps，启动Tomcat自动解压，通过http://localhost:8080/music-server/访问。

这里必须说一句：经典SSM是war包形态，Spring Boot是jar包形态，这个区别在论文的技术选型部分一定要写清楚。答辩老师如果看到你的系统用了SSM却是jar包启动，可能会追问"你怎么做到的"，如果你答不上来反而尴尬。要么用Spring Boot整合SSM（那论文里就诚实写Spring Boot技术栈），要么用经典SSM但部署方式是war包，二选一，别混着写。

4.4 音乐文件管理与数据库路径的关系

系统运行一段时间后，音乐文件会越来越多。歌曲上传接口只是把文件保存到磁盘，但数据库的song表里存的只是URL相对路径。如果磁盘文件被误删了，数据库里的记录还在，播放时就404了。这个"一致性"问题虽然是开发中容易被忽视的，但答辩时可以主动提出来作为"系统改进方向"，反而能成为加分项。

我在论文里的应对方案是：额外写一个定时任务（Spring的@Scheduled注解即可），每天凌晨扫描数据库待验证的歌曲记录，检查对应文件是否存在，不存在则标记为"文件缺失"状态，并在后台管理页面以红色标记展示。这个功能不算复杂，但足以展现你在系统设计层面的思考深度。实际做毕设如果时间紧，不实现也没关系，写成改进展望也是可以的。

5. 论文写作与答辩备战：程序做完，工作其实还剩一半

程序做完那一刻很兴奋，但我很快就意识到论文才是毕设评分的大头。不少同学程序功能很完整，论文却写成了"用户手册"，答辩时被老师一句"你的研究点在哪里"问得哑口无言。我总结了一套自己的论文写作逻辑，核心是"论文不是程序说明书的堆砌，而是系统设计过程的呈现"。

5.1 论文框架：从绪论到测试，每个章节的写作重心各不相同

我的论文一共六章加参考文献、致谢，结构如下：

第一章绪论：写选题背景、国内外研究现状、论文主要工作。背景从数字音乐发展趋势切入，研究现状总结现有的音乐平台（不指名道姓地分析功能），最后列出本文的工作内容和论文结构安排。

第二章相关技术介绍：介绍SSM框架和Vue技术栈，重点写清楚Spring的两大核心（IoC和AOP）、SpringMVC的请求处理流程、MyBatis的ORM原理。这部分很多同学容易写成纯抄博客、跟设计毫无关系，我的做法是每写完一个技术点，加一句"本文中该技术用于解决什么场景"，比如"MyBatis的延迟加载机制在本系统的歌词查询中得以应用"。

第三章系统分析：包括可行性分析（技术、经济、操作三个维度）、功能性需求分析、非功能性需求分析。需求分析部分用用例图表达角色和功能的关系，非功能性需求要写出性能指标（如响应时间小于3秒、支持200并发等）。

第四章系统设计：包括总体架构设计、功能模块设计、数据库设计（ER图+表结构详情）。数据库设计这一部分内容最厚，我每张表都配了字段说明表格，方便老师快速理解。

第五章系统实现：按照用户模块、音乐模块、歌单模块、评论模块、后台管理等分小节写。每个小节的结构是：模块功能描述→核心类设计与核心代码→界面截图→实现效果说明。核心代码选3-5段即可，不要贴一大段，老师没时间细看。

第六章系统测试：包括测试环境、测试用例设计（功能测试+界面测试+兼容性测试）、测试结果分析。这里我特意加入了"播放卡顿修复"的测试过程，展示定位问题的完整链路，比单纯列"测试用例全部通过"更有说服力。

5.2 答辩演练：老师最爱问的五类问题提前准备

论文和程序都完成后，剩下就是答辩。我提前准备了五个方向的问答，基本覆盖了80%的现场抽问：

第一类：技术选型问题。"为什么选用SSM？为什么不直接用Spring Boot？"我的回答思路是：毕设目的在于检验对Java Web基础框架的掌握程度，SSM由三门技术组成，能分别考察Spring的IoC/AOP、SpringMVC的MVC分层以及MyBatis的持久化映射，覆盖面更广。同时也说明SSM与Spring Boot是递进关系，理解SSM后迁移到Spring Boot成本很低。

第二类：核心功能问题。"你的播放次数统计是怎么实现的？"我在歌曲详情接口中加入了播放次数自增逻辑，每次前端调详情接口就update play_count=play_count+1。这个话题还能延伸讨论一下"如何防止恶意刷播放量"。

第三类：安全问题。"密码是怎么存储的？为什么不用明文？"这里讲清楚MD5加盐或者BCrypt的原理即可。

第四类：性能问题。"如果用户量变大了，你这个系统哪里会最先成为瓶颈？"我的回答是数据库表缺少索引优化以及文件存储存在单点问题，并说明改进方向。

第五类：扩展问题。"以后想在这个系统里加什么功能？"我会回答引入Maven私服、Redis缓存热点歌曲信息、容器化部署（Docker）以提升可维护性。

这些问题不需要回答得多高深，关键是"言之有物"，能自圆其说。把逻辑提前理顺，比临时发挥稳得多。

6. 复盘总结：重做一次乐音乐，我会改掉的五个问题

答辩结束以后，其实心里很清楚这个系统有多少可以打磨的地方。如果把"乐音乐"再做一次，我必定会改动下面这几处。

第一，经典SSM换成Spring Boot + MyBatis-Plus。不是Spring Boot比SSM高级多少的问题，而是配置复杂度会大幅降低。经典SSM的XML配置文件实在是太多了，会挤占真正用来写业务逻辑的时间。MyBatis-Plus可以少写大量的基础CRUD SQL，把精力放在连表查询和复杂统计上。

第二，数据库加索引。我在开发阶段表数据量小，没感觉查询慢。但答辩前为了演示导入了一万多条歌曲数据，搜索和列表接口的响应明显变慢。当时紧急给song表的name字段加了普通索引，才算恢复流畅。如果一开始设计表的时候就考虑索引，这一步就不用临阵磨枪。

第三，播放器加上进度记忆功能。当前系统的播放记录是存在内存中的，刷新页面后播放进度丢失。真正的音乐系统（像网易云、QQ音乐）应该记住用户上次听到的位置，这需要一张播放历史表，每次播放跳转都更新进度数据。

第四，后台加入数据可视化图表。用ECharts画一个歌曲播放量Top 10的柱状图，再画一个用户注册趋势的折线图。管理页面瞬间就有了"高大上"的感觉。技术难度不高，但对系统完整度的提升非常明显。热搜里提到"vue中用echarts画两个柱状统计图"，其实这就是同款需求，在毕设里能成为不错的答辩素材。

第五，前端组件再抽象一层。我把歌单卡片、歌曲行、评论条这些UI组件都封装成了Vue单文件组件，但当时封装得不够彻底，有几个页面里重复粘贴了相同结构。如果重新写，我会更严格地把"数据展示型组件"和"业务容器组件"分开，这样页面开发会清爽很多。

做完一次毕设，最大的感受是：技术的深度不在于你用了多新的框架，而在于你对你用的框架理解了多透。SSM+Vue的组合不新，但通过一个完整的音乐系统把登录鉴权、文件存储、路由权限、状态管理、部署运维这些环节全部走通以后，你会发现自己对整个Java Web开发的理解，比啃十篇博客都要扎实得多。

最后再分享一个小技巧：论文开题和中期答辩之前，就把项目跑起来录一个操作演示视频存好。一是因为答辩现场可能会遇到设备问题，有视频作为兜底方案就从容很多；二是录制的过程会逼着你完整走一遍所有功能，很多隐藏的问题就是在演示准备中提前暴露出来的。这个习惯，到了工作以后也一直受用。