做毕业设计时选一个“乐器社区网站”的题目，算是踩中了一个不错的位置：它比普通的“XX管理系统”更有辨识度，又比纯粹的电商平台好落地，最关键的是技术栈足够主流，SpringBoot+MySQL的组合几乎是面试官和答辩老师最熟悉的搭配。这篇文章我把整个项目的选题逻辑、功能设计、数据库建模、后端接口、小程序接入以及实操中容易翻车的细节一次性讲清楚，希望能给正在做同类题目的同学一条可以直接参考的完整路线。

先说下项目形态。这个题目做出来是两个端：一个面向普通用户的Web端社区网站，一个配套的微信小程序端，用于乐器内容宣传展示。后端统一走SpringBoot+MySQL，小程序端通过HTTP接口与后端通信。整体功能围绕乐器内容展示、用户社区互动、后台管理三条主线展开，覆盖了从内容生产到用户消费的完整链路。

1. 为什么选择“乐器社区网站”作为毕业设计题目

选题这件事在毕设里的重要性常被低估。很多人到最后随便挑一个管理系统凑数，答辩时被问到“你这个项目的难点在哪”就哑火。乐器社区这个题目比较讨巧的地方在于：它既有内容展示型的页面复杂度，又有社区互动型的业务复杂度，两者叠加后自然会引出权限控制、数据关联、文件上传、分页搜索等真实业务问题，每个点都能在答辩时展开说。

1.1 选题思路：热门方向与差异化结合

SpringBoot+MySQL是绝对的主流技术组合，社区里大量现成方案可以参照，遇到问题很容易搜到答案。但纯粹做“乐器资讯展示”又太单薄，所以把社区互动拉进来——用户注册后可以发布帖子、上传演奏视频或图片、评论互动、收藏内容、关注其他用户。于是系统的核心角色就从“单向浏览”变成了“双向参与”，数据模型也复杂到刚好合适，既不会因为太简单而显得没工作量，也不会因为太复杂而做不完。

1.2 业务切入：把“宣传展示”和“社区交流”合并成一个闭环

乐器宣传平台如果只做展示，用户看完就走，没有任何留存逻辑。而加上社区以后，乐器厂商或教学机构可以发布乐器百科、教学视频、活动公告；普通用户可以在下面提问、发帖晒琴、交流心得；后台管理人员负责审核内容、管理用户。这就形成了一个闭环：平台生产内容吸引用户，用户互动产生新内容，新的内容又反过来支撑宣传效果。做毕设时，这个业务故事在论文里特别好写，逻辑链完整，答辩时讲起来也顺。

1.3 项目整体定位与适合人群

这个项目适合后端基础一般、但想在一个完整项目里练习SpringBoot、MyBatis-Plus、数据库设计和前后端联调的同学。难度上属于中等偏下一点，但如果把微信小程序端也纳入进来，工作量会明显增加，能体现出“全栈”的广度。如果你本身有前端基础，建议Web端用Vue搭建；如果前端时间紧张，用Thymeleaf模板渲染也可以，只是社区互动的体验会差一些。我的建议是Web端做完整后台管理+社区展示，小程序端做面向C端用户的轻量化宣传与浏览，两个端共用一套后端接口，这是性价比最高的搭配。

2. 功能模块拆解：用户、内容、社区三个核心闭环

项目功能设计不能拿到手就急着写代码，先把模块图画清楚。我的做法是把系统拆成三个闭环：用户闭环负责账号体系，内容闭环负责乐器信息的生产与展示，社区闭环负责用户之间的互动。三者相互独立又有依赖，代码分层时容易管理，论文的“功能模块设计”章节也可以直接照着写。

2.1 用户端基础模块：注册登录、身份管理、个人主页

用户模块是社区系统的地基。这里要注意一个设计决策：用户身份最好支持两类——普通用户和乐器机构/教师用户，后者的区别在于可以发布宣传性质的内容，普通用户只能发普通帖子。实现方式可以是在用户表里加一个role字段，用普通整型区分即可，不必引入复杂的RBAC权限框架。注册时用户名唯一校验、密码加密存储、登录后签发Token，这三件事是必选项。个人主页需要展示用户发布的帖子、收藏的乐器内容、关注列表，这涉及到三张关联表的查询，也是后面数据库设计的重头戏。

2.2 乐器内容模块：乐谱、乐器百科、视频教学、活动公告

内容模块是整个网站宣传属性的集中体现。我的设计是四种内容类型：

