企业官网建设流程全解析

第一次接到"基于Java+SpringBoot+SSM音乐分享与交流平台"这个题目，我心里第一反应是：这不就是做个播放器吗？后来真正动手才发现，它和我一开始想的完全不一样。音乐分享平台的核心不在"播放"，而在"分享"和"交流"这两个词上。歌曲上传、歌单创建、评论互动、关注机制、点赞收藏，这些功能加在一起，才撑得起"音乐交流社区"这个定位。整条链路做下来，你会把Java后端开发里最常用的一套东西完整过一遍，所以这个题在课程设计和毕业设计里一直很受欢迎。

这篇内容我尽量按自己的实际开发节奏来写，不按说明书那样一条条列。适合两类人看：一类是打算用这个题做毕业设计或课程设计的同学，另一类是正在学SpringBoot整合SSM、想找个完整项目练手的开发者。下面从需求拆解开始，讲到表结构、核心功能、页面交互、部署调试，最后补一些我踩过的坑和实话。

1. 项目到底在做什么：一个音乐交流社区的需求拆解

1.1 这个平台解决什么问题，给谁用

很多同学看到"音乐分享与交流平台"第一反应是"就是音乐网站嘛"，于是把精力全放在播放页上，做完才发现互动模块空空荡荡。这里有个关键认知：这类项目的目标用户是"想分享音乐并且和其他乐迷交流的人"，不是"单纯来听歌的人"。

所以平台要解决的核心问题有三个。第一，用户能上传歌曲、创建歌单，把自己的品味展示出来；第二，其他用户能听到这些歌，还能评论、点赞、收藏，形成讨论；第三，用户之间能关注，慢慢沉淀出一个社区氛围。管理员角色则是兜底，负责管用户、审核歌曲、清理不当评论。

从角色看，前后台权限要分开。前台用户可以做听歌、上传、评论、点赞、收藏、关注、管理自己的歌单这些事；后台管理员能查看数据统计、禁用违规用户、删除歌曲和评论。这个权限模型不复杂，但它是整个项目的主骨架，数据库设计和接口设计都围绕它展开。

1.2 从标题拆出来的功能清单

我习惯先把标题拆成关键词，再映射到功能，这样不会漏需求。"音乐分享"对应歌曲上传、歌单创建、音乐列表；"交流"对应评论、点赞、收藏、关注；"平台"意味着需要前后台管理、用户体系、数据统计。整理之后，功能清单大致如下。

前台用户功能：

• 注册、登录、退出登录，个人资料修改，头像上传
• 浏览歌曲列表，按歌曲名、歌手名、歌单名搜索
• 歌曲详情页在线播放，歌词展示，播放量统计
• 对歌曲评论，评论支持楼中楼回复，支持删除自己的评论
• 点赞、取消点赞歌曲，查看我点过赞的列表
• 收藏歌曲到歌单，创建歌单、修改歌单、删除歌单
• 关注其他用户，查看关注列表和粉丝列表
• 个人主页：我上传的歌、我的歌单、我的评论记录

后台管理功能：

• 管理员登录，登录拦截校验角色
• 用户管理：查看列表、禁用/解禁用户
• 歌曲管理：审核/下架歌曲，编辑歌曲信息
• 评论管理：删除违规评论
• 基础统计：总用户数、总歌曲数、总评论数、播放量排行

这些功能看着多，但细拆以后都是增删改查加上简单的业务判断，做完一遍刚好把SSM三层架构练熟。

1.3 为什么"交流"比"播放"更重要

如果只做播放功能，那叫"在线播放器"，开发难度也低很多。但这类题目的判定重点通常在互动模块，这也是提交文档时最容易体现工作量的地方。评论表要不要支持楼中楼，点赞用什么样的防重方案，收藏和点赞是不是拆成两张表，关注关系怎么做到不能重复关注，这几个问题在答辩时被问到的概率非常高。

我当时最明显的一个认知转变是在做评论模块的时候。起初我觉得评论就是"往表里插一条数据"，后来发现还得考虑排序、分页、楼层回复、删除之后前端怎么显示"该评论已删除"。到了这一步项目才有了"社区"的感觉。所以你在设计阶段就把互动场景想清楚，后面写代码会顺很多。

