基于Spring Boot的儿童音乐分享网站毕业设计全流程解析

四五月份打开任何技术社区，铺天盖地都是毕业设计求助帖。有人求完整源码，有人纠结选题，有人反复在Java、PHP、Python之间横跳。我刚把一个基于Spring Boot的儿童音乐分享网站完整落地并整理了文档，复盘下来发现这个题目非常值得推荐：它够具体、系统边界清晰，一套东西能串联起Java后端、管理后台、Web前端、微信小程序，还能往单片机硬件互动方向延伸出亮点。这篇文章就把我实际做过的东西掰开揉碎讲一遍，从选题逻辑、表结构、接口设计到小程序踩坑、答辩演示准备，全部覆盖。核心代码片段我直接贴在对应段落里，你可以照着改，但一定得自己敲一遍，否则答辩时一问就露馅。

1. 这个题目到底在考什么：从需求到评分点的完整映射

1.1 一个真正"能答辩"的儿童音乐分享网站长什么样

很多人拿到题目就急着写代码，结果写了两周发现功能堆不齐，答辩时PPT比代码还厚。先别急着动手，花两天把系统边界想清楚。

以儿童音乐分享网站为例，它的"用户故事"应该这样描述：一个家长注册账号后，为自己的孩子创建一个儿童档案；孩子在家长的手机上或者平板上的小程序里浏览儿歌、摇篮曲、启蒙音乐；孩子可以收藏喜欢的歌，可以按歌单连续播放；家长可以设置每日播放时长上限，可以远程锁定播放界面；管理员在后台审核音乐上传、管理评论，遇到不适合儿童的内容直接下架。

这套描述就是需求文档的核心素材。你把它转成用例图、功能列表、数据库ER图，整个项目的骨架就出来了。注意"儿童"这个限定词非常关键，它决定了系统里必须有内容审核和家长控制，这两块恰恰是普通音乐网站不需要的，也是很多模板代码里没有的，属于你自己设计出来的差异化功能。

1.2 评委最关注的五个评分维度

毕设答辩和公司面试不一样，评委老师不是要你证明自己有多强，而是要确认这项目是你写的、你懂原理、工作量够。对照我自己的经验，评分维度大致是下面这五块：

• 需求与文档完整性：题目背景、可行性分析、用例图、流程图、ER图、接口文档。儿童音乐网站因为角色多、状态多，天然容易画出像样的图表。
• 数据库设计规范性：表结构是否合理、有没有冗余、有没有考虑数据一致性。比如音乐表和歌单表是多对多关系，需要中间表；播放记录表要控制增长量，否则线上跑一年就几千万条。
• 核心技术真实掌握度：Spring Boot的自动配置、IoC容器、JWT鉴权、MyBatis-Plus的使用，你得能讲清楚为什么这样写。比如拦截器里放行哪些路径、为什么JWT要设置过期时间，这些概念必须张口就来。
• 功能完成度与稳定性：用户注册登录、音乐播放、歌单收藏、评论审核、家长控制，这些主流程不能断。宁可少一个花哨功能，也要把播放链路做得流畅。
• 创新与亮点：小程序端、单片机硬件联动、推荐算法简化版、敏感词过滤，任何一项做扎实了都能拉高整体评价。

把这五条刻在脑子里，后面每一步决策都对着它们检查，就不会跑偏。

1.3 多语言实现路线怎么选：Spring Boot、PHP、Python、C#横向对比

题目里列了Java、PHP、Python、C#，其实是在告诉你可以用任意主流后段语言实现。但你得选一条自己最有把握的路，我强烈建议优先Spring Boot，原因后面会展开。这里给一个真实对比，方便你结合自身情况选型：

技术栈	上手难度	招聘市场需求	适合什么人	典型坑
Java + Spring Boot	中	很高	系统学过Java、想走企业级开发方向	启动慢、包多、初学者容易卡在环境配置
PHP + ThinkPHP/Laravel	低	中	已经会PHP、时间非常紧	并发处理和工程化较弱，答辩理论深度有限
Python + FastAPI/Django	低	高	更熟悉Python、想少写样板代码	GIL与高并发解释起来较复杂，需要补课
C# + ASP.NET Core	中	中	学校教过C#、目标明确选.NET方向	社区资料相对Java少，遇到问题搜索成本高