• 乐器百科：展示乐器分类、图片、详细介绍、材质工艺参数
• 乐谱资源：提供上传的乐谱图片或PDF，用户可以预览和下载
• 视频教学：嵌入视频链接或上传视频，配合文字教程
• 活动公告：发布乐器比赛、线下体验活动、优惠促销信息

四种内容类型可以统一建模为一张“内容表”，用type字段区分类型，也可以独立建四张表。我建议用统一内容表加扩展字段的方式，减少表数量，也便于统一管理审核状态。内容发布后默认是“待审核”状态，管理员审核通过才在前台展示，这个状态机逻辑在答辩时是个很好的亮点。

2.3 社区互动模块：帖子、评论、收藏、关注

社区模块是代码量的大头，也是展示业务深度的关键。帖子表需要支持标题、正文、图片组、标签、分类这些字段；评论表需要设计父子层级，也就是回复某条评论的二级评论；收藏表是一个经典的多对多中间表，用户和内容之间的关联；关注表则记录了用户与用户之间的关注关系。这个模块最少涉及四张表的CRUD，还不包括列表查询时关联用户昵称、头像、帖子的图片首图、评论数量、点赞数量这些“附加字段”，每一个都对应一条SQL或一个LambdaQueryWrapper的写法。

2.4 管理后台：内容审核、用户管理、数据统计

后台管理建议单独做一套，不要和前台混在一个Controller里。最简单的方案是做一个独立的Admin模块，管理员登录后可以看到待审核内容列表，一键通过或驳回；可以禁用违规用户；可以查看内容的浏览量和社区活跃度统计。后台的代码量不大，但胜在业务逻辑清晰，答辩时可以重点展示权限控制和状态流转。统计功能用简单的SQL聚合查询就行，不需要引入复杂的数据可视化组件。

2.5 微信小程序端功能裁剪与差异化

小程序端不宜把Web端的全部功能都搬过去，我当时的做法是只保留三个核心入口：乐器展示、内容浏览、个人中心。小程序定位是“宣传窗口”，所以首页放乐器轮播、分类导航、热门内容推荐；发现页放帖子社区列表，支持上下滑浏览；个人中心支持登录、查看收藏和发布的帖子。功能裁剪后小程序端的代码量控制在合理的范围内，前后端联调也不至于拖太久。

3. 技术选型与集成架构：SpringBoot+MySQL+小程序三端如何协作

关于技术选型这个问题，很多同学的思路是先定框架再想理由，这是顺序搞反了。正确的顺序是先明确项目需求，再反过来论证选型，这样论文里“技术选型”这一章才站得住脚。

3.1 后端框架选型逻辑

SpringBoot之所以适合毕设项目，根本原因是它把Spring生态中繁琐的配置自动化了。传统SSM项目需要大量XML配置，光是Spring和MyBatis整合就要写半页配置文件；SpringBoot用起步依赖和自动配置把这一层完全抹平，你只需要引入spring-boot-starter-web就能跑起一个Web服务。做毕设时这不是“懒”，而是把精力集中在业务开发上，这本身就是工程上成熟的做法。配合MyBatis-Plus，单表CRUD连SQL都不用写，分页查询也只需要一个Page对象，开发效率明显提升。

3.2 数据库选型

MySQL属于关系型数据库，最擅长处理这种强关联的社区类业务。用户和帖子之间、帖子和评论之间、用户和收藏内容之间都是典型的外键关联场景，关系型数据库用主外键和中间表就能很清晰地把模型表达出来。相比NoSQL方案，MySQL对事务的支持也让内容审核、用户禁用这类状态操作更可靠。毕设场景下Linux服务器上MySQL 8.0+即可，字符集用utf8mb4，排序规则用utf8mb4_general_ci，可以正常存储emoji等特殊字符。

3.3 小程序端与后端接口的交互模式

小程序端本质是一个独立的客户端，与后端通过JSON格式的HTTP接口通信。小程序内使用wx.request发起网络请求，后端暴露RESTful风格接口。这里要特别注意域名和HTTPS的问题：微信小程序上线要求后台域名必须是备案过的HTTPS域名，本地开发可以在微信开发者工具里勾选“不校验合法域名”来绕过。接口设计上必须约定一个统一的响应体结构，我采用的就是最常见的code/message/data三段式结构。

{ "code": 200, "message": "操作成功", "data": { "token": "xxxx.xxxx.xxxx" } }

3.4 项目目录结构与代码分层