1.4 交付物里到底有什么

标题里写了"源码+LW+调试文档+讲解"，这说明它不是纯代码项目，而是完整的学习交付包。LW就是说明文档，重点写需求分析、系统设计、数据库设计、核心功能实现和测试结果；调试文档记录开发过程中遇到的问题和解决方案；讲解一般对应演示和答辩。换句话说，做这类项目不能只把代码跑通，还要能在文档里把"为什么这么做"讲清楚。

我见过不少同学代码写得挺好，一到答辩就讲不出设计理由，最后分数不高。所以下面几节我会刻意把"选型理由"和"设计原因"讲明白，这些内容可以直接吸收到你的LW里。

2. 技术栈选型背后：SpringBoot和SSM到底怎么共存

2.1 技术栈全景

这类项目最常见的组合是：后端用SpringBoot整合Spring MVC、MyBatis，也就是"SpringBoot + SSM"；前端用Thymeleaf配合Bootstrap，或者Vue做前后端分离；数据库用MySQL；构建工具用Maven；开发工具用IDEA。版本上建议SpringBoot 2.7.x，对应JDK8或JDK11，MySQL用8.0，这套组合生态最成熟，网上的参考资料也最多。

我的习惯是SpringBoot版本固定在2.7.18，不轻易上3.x。因为3.x要求JDK17起步，且很多三方starter还不一定兼容，对一个学习型项目来说没必要冒险。依赖管理上统一用Maven，不用Gradle，原因很简单：教程多、报错好搜、大部分同学环境里已经有Maven。

2.2 SpringBoot是壳，SSM才是核心

很多同学对"SpringBoot + SSM"这个说法有疑惑：SpringBoot不是已经把Spring整合进去了吗，为什么还要说SSM？我的理解是，SpringBoot是一个开发框架的"壳"，它负责自动配置、内嵌服务器、快速起步；而SSM指的就是Spring、SpringMVC、MyBatis这三层核心组件。Spring管理Service层的Bean，SpringMVC处理请求和页面跳转，MyBatis负责数据库访问。SpringBoot在这个关系里不是替代者，而是把SpringMVC、MyBatis等组件"包起来"让我们少写配置。

用个生活化的比喻：SpringBoot有点像组装好的品牌整机，开机就能用；SSM是你指定要的三大件——主板、显卡、硬盘，整机里嵌着的还是这些东西。写代码时你依然在写@Service、@Controller、@Mapper注解，依然写MyBatis的XML映射文件，只是不用再手动配置一堆XML了。

落实在代码上，就是在pom.xml里引入MyBatis的SpringBoot启动器，比如mybatis-spring-boot-starter，然后在application.yml里配置数据源和Mapper扫描路径，剩下的交给自动配置。这也解释了为什么目录结构里既有SpringBoot的启动类，又保留着SSM传统的controller / service / mapper / entity分层。

2.3 为什么数据层选MyBatis而不是JPA

数据访问层我用的是MyBatis，而不是Spring Data JPA。原因有两点。第一，MyBatis的SQL是自己写的，表结构、复杂查询、统计排行这些在面试和答辩时好解释，ER图和数据流更直观；第二，MyBatis的动态SQL对分页、条件筛选这类需求非常顺手，排查问题也方便。

对比一下：JPA帮你把简单增删改查省掉，但一旦遇到多表关联、连表统计，要么写JPQL，要么用原生SQL，反而多一道翻译层。对它不太熟的同学还会被懒加载、级联、N+1问题绕晕。对这类学习型项目，MyBatis是更稳妥的选择。

2.4 前端要不要前后端分离

对于毕设或课程设计，我建议默认选Thymeleaf + Bootstrap，不选Vue前后端分离。原因很实在：你省去跨域配置，省去接口联调，Session登录直接生效，项目也更容易打包成一个Jar直接跑。Vue方案确实更贴近企业开发，但它的复杂度会占用你做业务功能的时间。如果你已经熟练Vue，想用前后端分离展示能力，也可以做，但你要额外处理跨域、Token、静态资源部署这些事。我的实际项目和题目要求一致，采用服务端渲染方案，后端返回页面和接口两种数据，交互部分用jQuery，样式用Bootstrap，整体工作量控制在一个人能做完的范围。