我当时选Spring Boot，除了需求匹配度高，还有一层原因：Spring Boot的生态足够成熟，从用户认证、数据持久化、文件上传到定时任务，都有现成组件。你在答辩时要讲原理，网上随便一搜就是底层机制分析，不至于被问倒。最重要的是，这个小程序的场景和Java生态天然契合，前后端JSON交互、JWT签名、阿里云OSS上传，都是Java面试里常问的真实场景，相当于用毕设顺便刷了一遍Java面试题。

2. 先画系统边界，再写代码：模块、角色与表结构设计

2.1 角色与权限模型

儿童音乐分享网站不是简单的单用户系统，它至少有三类角色，对应三种完全不同的操作界面：

• 儿童用户：在小程序端浏览、播放、收藏、创建歌单，不能看到评论里的敏感内容，不能修改家长设置。
• 家长用户：管理儿童账号、设置播放时长、开启儿童锁、查看播放历史，可以做内容举报。
• 内容管理员：在后台审核音乐上传、审核评论、下架违规内容、统计播放数据。

权限模型最省事的方案是RBAC（基于角色的访问控制）。用户表、角色表、用户角色关联表，后端接口上用拦截器验JWT里的角色字段。儿童角色只放行/api/child/**，家长角色放行/api/parent/**，管理员角色放行/api/admin/**。别把权限写死在代码判断里，后面加需求会非常痛苦。

2.2 核心功能模块清单

整理一张表格放在设计文档里，既方便你编码时对照，又方便答辩老师快速理解项目工作量：

模块	功能点	说明	优先级
用户模块	注册、登录、JWT签发、儿童档案管理	家长注册后创建儿童档案，绑定年龄段	P0
音乐模块	音乐上传、音频转码、封面管理、分类标签	管理员先审后发，儿童端只能看到已上架音乐	P0
歌单模块	歌单创建、收藏音乐、每日推荐歌单	支持一键播放整张歌单	P1
播放模块	播放、暂停、上一曲/下一曲、播放记录	记录儿童播放时长，供家长控制使用	P0
评论模块	发表评论、点赞、敏感词过滤、举报	评论需要先过敏感词，再人工抽审	P1
家长控制模块	PIN码设置、单次播放时长、每日累计时长、强制停播	时长到了之后前端停止播放并弹出提示	P1
数据统计模块	播放量排行、收藏排行、分类占比	给管理员后台提供简单看板	P2

P0是必须完成的，P1是主干功能，P2可以在时间充裕时加分。没有P0，系统不能叫"可用"；只有P0，答辩也可能被批"工作量不足"。所以我建议P0+P1全部做完，P2看情况加。

2.3 数据库表设计

表设计是整个项目的地基。我这一版做了九张核心表：用户表、角色表、用户角色关联表、音乐表、歌手/专辑表（可选）、歌单表、歌单音乐关联表、播放记录表、评论表、审核记录表、家长控制配置表。实际项目里歌手和专辑我合并成了一张music_meta表，减少关联查询。

下面给三个关键表的建表SQL，直接抄进你自己的建表脚本里改改就行。第一个是音乐表：

CREATE TABLE `music` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(128) NOT NULL COMMENT '歌曲名', `singer` varchar(64) DEFAULT NULL COMMENT '歌手/演唱者', `album` varchar(128) DEFAULT NULL COMMENT '专辑或出处', `category` varchar(32) NOT NULL COMMENT '分类：儿歌/摇篮曲/启蒙/国学', `tags` varchar(255) DEFAULT NULL COMMENT '标签，逗号分隔', `cover_url` varchar(255) DEFAULT NULL COMMENT '封面图URL', `audio_url` varchar(255) NOT NULL COMMENT '音频文件URL', `duration` int DEFAULT '0' COMMENT '时长（秒）', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待审核 1已上架 2已下架 3被举报', `uploader_id` bigint DEFAULT NULL COMMENT '上传人ID', `play_count` bigint NOT NULL DEFAULT '0' COMMENT '播放次数', `like_count` bigint NOT NULL DEFAULT '0' COMMENT '收藏次数', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category_status` (`category`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='音乐表';

第二个是播放记录表。这个表一定要考虑数据量，不能设计成"永远不删除"，否则光日志就能拖垮查询：

CREATE TABLE `play_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '儿童用户ID或家长账号ID', `music_id` bigint NOT NULL, `play_date` date NOT NULL COMMENT '播放日期', `play_duration` int DEFAULT '0' COMMENT '本次播放时长（秒）', `play_count` int DEFAULT '1' COMMENT '当日累计播放次数', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_date` (`user_id`, `play_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='播放记录表';

第三个是家长控制配置表，它承载了整个"家长模式"功能：

CREATE TABLE `parent_control` ( `id` bigint NOT NULL AUTO_INCREMENT, `parent_user_id` bigint NOT NULL COMMENT '家长用户ID', `child_user_id` bigint NOT NULL COMMENT '绑定的儿童账号ID', `pin_code` varchar(64) NOT NULL COMMENT '家长PIN码，BCrypt加密存储', `daily_limit_minutes` int DEFAULT '30' COMMENT '每日累计播放上限（分钟）', `single_limit_minutes` int DEFAULT '15' COMMENT '单次连续播放上限（分钟）', `enable_lock` tinyint DEFAULT '1' COMMENT '是否开启儿童锁', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_parent_child` (`parent_user_id`, `child_user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='家长控制配置表';

注意pin_code一定要用BCrypt加密，别明文存。答辩时如果老师问"为什么存储PIN要加密"，你可以直接回答：防止数据库泄露后家长控制被绕过，儿童暴露在不适合的内容中，这属于儿童隐私保护的基本要求。

3. 后端核心链路的实现笔记：上传、播放、JWT与推荐

3.1 项目骨架与依赖清单

我用的是Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis（可选）。Maven依赖就那几个，但版本必须互相兼容，我卡过最久的一次就是Spring Boot 2.7和MyBatis-Plus 3.5.x之间关于分页插件方言的冲突。直接贴pom.xml核心部分：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.8</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.31</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> </dependencies>

项目结构我习惯这样分：controller、service、mapper、entity、config、common、dto、vo。其中common放统一返回结果类Result<T>和异常处理类，dto放前端传入的参数对象，vo放返回给前端的视图对象。很多学生喜欢直接用Map返回，小项目行，但答辩时老师看到你会用DTO和VO分离，印象分会明显更高。

3.2 登录与JWT鉴权：儿童端、家长端怎么区分

用户登录成功之后，后端签发一个JWT。JWT的payload里除了基础的用户ID、用户名、角色，我还加了一个字段mode，用来区分当前是儿童模式还是家长模式。为什么要加这个字段？因为儿童模式下某些接口必须拒绝访问，比如修改PIN码、查看审核记录。

核心逻辑就三步：登录接口校验用户名密码，生成JWT返回给前端；拦截器从Header里取Token并解析；每个接口通过角色注解或拦截器路径规则放行。对于一个毕设系统，没必要引入Spring Security全家桶，自己写一个拦截器反而更清楚：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录"); } Claims claims = JwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); request.setAttribute("mode", claims.get("mode")); return true; } }

通过拦截器把userId、role、mode塞进request属性，后续service里直接取。这套代码解析出的逻辑，比去网上抄一个Security配置要稳妥得多，因为你完全知道每一步在干什么。

3.3 音乐上传：格式校验、存储与静态资源映射

音乐上传是文件上传的经典场景。我推荐的处理方式是：本地上传+OSS可选。如果真的没有云服务器，就存在本机指定目录，再用Spring Boot的静态资源映射把目录暴露出去。

上传接口有几个细节要注意，都是实际踩坑踩出来的：限制文件大小，否则大音频文件会把内存撑爆；校验扩展名，只允许mp3、m4a、wav等格式；对上传者做角色校验，普通儿童账号不能调这个接口；文件名重命名，用UUID或时间戳，防止中文名乱码和路径穿越。

上传核心代码：

@PostMapping("/admin/music/upload") public Result<String> upload(@RequestParam("file") MultipartFile file, @RequestParam("title") String title, @RequestParam("category") String category) { // 1. 校验文件大小和扩展名 if (file.getSize() > 50 * 1024 * 1024) { return Result.error("文件不能超过50MB"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".") + 1).toLowerCase(); if (!Arrays.asList("mp3", "m4a", "wav").contains(ext)) { return Result.error("不支持的音频格式"); } // 2. 存储到本地目录，用UUID重命名 String fileName = UUID.randomUUID() + "." + ext; File dest = new File(UPLOAD_DIR + fileName); try { file.transferTo(dest); } catch (IOException e) { return Result.error("文件保存失败"); } // 3. 保存音乐元数据，状态置为待审核 Music music = new Music(); music.setTitle(title); music.setCategory(category); music.setAudioUrl("/files/" + fileName); music.setStatus(0); musicService.save(music); return Result.success("上传成功，等待审核"); }

在application.yml里加静态资源映射：

spring: mvc: static-path-pattern: /files/** resources: static-locations: file:${upload.dir:./uploads/}

这样音频URL就能直接通过/files/xxx.mp3访问。但如果以后部署到云服务器，建议换OSS，否则服务器带宽会打满。

3.4 播放记录与简易推荐逻辑

推荐功能听起来高大上，但毕设里做一个"猜你喜欢"的简化版完全够用。我的做法基于标签匹配：每首歌都有category和tags字段，查询当前用户播放次数最多的三个分类，再在这些分类里排除用户已经收藏和播放过的歌，按播放量降序取10条。

用SQL写就是这样：

SELECT m.* FROM music m WHERE m.status = 1 AND m.category IN ( SELECT category FROM play_record pr JOIN music mm ON pr.music_id = mm.id WHERE pr.user_id = #{userId} GROUP BY mm.category ORDER BY COUNT(*) DESC LIMIT 3 ) AND m.id NOT IN ( SELECT music_id FROM play_record WHERE user_id = #{userId} ) ORDER BY m.play_count DESC LIMIT 10;

逻辑很简单，但答辩时你可以展开讲：为什么排除已播放歌曲？因为推荐系统需要"多样性"和"惊喜度"，不能一直推用户已经听过的内容；为什么按播放量排序？因为从众效应在儿童内容场景里有一定合理性，热门且优质的内容更值得推荐。你看，两个问题讲清楚，一个简单推荐模块就能讲出深度。

4. 内容安全与家长控制：儿童网站最该认真做的地方

4.1 音乐上架的审核状态机

儿童音乐网站和普通音乐网站最大的区别，是内容安全必须前置到位。我设计了四个状态：待审核、已上架、已下架、被举报。管理员上传的音乐默认进入待审核，管理员在后台点审核通过才变成已上架；如果收到举报或有违规内容，状态变成被举报，管理员处理后置为下架或恢复上架。

状态机用代码实现时，最关键的是不能在service里随随便便更新status字段。我建议写一个专门的方法auditMusic(musicId, auditResult)，在里面校验当前状态必须是待审核，否则直接拒绝。这本质上是状态机的一致性保护，虽然简单，但能体现出你懂"状态流转"这个概念。

4.2 评论过滤与举报机制

评论区是最容易被忽略又最容易出问题的位置。儿童网站的评论必须过敏感词。我用的是开源工具sensitive-words，初始化一个敏感词列表，发表评论时先经过过滤，命中就直接把整条评论标记为待人工审核，而不是只替换成星号，因为替换后家长看到内容还会引起误解。

处理逻辑：

public boolean checkComment(String content) { if (SensitiveWordUtil.contains(content)) { return false; } return true; }

前端发评论时，后端先调checkComment，如果包含敏感词，状态置为2（待审核），管理员后台能看到并决定是否放行。这里还可以加一个简单举报表，家长看到疑似违规的评论点举报，写入report_record表，管理员后台进行复核。

4.3 家长模式：PIN码、时长统计与定时停播

家长模式是我认为整个项目里最出彩的功能，也是你答辩时最值得讲的一块。核心诉求是：儿童不能自己关掉播放限制，必须有家长输入PIN码才能修改配置。

实现分三步。第一步，家长在设置页开启儿童锁时设置PIN码，后端存BCrypt加密结果；第二步，小程序端每次进入设置页或退出儿童模式时弹PIN验证框，调用/api/parent/verify-pin接口；第三步，后端有个定时任务，每分钟扫描一次play_record表，统计当天累计时长，如果超过daily_limit_minutes，将对应儿童账号的play_status字段置为0，小程序端播放器轮询这个字段，发现是0就自动暂停并弹窗提示"今天已经听够啦，明天再来吧"。

这个"后端统计+前端轮询"的交互方式，比前端自己算时长要可靠得多，因为小程序端的时间可以被改，后端时间不可伪造。就这一个点，就够你在答辩时回答三四轮追问。

4.4 这个模块如何成为答辩加分项

每年毕业设计一大半都是商城、管理系统、论坛，内容审核和家长控制这种带行业垂直属性的功能很少见。老师看到你会针对"儿童用户"这一特殊人群做隐私保护设计，会直接判断你具备产品思维，而不仅仅是CRUD工程师。

5. Web前端与微信小程序：播放器与多端联调的经验

5.1 Web端：Vue3播放器选型与接口对接

Web端我用了Vue3 + Element Plus + vue-aplayer。Element Plus负责后台管理界面，vue-aplayer负责前台播放。这里有一个经验：不要自己写音频播放器，Audio API的原生UI很难看，而且碰到自动播放限制、切换歌曲状态同步等问题，自己折腾半天，效果还差。用成熟组件，做两层封装，对外暴露playList和currentIndex就够了。

后台管理的音频试听功能，可以在表格里加一个"试听"按钮，点击弹窗播放对应音频URL。前端播放URL时，记得通过后端返回的完整URL来拼接，别把本机路径写死。

5.2 小程序端：InnerAudioContext踩坑与域名白名单

小程序端播放音频，核心API是wx.createInnerAudioContext()。开发时有一个非常常见的坑：模拟器上音频能放，真机上放不出来。原因大概率是"开发环境不校验合法域名"这个开关没开，或者音频资源域名没在微信公众平台里配白名单。

建议开发阶段，在微信开发者工具右上角详情里勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"，这样本地调试不会被域名校验卡住。等要部署上线了，再把你的服务器域名配到后台，并且必须是HTTPS，否则真机上照样加载不了。

小程序里播放音频的典型代码：

const innerAudioContext = wx.createInnerAudioContext(); innerAudioContext.src = audioUrl; innerAudioContext.autoplay = true; innerAudioContext.onEnded(() => { // 播放完自动切下一首 playNext(); });

还有一个细节：小程序在切到后台时，音频不一定持续播放，这个行为由微信平台控制，不是你能改的。想要后台播放能力，需要申请"背景音频"类目权限，你可以在论文中提一句"已经了解背景音频能力的申请条件，但由于个人主体小程序无法开通，故采用普通前台播放方案"。这能体现你对平台限制有充分认知。

5.3 前后端联调：跨域、接口规范与调试技巧

Web端开发时最常遇到的就是跨域。Vue开发服务器跑在http://localhost:5173，Spring Boot跑在http://localhost:8080，前端直连必然报CORS错误。我在后端写了一个全局CORS配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

需要说明的是，小程序端不受浏览器同源策略约束，天然不跨域，但要求服务器域名备案和HTTPS。所以联调阶段重点是把接口请求和返回结构统一。我的Result<T>统一结构是这样的：

{ "code": 200, "message": "success", "data": {} }

前端拿到code为200才处理data，否则统一toast提示message。这个小设计能让前后端联调效率提升非常多，以后写Java面试题里的"统一响应体"也顺手了。

6. 加一个硬件互动亮点：单片机怎么和音乐网站联动

6.1 方案设计与成本估算

题目里出现了"单片机"，说明这个方向是加分项，不是主功能。我给当时的学生团队设计了一套低成本方案：用STM32F103C8T6最小系统板，接一个蓝牙模块（HC-05或JDY-31），再通过PWM控制RGB灯带。儿童在小程序播放音乐时，点击"氛围灯"按钮，小程序通过蓝牙向单片机发送当前音乐的节奏信息，单片机解析后让灯带随节奏呼吸变色。

整个硬件成本：单片机板约20元，蓝牙模块约10元，灯带约15元，杜邦线加面包板约10元，总成本不到60元。这个成本对于高校学生来说完全可以接受，而且比纯软件功能有视觉冲击力，答辩演示时一亮灯，现场氛围都不一样。

6.2 51单片机还是STM32：学生党如何选

如果你完全没接触过单片机，选51单片机（比如STC89C52）更容易起步，因为例程多、教程多、引脚少，不容易烧错线。但51单片机的主频低、RAM小，跑蓝牙协议栈的AT指令解析没问题，做复杂的音乐节奏分析就吃力了。

STM32F103C8T6是Cortex-M3内核，主频72MHz，做简单的FFT频谱分析或节奏检测完全够用。它还可以直接用Arduino的生态工具来开发，对只写过Java/Python的人极其友好。我的建议是：做毕设加分项，选STM32F103C8T6 + Arduino框架，代码量最小，学习曲线最平缓。你用STM32CubeMX配好GPIO和USART，然后写串口解析，整个过程一天就能跑通。

6.3 通信协议与Spring Boot对接思路

单片机并不是直接和Spring Boot通信，而是通过小程序中转。小程序的蓝牙APIwx.openBluetoothAdapter连接蓝牙模块，再用wx.writeBLECharacteristicValue向单片机发送命令。后端只负责把音乐节奏数据推给前端，前端再转发给蓝牙模块。

我设计了一个最简协议帧，避免新手在串口解析上浪费太多时间：

帧头(0xAA) + 命令字(0x01) + 数据长度(1字节) + 灯效数据(1字节) + 校验和(1字节)

例如：AA 01 02 0B A8表示设置红色呼吸模式。单片机端循环读取串口，收到帧头0xAA后开始组包，最后校验和通过才执行动作。这个协议非常简单，但足够体现"通信协议设计"能力。

6.4 演示视频与论文包装建议

硬件联动要在答辩时演示，最好提前录一个展示视频，因为你不能保证现场蓝牙不断连、灯带不熄灭。视频脚本可以这样设计：10秒钟展示网站功能（登录、播放、歌单），10秒钟展示家长控制，10秒钟展示蓝牙控制灯带。节奏明快、重点突出，比现场手忙脚乱点半天强得多。

论文里加一节"系统扩展与硬件联动设计"，配一张系统架构图（硬件端、小程序端、后端三层的连接关系），再贴一段核心串口解析代码。这种内容在毕设论文里很少见，能够直接拉开与"纯管理系统"项目的差距。

7. 从开发到答辩：我踩过的一些坑和补救办法

7.1 上传大文件超时：配置、转存与异步处理

第一次测试上传20MB的音频，Postman等了30秒直接超时。原因是Spring Boot默认的Tomcat限制单次上传文件大小为1MB，MultipartFile直接报错。解决方法是改配置：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 60MB

但这只是第一步。更大的隐患是上传接口同步地把文件写入磁盘，占用了请求线程。如果未来并发上传，服务会卡死。更稳妥的做法是先把文件转存到本地临时目录，然后丢给一个异步线程去处理音频元数据提取，接口立刻返回"上传成功，处理中"。对毕设来说，把配置改好、文件大小校验做好，就已经合格了。

7.2 音频格式与浏览器/小程序兼容性

有一个非常隐蔽的问题：部分用户上传的音频明明是mp3后缀，但实际编码格式是wav或aac，小程序端能播，Web端Chrome播不了。解决办法有两种：一是上传时用前端AudioContext解码测试，识别真实格式；二是后端接FFmpeg，统一转码成标准MP3。对毕设项目，我建议至少做第一层校验，用Java的AudioSystem或第三方库读取音频文件头，判断真实格式和后缀是否一致，不一致就直接拒绝上传。

7.3 日志排查与接口响应体设计

项目里经常出现"接口404了但不知道哪里错"的尴尬场景。Spring Boot默认日志只打印WARN以上级别，很多业务异常不明显。我建议在application.yml里把项目包名下的日志级别改成DEBUG，开发环境能直接在控制台看到SQL语句和异常堆栈：

logging: level: com.example.music: debug

后端的全局异常处理器也一定要有，否则前端拿到的一堆乱七八糟的报错提示会让老师觉得项目很不严谨。统一处理的好处是：任何未预料的异常都会被包装成Result.error("系统繁忙")，真正的异常信息只打印在服务端日志里。这样既安全，又方便排查。

7.4 答辩演示翻车抢救方案

最后一个经验纯属血泪教训。我当年模拟答辩的时候，现场WIFI没连上，小程序白屏了五分钟。后来我总结了三条抢救规则：

• 所有核心流程提前录好视频，网断了、环境崩了直接放视频，不要干等着调Bug。
• 演示时先用Web管理后台，因为小程序真机演示变数最大，如果现场网络不稳定，可以拿着手机走到路由器旁边。
• 提前准备好"如果一个功能挂了，立刻跳到下一个功能"的演示顺序。比如音乐播放挂了，就先去讲家长控制的后台表格，再讲数据库设计PPT。

这些规则看着琐碎，但真到了答辩现场就是救命稻草。你辛辛苦苦做了几个月的项目，如果在演示环节因为网络问题被扣分，太亏了。

回到开头那个问题：这套基于Spring Boot的儿童音乐分享网站，到底难不难？认真按上面这条链路走一遍，你会发现真正有价值的东西不是最后交上去的代码，而是你做需求拆分、表结构设计、接口鉴权、小程序联调、硬件联动的完整过程。哪天你把这些经验写进简历，面试官问起毕设做了什么，你能从上传音频的格式校验讲到蓝牙灯带的协议帧设计，这一关基本就稳了。