我建项目时习惯按功能分层，而不是简单的MVC三层。基础的分层原则是：Controller只负责接收参数和返回结果，Service负责业务逻辑，Mapper负责和数据库打交道。但社区项目里涉及文件上传、Token鉴权、全局异常处理这些横向逻辑，所以额外增加了config、common、utils等包。一个比较清晰的目录参考如下：

src/main/java/com/example/musicspace/ ├── common/ // 统一响应体、全局异常、常量 ├── config/ // 跨域配置、拦截器配置、文件上传配置 ├── controller/ // 接口层 │ ├── admin/ // 后台管理接口 │ └── api/ // 前台接口 ├── service/ // 业务逻辑层 ├── mapper/ // MyBatis-Plus数据访问层 ├── entity/ // 数据库实体 ├── dto/ // 接收参数的DTO ├── vo/ // 返回给前端的视图对象 └── utils/ // JWT工具、文件工具等

这样一个目录结构在论文的“系统设计”章节里非常好描述，每层职责一目了然，答辩老师问某一层的代码在哪，你半分钟内就能找到。项目经验上，把Entity和VO分开、避免直接把数据库实体返回给前端，这一点值得落实。数据库字段是下划线命名（如created_time），而Java里是驼峰命名（如createdTime），MyBatis-Plus开启驼峰映射后可以自动转换，省去大量手工映射代码。

4. 数据库设计：关系型建模的思路与细节

数据库设计是毕设项目里最能体现“设计感”的部分，也是论文的必要章节。我做这个项目时一共规划了8张核心数据表。这里把关键的表结构和设计理由展开讲一下。

4.1 核心数据表设计

首先是用户表user。字段包含id、username、password、nickname、avatar、role、status、created_time。password字段存储的是BCrypt加密后的密文而不是明文，status字段用于标记用户是否被禁用。其次是内容表content，字段是id、user_id、type、title、cover、content、status、view_count、like_count、created_time。type用来区分是乐器百科、乐谱、视频还是活动。

帖子表post结构类似内容表，额外增加category_id、images字段，images可以用JSON字符串存一组图片路径。评论表comment需要设计parent_id字段，为0表示是一级评论，否则表示回复的是某条评论。标签表tag乐谱表note可以单独记录谱子文件的存储路径、上传用户ID和下载次数。收藏表favorite和关注表follow都是典型的两列关联关系。

4.2 关联关系设计

关联关系的核心是用中间表。收藏表favorite只有三个字段：id、user_id、content_id，加一个唯一索引uk_user_content(user_id, content_id)保证同一个用户不能重复收藏同一个内容。关注表follow是id、user_id、follow_user_id，同样加唯一索引。帖子的分类我建议单独建category表或直接用字段存分类名，二选一。考虑到后续分类管理扩展，建议建表更规范。

4.3 容易忽略的索引与字段设计

这是一个经验点：很多人建表之后不索引，数据量小的时候没问题，但一旦帖子数量过几百条，列表页按时间倒序查询就会明显变慢。我当时在post表的created_time字段上建了普通索引，在content表的status和created_time上建了联合索引，这样后台审核列表按状态筛选、前台按时间排序都能走索引。还有一点容易被忽略的是created_time这类字段建议用datetime类型，并且设置默认值CURRENT_TIMESTAMP，这样插入时不需要手动传时间。