3. 数据库设计：一张表背后都藏着什么业务逻辑

3.1 用户与角色设计

用户表是整个平台的基石。我建议字段至少有：id、username、password、nickname、avatar、status（是否禁用）、is_admin（是否管理员）、create_time。username要加唯一索引，登录名不能重复；password不要存明文，哪怕是最普通的项目，也要做加密处理。

用MD5还是BCrypt？我建议用BCrypt，Spring Security Crypto包里直接有现成工具，虽然引入的是Spring Security的子模块，但只用来做密码加密，不会引入全套安全框架。如果项目里不想引额外依赖，就自己写MD5加盐，比如每次注册生成一个随机盐，把盐和密码一起哈希后再存库。至少比明文强很多。

角色判断我这里没有单独建角色表，图省事用了is_admin字段。如果题目要求更复杂的"管理员/普通用户/审核员"三种角色，再考虑独立的role表。用字段还是用表，取决于你系统里到底有几个角色，不要一开始就设计过度。

3.2 音乐内容体系：歌曲、歌手、专辑、歌单

歌曲表常见字段：id、song_name、singer_id、cover_url、file_path、lyric、duration、play_count、create_time。其中duration指的是时长秒数，前端播放器跳转、列表展示都需要它。file_path存的是相对路径，比如/upload/music/xxx.mp3，不要存完整本机路径，否则换电脑部署全挂。

歌手和专辑对小型项目来说可以做简化：如果你只需要展示"歌手名字"，那直接在song表加一个singer_name字段也够用。但为了体现良好的数据库设计习惯，我还是建议拆出singer表和album表，歌曲通过singer_id和album_id关联。这样在答辩时你可以讲"这样设计避免冗余，方便扩展歌手的更多信息"。

歌单是音乐分享的载体。playlist表存歌单的标题、封面、简介、创建人ID；playlist_song表是歌单和歌曲的多对多关系表，存playlist_id、song_id、add_time。这里有一个常见失误：很多人把歌曲直接挂在歌单下，删歌单时把歌曲也删了。正确逻辑是歌单和歌曲是两个独立实体，删除歌单只删关系记录，歌曲本身保留。

3.3 互动数据表：评论、点赞、收藏、关注

评论表核心字段是id、song_id、user_id、content、parent_id、create_time。parent_id为0表示顶级评论，不为0表示这条评论是某条评论的回复。这个设计叫楼中楼，实现简单，前端拿到列表后再按parent_id归组就行。注意content要做长度限制，比如500字，既省存储又防止用户刷屏。

点赞和收藏一定要拆成两张表，因为语义不同，后续统计也不一样。点赞表like_record用user_id + song_id做唯一索引，保证用户对同一首歌只能点一次赞；收藏表favorite_record同理。用唯一索引做防重是性价比最高的方案，比先查询再插入靠谱得多，同时也可以应对并发场景。

关注表follow存user_id（关注者）、followed_user_id（被关注者）、create_time。同样加唯一索引防止重复关注。查询我的粉丝列表时，按followed_user_id反查即可。这里要注意给followed_user_id建普通索引，否则用户量上来之后查询会很慢。

3.4 建表SQL片段参考

下面给两个核心表的SQL，注释我已经写在里面，可以直接参考。

歌曲表：

CREATE TABLE `song` ( `id` bigint NOT NULL AUTO_INCREMENT, `song_name` varchar(100) NOT NULL COMMENT '歌曲名', `singer_id` bigint DEFAULT NULL COMMENT '歌手ID', `singer_name` varchar(100) DEFAULT '' COMMENT '歌手名冗余字段', `cover_url` varchar(255) DEFAULT '' COMMENT '封面图地址', `file_path` varchar(255) NOT NULL COMMENT '音乐文件地址', `lyric` text COMMENT '歌词文本', `duration` int DEFAULT 0 COMMENT '时长(秒)', `play_count` int DEFAULT 0 COMMENT '播放量', `status` tinyint DEFAULT 1 COMMENT '1正常 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_singer` (`singer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

评论表：

CREATE TABLE `comment` ( `id` bigint NOT NULL AUTO_INCREMENT, `song_id` bigint NOT NULL COMMENT '歌曲ID', `user_id` bigint NOT NULL COMMENT '用户ID', `content` varchar(500) NOT NULL COMMENT '评论内容', `parent_id` bigint DEFAULT 0 COMMENT '0为顶级评论，否则为回复的评论ID', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_song` (`song_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

我把singer_name做成冗余字段，不是必须，但可以免掉联表查询，前端歌曲列表直接显示。设计取舍就是这样：规范化和查询效率之间取平衡，只要你在文档里说明理由，就是加分项。

4. 核心功能实现：登录鉴权、文件上传、播放与互动

4.1 注册登录与登录鉴权

登录方案我用的Session配合拦截器，没有引入JWT，因为服务端渲染场景下Session天然合适。流程是：用户提交用户名密码，后端验证通过后把用户对象放进session，接着设置一个拦截器拦截所有需要登录的请求。拦截器里判断session是否为空，为空就跳转到登录页。

注册功能要先查一次username是否已存在，再加密码加密，然后插入用户。很多初学者忽略"查重"这一步，结果数据库报唯一索引错误才发现，不如前置判断给用户友好提示。顺便说一个细节：登录表单的密码传输用HTTPS才安全，本地项目一般HTTP，但后端一定要用加密存储，这是底线。

拦截器核心代码大概长这样：

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

配置类是注册拦截器并放行静态资源：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/", "/song/list", "/song/detail/**", "/css/**", "/js/**", "/img/**", "/upload/**"); } }

管理员的接口还要额外判断loginUser.is_admin，不为true直接返回403页面。

4.2 歌曲上传与本地存储

音乐文件是二进制，不能存数据库，我采用本地磁盘存储。目录结构上，我在项目根目录建了一个upload/music和upload/cover，分别放音频和封面。开发环境用本地路径，后续如果部署到服务器，再通过配置文件把路径抽出来。

上传时前端用表单或FormData提交文件，后端要做两件事：校验类型和限制大小。类型只允许mp3、flac、wav这些常见格式，大小通过Spring配置限制在50MB以内，防止有人把整个压缩包传上来。文件名不要用用户原始文件名，我用UUID或时间戳重新生成，避免中文名乱码和重名覆盖。

音频时限流这里也提醒一句：50MB上限对测试够用了，但如果是毕设演示，尽量传2~5MB的截取片段，别传超大无损音质文件，否则对播放流畅度和存储空间都是压力。

配置文件的multipart参数如下：

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

同时还要配置静态资源映射，让上传的文件能通过URL直接访问：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath = System.getProperty("user.dir") + File.separator + "upload" + File.separator; registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); }

这段配置看起来不起眼，但少了它，上传的歌永远打不开，页面图片全部404，是最容易踩的坑之一。

4.3 在线播放与播放列表

播放功能我直接用的HTML5 audio标签，后端把file_path当作src传给前端即可，不需要自己实现流媒体分发。对学习型项目来说，HTTP静态文件播放已经足够。

播放器的核心难点在于"全局播放条"和"自动连播"。我的做法是在页面底部固定一个audio标签，通过JavaScript控制。歌曲列表的"播放"按钮把当前歌曲数据存入一个全局数组，把audio的src换成当前歌曲路径并调用play()，播放结束时监听ended事件自动切换到数组的下一首。

核心逻辑可以简化成：

<audio id="player" src="" controls style="display:none"></audio>

let playList = []; let currentIndex = 0; function playSong(song) { playList = arguments.length > 1 ? Array.from(arguments[1]) : playList; currentIndex = playList.findIndex(item => item.id === song.id); const player = document.getElementById('player'); player.src = song.filePath; player.play(); } player.addEventListener('ended', function () { if (currentIndex < playList.length - 1) { playSong(playList[currentIndex + 1]); } });

这里的playList需要你在歌曲列表页点击播放时把整页的歌曲数据传进来，否则"下一首"逻辑不会工作。我记得第一次做时只传了当前歌曲，结果每次播完就停止，检查半天才明白是没有维护列表数据。

4.4 评论、点赞、收藏和播放量的实现

评论模块用PageHelper做分页，后端接口接收pageNum和songId，返回评论分页数据。PageHelper用法很简单：

PageHelper.startPage(pageNum, pageSize); List<Comment> comments = commentMapper.selectBySongId(songId); PageInfo<Comment> pageInfo = new PageInfo<>(comments);

这里要注意PageHelper的坑：startPage后面必须紧跟第一条SQL查询语句，中间不能穿插其他查询，否则分页条件会落到错误的查询上。

点赞用唯一索引防重之后，接口变得非常简单。点赞时尝试插入like_record，如果插入成功就给song表like_count加1；取消点赞就是删除记录并减1。用catch捕获唯一索引冲突的异常，返回"你已经点过赞"，比先select判断再insert少一次查询。

播放量自增我放在歌曲详情接口里，每次请求播放详情就执行UPDATE song SET play_count = play_count + 1 WHERE id = ?。简单项目不需要做防刷，也不需要把播放量放进缓存，因为数据量小、瓶颈不明显。但你要在文档里说明：这是为演示便利做的简化设计，生产环境通常会引入Redis或者异步队列。

收藏功能逻辑类似，区别是收藏之后用户有一个"我的收藏"列表页，需要联查歌曲信息展示。

4.5 搜索与首页推荐

搜索用MyBatis的动态SQL实现模糊匹配：

<select id="searchSongs" resultType="entity.Song"> SELECT * FROM song <where> <if test="keyword != null and keyword != ''"> song_name LIKE CONCAT('%', #{keyword}, '%') OR singer_name LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY create_time DESC </select>

首页推荐我没有写太复杂的推荐算法，就是按播放量倒序取前十名，再按最新上传取一批新歌。这种设计足以撑起"热门推荐"和"最新发布"两个板块，也方便答辩时讲清楚业务逻辑。如果你想提高点区分度，可以再加一个"我关注的人上传的歌"列表，用关注表把用户的歌关联出来，这个功能在音乐社区场景里很出彩，实现也不难。

5. 页面设计：让社区感真正落地

5.1 整体页面结构

我用Thymeleaf做服务端渲染，页面分三大块：前台页面、播放器公共组件、后台管理页面。前台页面包括首页、歌曲列表页、歌曲详情页、歌单详情页、登录注册页、个人中心页；后台管理页面包括仪表盘、用户管理、歌曲管理、评论管理。

公共部分抽了两个Fragment：一个顶部导航栏，带搜索框和登录状态；一个底部播放条，全局通栏显示。Thymeleaf的th:replace把公共部分复用起来，改一处全站生效。如果你用纯HTML写十个页面，改导航栏要改十次，那是最痛苦的。

5.2 歌曲详情页与播放器联动

歌曲详情页里，我放了封面、歌名、歌手、播放按钮、歌词和评论区。播放按钮触发前面提到的playSong方法，把当前歌曲加到播放列表。如果有歌单场景，播放列表就是这个歌单的所有歌曲。

歌词展示我是直接把文本按换行拆成数组，然后根据audio的timeupdate事件计算高亮行。这个功能看起来复杂，实际就是读取超过当前秒数的第一行，加一个CSS类变亮而已。第一次做建议简化为"滚动展示全部歌词"，有时间再做逐行高亮。

评论区是一个典型的二级列表：顶级评论按时间倒序排，每条顶级评论下面挂它对应的回复。前端可以用两层循环实现，也可以后端在组装VO时把子评论塞进parent的list字段里。我建议后端组装，前端只负责渲染，逻辑更集中。

5.3 后台管理页面的简洁实现

后台管理页面表格用Bootstrap Table或者手写表格都行。操作按钮无外乎禁用用户、删除歌曲、删除评论。管理员每做一步操作，前端发一个请求，后端执行后返回布尔值或JSON，再刷新当前列表。

有一个细节值得注意：后台和前台要复用同一套模板，但导航栏不同。我会在Controller层统一判断当前用户是不是管理员，然后往Model里塞一个isAdmin标记，导航栏根据标记显示不同的菜单。不要为后台单独建一套页面框架，那样代码量直接翻倍。

6. 环境搭建、部署调试与避坑实录

6.1 开发与运行环境清单

这套项目对机器要求很低。我用的组合是：JDK8，Maven 3.6+，MySQL 8.0，IDEA 2021版本，SpringBoot 2.7.18。如果你用JDK11或JDK17，SpringBoot 2.7也兼容，问题不大。

导入项目的时候注意两个设置：Maven的settings.xml要配好镜像仓库，否则依赖下载很慢；IDEA要设置项目SDK为对应JDK版本，且确认Maven runner的JDK和项目一致。很多同学遇到的"项目能编译但启动报错"，多半是这三个JDK版本不一致导致的。

6.2 打包部署流程

开发完成后打包很简单，在项目根目录执行：

mvn clean package -DskipTests

打包后的Jar在target目录下，直接运行：

java -jar music-community-0.0.1-SNAPSHOT.jar

如果你想指定其他配置文件，用这个命令：

java -jar music-community-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

部署到Linux服务器时，我习惯用nohup后台执行，并把日志输出到文件：

nohup java -jar music-community-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

用Jar方式部署，唯一要注意的是数据库连接配置、上传路径的磁盘权限。Linux下如果还有上传文件的写入问题，检查应用启动用户对upload目录有没有写权限，这是我在服务器上遇到最多的一个坑。

6.3 常见问题排查速查表

我在开发过程中整理了一些高频问题的排查思路，做成表格方便你对照。

还有一个我印象很深的坑：Windows上开发时File.separator返回反斜杠，Linux上返回正斜杠，如果代码里硬编码了路径分隔符，Windows跑得好好的项目一到Linux就找不到文件。所以凡是拼接路径的地方，统一用File.separator，不要写死/或\\。

6.4 调试文档应该记录什么

调试文档不是让你把正常的操作步骤抄一遍，而是要记录"出错现场"。我的习惯是每条记录四段式：错误现象、报错日志、排查过程、最终解决。比如端口占用，我要写清楚怎么查PID、杀掉之后重启，而不是只写一句"换个端口"。

实际开发中80%的报错都是重复的，把这些整理好，一是自己以后接手项目能快速定位，二是交付文档时体现出完整的调试能力。答辩老师看到"遇到问题——定位——解决"的过程，比看到一张全是成功截图的效果好得多。

7. 给打算做同类型项目的人几句实话

7.1 拿到源码后应该从哪里入手

如果你不是从零手写，而是拿到一份现成的源码参考，不要直接打开代码通读。我建议的顺序是：先启动项目，把页面点一遍；再打开LW文档看ER图和系统模块；最后Controller到Mapper逐个看核心流程。先在脑子里建立"页面长什么样"和"接口怎么对"的映射，再读代码效率高得多。

启动项目时如果有数据库脚本，按脚本顺序执行，别贪多一次全跑，遇到外键依赖容易报错。另外先确认配置文件里的数据库账号密码改成你自己的，否则启动必失败。

7.2 这个项目后续还能怎么扩展

如果你做完之后还有余力，有几个扩展点性价比特别高。一个是用Redis做热门歌曲缓存，把播放榜从数据库查询改成缓存查询；另一个是引入OSS或云存储，把本地文件存储替换成对象存储，这是目前企业里最常见的做法；第三个是给评论加一个敏感词过滤器，用前缀树或正则实现，很容易讲清楚。

这些扩展不需要全做，挑一个做深，答辩时的含金量立刻不一样。

7.3 答辩演示的实际建议

演示之前一定要准备一条"核心流程"：注册登录、上传歌曲、播放评论、关注互动、后台管理。走流程时声音不用太大，但要能讲清每一步调用了什么接口、查了哪张表。

评审最常问的问题我都总结了一下：为什么密码要加密存储，为什么不直接用明文；评论和回复用一张表还是两张表，为什么；点赞防重怎么做；歌曲文件为什么存本地而不是数据库；播放量是怎么统计的。这些问题在前面章节基本都讲到了，你只要动手做一遍再回头看，自然就能答上来。

最后再分享一个小经验：这类项目真正拉开差距的地方不在某个炫酷页面，而在数据表之间的关系和边界情况处理。你把一张评论表设计得支持楼中楼，把点赞重复问题用唯一索引优雅解决，把上传路径兼容Windows和Linux，这些细节才是评审能感受到的"完成度"。做项目的过程本身，远比最后演示那几分钟更有价值。