CREATE TABLE `post` ( `id` int NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL COMMENT '发布人ID', `category_id` int DEFAULT NULL, `title` varchar(100) NOT NULL, `content` text, `images` json DEFAULT NULL, `view_count` int DEFAULT 0, `like_count` int DEFAULT 0, `comment_count` int DEFAULT 0, `status` tinyint DEFAULT 1, `created_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_created_time` (`created_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个设计细节值得说明：comment_count字段属于冗余设计。理论上评论数可以通过SELECT COUNT(*) FROM comment WHERE post_id = ?实时算出来，但社区列表页往往需要展示每条帖子的评论数，如果每次都去聚合查询评论表，十条帖子就要执行十条子查询，性能压力会集中在评论表上。用冗余计数字段，发布评论和删除评论时对该字段做递增递减即可，用一次UPDATE换一次COUNT查询，是社区类业务里常见的空间换时间的做法，答辩时讲出来会显得你有真实业务考量。

5. 后端核心实现与关键代码片段

这一部分挑几个后端开发中“含金量”较高的实现点展开，包含统一响应体、登录鉴权、帖子发布、文件上传这四个关键环节。每个环节都有毕设答辩时可说的设计理由。

5.1 统一返回结果与异常处理

前端不管Web还是小程序，都希望后端接口返回结构一致。我定义一个Result<T>类，统一返回code、message、data三个字段。同时用@RestControllerAdvice做全局异常捕获，业务异常抛出BusinessException，系统异常统一返回500，校验异常返回参数错误信息。

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

全局异常处理的核心价值在于：不让任何一条异常堆栈直接暴露给前端，而是统一包装成用户能看懂的中文提示。比如文件上传超限时抛出“文件大小不能超过5MB”，而不是返回一大串英文异常堆栈。这个设计在答辩时也可以作为“系统的健壮性设计”来讲述。

5.2 用户登录与Token鉴权

登录接口比较简单，校验用户名密码，通过后签发一个Token返回前端。Token我采用的是JWT方案，因为它是无状态的，后端不需要存储会话信息。JWT由三段组成：Header、Payload和Signature。Header声明算法，Payload存放用户ID、用户名、过期时间，Signature用服务端密钥对前两段签名。前端每次请求时在Header里带上Authorization: Bearer token，后端通过拦截器解析Token并获取当前登录用户。

关于Token过期时间有个建议：Web端可以设置2小时过期，小程序端可以设置7天，因为在手机上用户不希望频繁重新登录。如果过期时间设置太短，用户体验会很差；太长又有安全隐患。折中方案是引入Refresh Token机制，但毕设阶段做一个Token就够，过多的机制会在论文里占据篇幅还不一定讲清楚。

@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 ")) { token = token.substring(7); // 解析token，如果过期或非法，抛出异常 Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } throw new BusinessException(401, "未登录或登录已过期"); } }

拦截器配好以后，只需要在WebConfig里注册，并指定拦截路径和不放行路径。登录接口、注册接口、首页内容浏览接口等公开接口要放行，个人主页、发布帖子、收藏、关注等接口必须走拦截器。

5.3 社区帖子发布的核心实现

帖子发布本身不复杂，一张表插入数据而已。但有两个细节要做到位。

第一个细节是发布后处理首图。前端传一个图片URL数组过来，后端存储时把第一张图提取出来作为列表页的封面图，方便列表页展示。这个逻辑放在Service层完成，而不是让前端二次上传。

第二个细节是内容安全审核。最简单的方式是给帖子加status字段，默认0为待审核，管理员审核通过后变为1，驳回为2。前台查询列表时只查询status=1的内容。这个规则虽然简单，但构成了后台的核心业务流。

5.4 文件上传与静态资源映射

做乐器社区必然涉及图片上传，比如用户上传头像、发帖传图。后台上传接口接收MultipartFile，把文件保存到本地磁盘的某个目录，然后返回可访问的URL。这里有个毕设容易踩的坑：文件保存在upload目录下，但默认情况下SpringBoot无法直接通过URL访问磁盘上的文件，必须在配置类中做静态资源映射。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

文件命名上建议用UUID重新生成，避免用户上传的文件名和他人冲突，也避免中文名或特殊字符在URL里引起编码问题。保存路径也建议按日期分目录，比如/upload/20250515/xxxx.jpg，这样一段时间后清理过期文件很方便。

5.5 MyBatis-Plus的使用经验

MyBatis-Plus最核心的好处是单表CRUD零SQL，比如根据ID查询、新增、更新、删除都有现成方法。复杂查询可以用LambdaQueryWrapper构造条件，比如查询某分类下的已审核帖子并按时间倒序：

LambdaQueryWrapper<Post> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Post::getCategoryId, categoryId) .eq(Post::getStatus, 1) .orderByDesc(Post::getCreatedTime); Page<Post> page = postMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);

关联查询（如帖子列表需要显示发帖人昵称和头像）有两种处理方式：一是直接查出Post列表后，在Service中遍历，用user_id批量查用户并组装到VO；二是写自定义SQL用JOIN。数据量小时两者性能差距不大，我更推荐第一种，代码可读性强，不用维护复杂SQL。这里有一个小技巧：批量查用户时不要用for循环逐个查询，而是用selectBatchIds一次把所有用户ID查出来，再组装Map，这样只执行一条SQL，遍历组装时的性能开销也远低于多次数据库往返。

6. 微信小程序端的接入要点与Web端的差异

小程序端和Web端共用后端接口，所以大部分代码是纯前端逻辑。但接入过程中有几个差异点必须处理，否则前后端联调会磕磕绊绊。

6.1 小程序登录流程

小程序的登录比较特殊，不能直接用用户名密码，而是调用微信官方API。完整流程是：前端调用wx.login获取一个临时code，把code发送到后端，后端拿着code去微信服务端换取openid，再根据openid找到或创建用户，最后返回一个自定义登录态Token给前端。但做毕设时有个更省事的方案：如果不需要微信真实用户体系，可以不用wx.login，而是直接用账号密码登录。我用的是折中方案：登录页支持账号密码登录，登录成功后把Token存入wx.setStorageSync，每次请求时从本地取出Token放到请求头里。真正接入wx.login需要注册小程序账号，还需要服务器能访问微信的接口，这些前置条件在毕设环境下不一定都满足，所以先做账号密码版稳妥。

6.2 请求封装与统一拦截

小程序不像Axios有默认拦截器，需要自己封装一个request.js，把Token注入、错误码拦截、加载动画都统一处理。基本结构是：

const request = (url, method = 'GET', data = {}) => { return new Promise((resolve, reject) => { const token = wx.getStorageSync('token'); wx.request({ url: baseUrl + url, method, data, header: { 'Authorization': token ? 'Bearer ' + token : '' }, success(res) { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }); } else { wx.showToast({ title: res.data.message, icon: 'none' }); reject(res.data); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); };

统一封装的最大好处是：新增接口时不用重复写token注入和错误处理，一旦后端改了错误码，只需在封装层改一处。

6.3 列表加载与图片占位细节

小程序端的社区列表，我用了onReachBottom触发分页加载。全局维护pageNum和pageSize，下拉刷新时重置pageNum=1，上拉加载时pageNum++，把新内容concat到列表数据后面。这里有个体验上的细节：图片加载慢会导致布局闪烁甚至抖动，所以在image组件上尽量设置固定宽高比，同时用mode="aspectFill"保证图片裁剪后填满容器。乐器的图片大多数是竖构图，在列表里固定为三比四的比例观感更统一。

小程序端的另一个差异点是导航方式。Web端可以用router.push传参，小程序跳转详情页时需要用navigateTo拼接查询参数。由于URL长度有限制，传复杂对象时最好先存到全局变量或Storage，再通过ID读取。比如帖子详情页只需要传一个postId，进入详情页后根据这个ID向后端请求详情数据，这种模式也利于详情页下拉刷新。

7. 开发过程中踩过的坑与完整排查过程

这部分是真正的经验干货，也是当初开发过程中耗费时间最多的地方。每一条我都把根因和排查过程写清楚，方便你在遇到同类问题时快速定位。

7.1 MySQL时区问题导致的连接报错

第一次启动项目访问数据库接口时，直接报The server time zone value is unrecognized or represents more than one time zone。当时第一反应是查看MySQL连接串的配置，发现serverTimezone没有设置。这个问题的本质是：MySQL 8.0 默认时区用的系统时区，而JDBC驱动则需要明确的时区参数才能处理日期类型的转换。解决办法是在application.yml的连接URL上加上serverTimezone=Asia/Shanghai：

url: jdbc:mysql://localhost:3306/music_space?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

这个问题的排查价值在于提醒你：MySQL 5.x升级到8.x后，很多默认行为都变了，如果直接套用老项目的配置文件，很容易在环境层面浪费一晚上调试时间。

7.2 跨域导致前端请求被浏览器拦截

前端用Vue开发时，浏览器里发起请求一直报CORS错误。问题是后端没有允许跨域访问。浏览器出于安全策略，默认会拦截跨域请求。解决方式是在后端配置跨域规则，最简单的方式是实现WebMvcConfigurer的addCorsMappings方法。

@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的区别。从SpringBoot 2.4版本开始，allowCredentials(true)时不能再用allowedOrigins("*")，必须用allowedOriginPatterns("*")，否则启动时会直接报错。

7.3 文件上传大小超限的坑

开发完成后我尝试上传一个稍微大一点的视频，结果后端直接抛异常。查看控制台日志，发现是MaxUploadSizeExceededException。SpringBoot内置的上传大小限制默认只有1MB，做乐器宣传平台必然要传图片和视频，1MB显然不够。需要在配置文件中修改：

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

这里比较容易忽略的是max-request-size，如果只设置max-file-size，多文件上传时总大小超过请求限制依然会报错。修改完之后，还要配合前面提到的全局异常处理，把上传超限的异常转换为友好提示。

7.4 小程序真机调试中请求本地后端失败

在小程序开发者工具里调试正常，但手机扫码真机预览时所有请求都失败。根因是：开发者工具有“不校验合法域名”选项，真机预览则会严格校验，而本地开发环境根本没有HTTPS域名。排查过程是先在开发者工具里关掉“不校验合法域名”复现真机环境，确认是域名校验问题，接着逐一检查：后端是否监听在局域网IP端口>小程序请求URL是否填写了局域网IP>微信公众号平台里是否配置了合法域名。最终解决办法是：在开发者工具中开启“不校验合法域名、TLS版本以及HTTPS证书”选项，同时确保手机和电脑处于同一局域网。如果后端部署到服务器并配置了HTTPS域名，则需要在微信公众平台配置request合法域名。

这条排查过程让我意识到：小程序的网络请求链路看着简单，实际上每一层都有校验机制，项目联调时先确认环境配置，再检查代码，比盲目改代码高效得多。

7.5 评论计数不一致的问题

早期实现评论功能时，评论表写完直接通过子查询计算数量并返回，接口倒是正常，但列表页每十条帖子就需要额外十条COUNT聚合查询，数据库压力大。后来改成帖子表增加comment_count字段，每次插入评论时执行UPDATE post SET comment_count = comment_count + 1 WHERE id = ?，删除评论时反向减一。这样列表接口不再做子查询，评论数直接从帖子里拿。这里有一个容易遗漏的坑：如果用户删了帖子但没有同步删除评论表数据，会出现评论残留。我在Service层删除帖子时同时删除该帖子下的所有评论，再更新相关计数，用@Transactional事务保证一致性。这个优化点放到论文里，就是“系统性能优化”章节一个很实际的例子。

8. 关于毕设文档、答辩准备与远程调试的经验之谈

毕设做完了，代码能跑通，只算完成一半。另一半是文档和答辩。很多同学项目做得不错，但论文表述混乱，导致答辩时完全展示不出工作量。乐器社区这个题目在论文上其实是很好写的，因为它的业务故事完整，系统层级清楚，技术点也合理。分章节写的时候，重点突出这几块内容即可：选题背景与意义、需求分析、系统设计、数据库设计、系统实现、系统测试。其中系统设计和数据库设计是最核心的部分，需要大量截图配合：功能结构图、ER图、时序图、核心界面截图、接口测试截图。这一部分足够撑起篇幅。

答辩准备上，建议提前准备好三个层面的问答：一是技术选型类问题，例如“为什么用SpringBoot”“为什么用MyBatis-Plus”“为什么用MySQL”；二是业务流程类问题，例如“帖子发布到前台展示经过了什么流程”“用户收藏是如何实现的”“后台审核逻辑是怎样的”；三是环境部署类问题，例如“项目如何部署到服务器”“如果线上运行会遇到什么问题”。这三个类别的每个问题都要能随口答上三五句。还有一个实际经验：答辩前把项目的启动方式写在文档里，包括数据库初始化脚本、后端启动命令、前端构建命令。很多同学现场演示时因为数据库没起来或端口冲突卡住，白白扣分。

关于远程调试这件事，我也想多说一句。我在项目开发过程中找了同学帮忙做交叉测试，我当时才发现一个很有意思的情况：别人拿到你的项目时，最常遇到的不是代码逻辑问题，而是环境配置问题——JDK版本不对、MySQL版本差异、配置文件里的密码不同、端口被占用。所以项目里一定要附带一个完整的README.md，从环境要求、数据库初始化、后端配置修改、启动命令到前端构建，每一步都写清楚。这不仅是给别人看的，也是给你自己一个月后回看的。我在自己的项目交付文档里还额外放了演示视频和测试账号，极大方便了后期自检和他人检验。

最后再分享一点关于“全定制”的个人看法。毕设领域里“定制”意味着要根据你实际的技术水平和兴趣方向去适配，而不是直接套模板。一套代码如果只是能跑，但你完全讲不清里面的表关系、接口逻辑和部署过程，到答辩时反而会成为负担。真正有价值的做法是：拿一套成熟的参考实现作为起点，然后自己完整地走一遍从需求分析到设计、编码、测试的流程，把每一个模块都吃透。我在做乐器社区这个题目时，从搭建骨架到最终功能完善用了两周多，反复改了好几轮，但收获确实比看十遍教程还要实在。

这个题目的可扩展空间其实不小。如果你做完基础版本后还有时间，可以继续加推荐算法、消息通知、在线预约试琴等功能，每一个方向都能让项目在评优时有更多亮点。做毕设这件事，选对题目等于成功了一半，剩下的就是把每一步都走扎实。