每年到了毕设季，总有一堆同学在选题上卡壳。Java方向翻来覆去就那几个经典题目，图书馆管理系统、商城系统、宿舍管理系统，做到最后自己都腻了，答辩老师看了几百遍也审美疲劳。今天想跟各位聊的这个选题，是我这两年带毕业设计时印象比较深的一个方向：基于SpringBoot的校园资讯分享平台，也叫校园信息共享系统。这题目既没烂大街到毫无新意，又没冷门到无从下手，技术栈正好卡在SpringBoot + MySQL这条最稳妥的JavaWeb路线上，特别适合想踏实做一个完整项目、认真写完论文、顺利通过答辩的本科同学。
这个系统说白了就是给校园里做一个“信息集散地”。同学们可以发布校园新闻、活动通知、失物招领、二手闲置、拼车拼单这些信息，其他人可以浏览、搜索、评论、收藏、点赞。管理员在后台审核内容、管理用户分类。业务逻辑清晰，功能边界明确，数据关系不复杂但足够撑起一篇像样的毕业论文。而且这类系统有真实使用场景，讲起来不空洞，演示时也容易出效果。
这篇内容主要面向正在选题的应届毕业生、打算转行Java开发的自学者，以及想带学生做项目的导师。我会把整个系统的设计思路、数据库结构、核心模块实现、环境配置、调试排错，以及论文和答辩准备的要点全部拆开讲一遍。资料包里附带的源码、MySQL脚本、文档、调试记录和代码讲解，对应着下文提到的每个环节，拿到手之后能帮你快速跑通项目，也能让你真正理解每一行代码和每张表的来龙去脉。
1. 为什么校园资讯分享平台是个“聪明”的毕设选题
1.1 选题难度和评分点的平衡
先说说选题思路。很多同学选毕设题目，要么选个纯管理系统，需求简单、页面朴素，代码没难度但也没有亮点；要么一上来就想搞什么微服务、高并发、分布式，技术名词堆了一堆，最后自己写不出来，答辩也圆不回来。这两种极端每年都有大量翻车案例。
校园资讯分享平台恰好落在中间。从业务体量上看，它比普通的管理系统多了一层“用户生成内容”的互动逻辑，但数据量级和并发压力又完全在单机单体架构的舒适区内。从评分角度讲，毕设评分通常看三个维度：工作量是否饱满、技术应用是否恰当、论文表达是否清楚。这个项目天然具备饱满的工作量，因为功能点可以拆得很细：用户端有注册登录、资讯浏览、分类筛选、搜索、发布、详情、评论、点赞、收藏、个人中心；管理端有用户管理、资讯审核、分类管理、轮播图管理、数据统计。每个功能对应一个Controller、一组Service、几张表，工作量肉眼可见地充实。
同时，技术应用不浮夸——SpringBoot是主流框架，MySQL是标配数据库，JWT做登录鉴权，MyBatis-Plus操作数据库，这套组合毕业后写进简历也是真实可用的技能，不是那种“为了毕设而毕设”的玩具技术。答辩时老师问你为什么选这个框架，你可以理直气壮地说：因为它在业界应用最广泛、资料最全、生态最成熟，我这套代码生产环境也能直接改改用。
1.2 业务场景的真实性和延展性
这个题目还有一个隐形优势：业务场景真实。校园资讯本身就存在于每个高校的日常生活中，不管是学工部发通知、社团搞活动、学生在二手群出闲置，本质上都是信息分发与共享。你做系统的过程中，天然知道业务需求是什么、字段该怎么设计、界面应该长什么样，不用靠猜，调研和需求分析章节不难写。
延展性也好。如果一个同学想把项目做得更出彩，可以往上加Redis缓存热点资讯、加Elasticsearch做全文搜索、加WebSocket做消息通知、部署到云服务器上用Nginx代理、把前端换成Vue分离式开发。这些是加分项，不影响主线功能的完整性。即便不加，主体内容也足够撑起一篇8000到12000字的毕业论文。
1.3 你拿到源码之后应该怎么对待它
再说说“附源码、mysql、文档、调试+代码讲解”这类配套资料的使用方法。很多同学拿到代码的第一反应是打开IDE直接点运行，跑通了就以为万事大吉，结果答辩时老师随便问一个“你这登录接口怎么鉴权的”就卡壳了。我强烈不建议这么干。
正确姿势是这样的：第一步，先看文档和数据库脚本，搞清楚项目有哪些表、表之间什么关系；第二步，把项目跑通，用Postman或者浏览器把每个接口过一遍，跟数据库里的数据对应起来；第三步，把代码讲解视频或者文档对着源码一行行看一遍，重点看登录注册、Token校验、发布资讯、分页查询这几个核心链路；第四步，自己动手改需求，比如给资讯加一个置顶功能、给评论加分页，改完能跑通，这套代码才算真正变成你的东西。整个下文都会围绕这四个步骤展开，各位可以当作一份使用地图来读。
2. 系统整体设计与技术选型解析
2.1 技术栈选择背后的逻辑
项目选用的是SpringBoot + MySQL的组合，配套Maven做依赖管理、MyBatis-Plus做数据访问、JWT做无状态登录。这套选型基本是目前JavaWeb单体项目最主流的方案，没有之一。
为什么不用SSH（Struts+Spring+Hibernate）老框架？因为已经过时了，学了对就业没用，而且配置繁琐。为什么不用SpringCloud微服务？因为校园信息共享这个业务体量，微服务的注册发现、网关路由、配置中心、分布式事务这些组件大多是负担而不是助力。微服务解决的是团队协作、独立部署、横向扩展的问题，而你一个人写的单体应用用不上这些，反而会把项目复杂度拉高到无法收场的地步。事实上很多工作了三五年的Java工程师，日常写的还是SpringBoot单体+MySQL这套。
MyBatis-Plus值得展开说一下。它是在MyBatis基础上做的增强工具，最核心的价值是单表CRUD不用写SQL。你定义一个实体类，继承一个BaseMapper，插入、删除、按ID查、分页查这些方法就全都自动有了。对毕设项目来说这意味着两件事：第一，你少写了大量重复的SQL，开发速度肉眼可见地加快；第二，代码里没有一堆XML映射文件，论文里展示核心代码时可读性更好。复杂查询——比如按标题模糊搜索、按分类和状态组合过滤——依然可以写自定义SQL，MyBatis-Plus完全支持这种混合模式。
2.2 单体架构下的项目分层
项目采用经典的四层结构，这不仅是个人习惯，也是行业里最通用、面试官和答辩老师最认可的结构。
Controller层负责接收HTTP请求、参数校验、返回JSON结果。Service层处理业务逻辑，比如注册时查重用户名、发布资讯时校验内容合法性、管理员审核时更新状态。Mapper层也就是数据访问层，负责与MySQL交互。Entity层定义和数据库表字段对应的实体类。四层各司其职，改起来互不干扰。
举个例子说明分层的价值。假如需求变了，管理员审核通过后要自动给用户发一封邮件。没有Service层的代码，你得在Controller里拼逻辑，改起来很乱；有了Service层，你只需在审核这个方法里加一个邮件通知的调用。这就是分层设计最朴素的道理：每层只干自己该干的事，系统才有演化的余地。
2.3 前端方案的选择：服务端渲染还是前后端分离
这个项目资料包里的前端有两种做法，一种是用Thymeleaf服务端渲染，另一种是Vue做的半分离页面。我跟学生沟通时的建议是这样的：如果你Java基础一般、时间紧张，优先用Thymeleaf方案，把后端精力放在业务逻辑上；如果你前端基础好、想展示更多技能，就上前后端分离，后端只写RESTful接口，前端用Vue+ElementUI搭页面。
坦率地说，毕设答辩老师最关心的是后端设计和工作量。前端只要界面干净、交互流畅、能完整演示功能，就足够了。不少同学花了两周调Vue组件样式，后端只留了一堆没跑通的接口，最后得不偿失。后端代码的质量才是论文的核心素材，这点务必牢记。
2.4 核心功能模块总览
把整个系统的功能地图先铺开，后面逐个拆解。用户端包含注册登录、轮播图、资讯发布、资讯分类展示、资讯详情、评论、点赞、收藏、搜索、个人中心。管理端包含管理员登录、用户管理、资讯审核与下架、分类管理、轮播图管理、数据概览统计。
对应到数据库，这些功能映射为六张左右的表：用户表、资讯表、分类表、评论表、点赞表、收藏表。有同学会问，点赞和收藏能不能合并到一张表里？我的建议是分开。点赞是幂等操作，重复点击要取消，收藏也是同理，但两者的业务语义不同：点赞代表“我觉得好”，收藏代表“我想以后看”，统计口径也不一样，分开写代码更清晰。这是业务设计的一个小细节，论文里可以多写几句。
3. MySQL数据库设计与核心表结构
3.1 建表之前先理清实体关系
数据库设计是答辩时最容易追问的环节，也是论文里占篇幅比较大的章节。推荐用ER图先梳理实体和关系：一个用户拥有多个资讯，一个资讯属于一个分类，一个用户对一篇文章可以写多条评论，用户可以点赞和收藏多个资讯。这些关系用外键逻辑关联，但在实际表结构设计上并不需要物理外键，而是用逻辑外键关联，也就是业务字段存的ID。这样做的好处很多，比如删除父表数据不被限制、插入数据更快、避免外键约束导致的各种报错。业界普遍的观点是：互联网项目不建物理外键，依靠应用层保证数据一致性。你在论文里这么写，老师会觉得你是了解过实践的。
3.2 用户表设计要点
用户表字段是基础。id主键自增、用户名username唯一、密码password、昵称nickname、头像avatar、手机号phone、邮箱email、角色role、状态status、创建时间createTime。
密码必须加密存储，使用BCrypt算法。千万不能明文保存，这一点既是工程常识，也是答辩老师非常爱问的考点。你可以在论文的“安全性设计”一节专门写：BCrypt是加盐哈希算法，每次生成的哈希值都不一样，即使两个用户密码相同，存储的密文也不同。登录校验时用matches方法验证，代码里只有一两行，但体现的安全意识很值钱。
角色字段用admin和user两个值区分管理员和普通用户。为什么不单独建一张角色表？因为这个系统的角色是固定的、没有权限树，一张表和两个枚举值就够了，建角色表反而过度设计。答辩时如果老师问“如果以后要扩展多种角色怎么办”，你回答加一张角色表和角色-权限中间表即可，说明你理解扩展方向就行。
3.3 资讯表的设计与索引规划
资讯表是核心业务表，字段包括：id、用户ID、分类ID、标题、封面图、正文摘要、正文内容、状态status、浏览量viewCount、点赞数likeCount、收藏数favoriteCount、是否置顶、发布时间。
状态字段建议用整数枚举：0表示待审核，1表示已发布，2表示已下架，3表示审核未通过。发布资讯进入待审核，管理员审核通过后状态变为已发布，用户端只能看到已发布的数据。这个流程能体现内容安全管控，也是一个可以拿来讲的亮点：平台不是所有内容直接展示的，而是有人工审核节点。
索引规划方面，常规查询主要围绕几个维度：状态+分类ID（前台按分类浏览）、标题（模糊搜索）、用户ID（我的发布）、创建时间（按时间排序）。建议对status、categoryId、userId分别建索引，组合查询时MySQL会自动选择合适的索引。搜索如果只用LIKE '%关键字%'，数据量上来之后性能会明显下降，论文里可以提一句：如果后期数据量增大，可引入全文索引或Elasticsearch，作为系统展望。
3.4 评论、点赞、收藏三张表的微设计
评论表字段有id、资讯ID、用户ID、父评论ID、内容、创建时间。父评论ID用于支持一级评论和回复的嵌套关系。做二级评论是往上有深度的功能，如果只做一层评论也没问题，但二维结构的对话效果明显更好。
点赞表字段最精简的就是id、用户ID、资讯ID，加一个联合唯一索引。为什么不用单独一张表存总点赞数？因为点赞总数对应的是热点数据，每次都COUNT(*)虽然也能跑，但查询压力是明显的。表里冗余一个likeCount字段，每次点赞操作时用update语句自增或自减，列表页直接查冗余字段，性能层面更合理。这就是反规范化设计的一个典型应用，写进论文的数据库设计章节会很有说服力。
收藏表结构和点赞表类似。这里有个坑要特别提醒：点赞和收藏操作都要原子化，不能让“插入记录”和“数量自增”两个动作中间出现断层。建议在Service层方法上加@Transactional，保证同事务内一起成功或一起回滚。别小看这个注解，答辩提问“并发操作怎么保证一致”时，这就是答案的一部分。
3.5 MySQL安装踩坑实录：从官网下载到Navicat连接
毕业季收到最多的求助信息，一半以上是“数据库连不上”和“SQL脚本导入报错”。MySQL的安装配置本身是个大文档，我不拉长篇幅，只讲最容易翻车的地方。
官网下载MySQL Installer时，选MySQL Community Server版本，安装类型选Server only即可。安装过程中要设置root密码，务必记好。Windows服务安装完成后，连接时最常用的工具是Navicat for MySQL。很多同学装的是Navicat 16这种版本，如果没有正版授权就别提什么破解的事，直接用命令行客户端或者开源的DBeaver完全足够，不需要花心思去折腾额外的东西。
常见的连接报错有两个。第一个是“Client does not support authentication protocol requested by server”这个经典问题，原因是用MySQL 8.0以上的默认认证插件caching_sha2_password，老客户端不认。解决办法是把用户认证插件改成mysql_native_password，执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';再FLUSH PRIVILEGES。第二个是“Public Key Retrieval is not allowed”，在Navicat连接配置里找到“高级”或者连接参数选项，勾选允许公钥检索。这两个报错每年能拦住一大批人，建议直接把解决办法存进自己的笔记里。
还有同学会碰到错误代码e0434352这类问题，这其实不是MySQL的错误码，看起来更像Windows系统层面的运行库报错。排查方向有两个：一是检查必备的VC++运行库是否齐全，二是如果用的是绿色版MySQL，确认初始化目录的权限是否完整。总之遇到启动失败，先去Windows事件查看器看详细信息，別盲目重装。
4. 核心功能模块的实现与代码逻辑
4.1 注册登录与JWT鉴权
这套系统的登录认证用的是JWT，也就是JSON Web Token。用户登录成功后，后端生成一个签名字符串返回给前端，前端在后续请求的Header中带上这个Token，后端解析验证通过后就能识别用户身份。JWT是无状态的，服务器不需要存Session，这给前后端分离部署提供了很大便利。
生成Token用现成的库，比如jjwt或者hutool。核心逻辑是：构建一个JWT时设置用户ID、用户名、过期时间，用密钥签名。写一个拦截器或过滤器，对需要登录的接口统一从Header取Token，解析失败返回401未认证，成功就把用户ID放到请求上下文中。有一个容易忽略的细节：把密钥写死在代码里是不安全的，正确做法是放进application.yml配置文件中，通过@Value读取。论文里加一小段“安全加固”描述，答辩时能主动展示你的工程素养。
密码的存储和校验用BCrypt，注册时对明文密码进行加密，登录时调用匹配方法校验。这个方案的好处是同一密码每次加密结果不同，即使数据库泄露，也无法直接反推出原文。有同学图省事用MD5加盐，我建议不要用。不是MD5不能做，而是BCrypt在业界已经成了默认规范，你写代码时也应该跟随当前更被认可的做法。
4.2 校园资讯发布与审核流转
资讯发布流程是核心业务链路：用户填写标题、选择分类、上传图片、填写正文，提交后数据状态为待审核。管理端列表能看到所有待审核的资讯，点击通过后变为已发布状态，点击拒绝则要填写原因，用户可以查看拒绝原因并修改后重新提交。
这个流程设计有一个好处：它让系统更像一个“正规的产品”，而不是学生作业。答辩时可以这样阐述核心思路：平台必须对信息进行把关，校园资讯平台的内容面向全校师生，如果没有审核机制，就会出现垃圾广告、错误信息甚至违规内容，所以设计了待审核、已发布、已下架的三态流转机制。
代码实现上，发布接口要校验分类ID是否存在、标题不能为空、敏感词过滤可以预埋一个敏感词工具类。审核接口要注意幂等：同一篇资讯不能重复审核通过，否则状态字段会被覆盖。加一个前置判断，当前状态不等于待审核就拒绝操作，这个小逻辑能避免很多边界问题。
4.3 分页查询与多条件筛选
用户端资讯列表需要做分页。用MyBatis-Plus时，分页只需要配置一个PaginationInnerInterceptor，然后调用page方法传入页码和每页数量，返回的Page对象里有总记录数、总页数、当前页数据列表。前端传参数页码pageNum和每页大小pageSize，接回来渲染即可。
多条件筛选是列表接口的重点。比如前台接口要支持：按分类筛选、按关键字搜索、按时间排序、按热度排序。这些条件不能写死，需要灵活拼接。MyBatis-Plus提供LambdaQueryWrapper，根据条件构造器进行条件判断。类似这种写法：如果categoryId不为空，就加上eq条件；如果keyword不为空，就用like条件匹配标题；排序字段通过前端传入标识，做switch判断映射到对应列。这样一套逻辑能覆盖前台浏览场景的绝大多数请求，代码也优雅。
这里分享一个优化细节：列表页不要一次性把资讯正文内容完整查出来，只查标题、封面、摘要、浏览量这些字段，详情接口再返回完整内容。实现方式是查询时使用select指定列。好处有两层：一方面列表接口响应更快、流量更小，另一方面也体现了你对数据库查询性能的敏感性。这一点写论文时很出彩。
4.4 评论、点赞、收藏的实现细节
评论发布相对简单：用户点提交，后端组装评论内容、发布者ID、所属资讯ID，然后事务性保存。需要思考的一点是，评论列表如何排序——按时间正序排列，用户看到的是层层叠叠的对话结构；按时间倒序排列，比较方便查看最新讨论。设计中可以加一个排序字段控制，默认正序。
点赞和收藏的接口形态高度类似：前端传一个资讯ID，后端判断当前用户是否已经点过赞。没有则插入点赞记录并把资讯表likeCount加一；已经点过则删除点赞记录并把likeCount减一。这里的关键细节是两条SQL操作必须处于同一事务。收藏接口的逻辑同样处理，只不过操作的表和字段换成收藏表和favoriteCount。有一点个人建议：点赞和收藏不要返回纯成功或失败，建议把操作后的最新数量返回给前端，这样界面上能直接刷新而不用再发起一次查询。
4.5 文件上传：图片到底存哪里
资讯封面图和用户头像的上传是毕设项目绕不开的环节。最常见的做法是将文件保存到服务器本地磁盘的某个目录，同时把访问URL存进数据库。这个方案简单直接，在单体应用中足够了。
具体实现是配置一个上传路径，使用MultipartFile接收文件，用UUID随机生成文件名防止重名，后缀扩展名限制为jpg/png/gif，大小限制比如最大5MB。SpringBoot默认单个文件最大1MB，需要在application.yml里修改spring.servlet.multipart.max-file-size配置。保存文件用Files.copy方法，将临时文件转存到目标目录。访问时配置一个静态资源映射，把本地磁盘路径映射到访问URL路径，浏览器就能直接通过URL访问到图片。
上传路径建议存储相对路径而不是绝对路径，比如/upload/2025/xx.jpg。这样后续迁移服务器时，改动最小。最新热词里提到minio加入到springboot，如果你的项目想做一个加分项，把本地保存方案替换为MinIO对象存储是个不错的选择，MinIO兼容S3协议，但前提是你已经搞定了主流程。本地方案都已经能正常跑通的，就不要再中途引进一个中间件给自己添负担了，这是毕设项目里极其重要的一条经验：先保证主线稳定，再考虑颠覆性的重构。
4.6 管理员后台的核心能力
管理端的功能围绕用户和内容两个维度展开。用户管理板块支持用户列表、条件搜索、禁用与启用账号。禁用操作的实现并不只是改一个状态字段，而是要确保被禁用的用户无法调用发布、评论、点赞等写操作接口，这要求在拦截器或Service层对账号状态进行二次校验。一个只改了数据库字段而没有代码逻辑兜底的“假禁用”很容易被答辩老师看穿。
资讯管理相对复杂一点：审核列表涵盖待审核、已发布、已下架三种状态，管理员可以执行审核通过、拒绝、下架、删除四个操作。统计方面用简单的SQL聚合即可：每天发布的资讯数量、用户总数、资讯总数、评论总数，在管理后台首页用卡片或简单图表展示。这些统计数字直接喂给前端，图表可以用echarts画一个简单的柱状图，工作量不大但演示效果好。
4.7 Maven构建与项目配置细节
Maven构建是很多同学拿到源码后第一道坎。IDEA导入Maven项目时，要先确保IDEA里配置的Maven用的是你自己装的那个，而不是IDEA自带的。JDK版本建议用1.8，虽然SpringBoot 2.x已经支持更高版本，但1.8是兼容性最稳的选择。有同学遇到“SpringBoot版本太高”的情况，依据个人经验，优先推荐直接换用SpringBoot 2.7系列的版本，和JDK8的搭配极其稳定，不要试图给高版本强行降级。如果下载依赖太慢，用阿里云Maven镜像，在settings.xml里配置mirror即可，这是国内开发者的标配操作。
打包部署时，命令行输入mvn clean package，会在target目录生成一个可运行的jar包。命令行执行java -jar xxx.jar启动服务，这样一个独立的SpringBoot应用就完成部署了。有同学问怎么把代码部署到服务器上：购买一台云服务器、安装JDK和MySQL、把jar包和SQL脚本传上去、建库导入数据、启动服务即可。这套流程应该写进你论文的“系统部署”小节，因为它是完整的工程实践。
5. 环境准备、项目启动与调试排错
5.1 运行环境清单与初始化步骤
我把项目跑起来的完整顺序列出来，按顺序执行就能少走弯路。
第一步，安装JDK 1.8并配置环境变量，命令行输入java -version能输出版本号即成功。第二步，安装MySQL 8.0，设置root密码，用Navicat或命令行创建数据库，编码选择utf8mb4。第三步，导入项目源码中的SQL脚本，脚本里包含建库建表语句以及初始数据，导入完成后可以看到所有表和几条管理员账号。第四步，用IDEA导入SpringBoot源码，等待Maven自动下载依赖。第五步，修改application.yml里的数据库用户名和密码，改成你自己的配置。第六步，启动SpringBootApplication主类，观察控制台日志，看到“Started”字样说明启动成功。第七步，浏览器访问前端页面或按接口文档调试后端接口。
5.2 九成新手会栽的配置错误
第一个是application.yml里的数据库账号密码没改对。很多同学的MySQL密码包含特殊字符，比如@符号。此时URL中的密码拼接会出问题，解决办法是特殊字符进行转义，或者干脆将密码换成简单一点的组合，本地开发环境不用追求复杂密码。
第二个错误是MySQL服务没启动。Windows下要么在任务管理器服务列表里启动MySQL服务，要么用管理员权限运行net start mysql。特别提醒：这一条极其常见，红灯亮起时请先检查这个。
第三个错误是端口被占用。SpringBoot默认端口是8080，如果被其他程序占用，启动日志会报Web server failed to start。解决办法是在application.yml里修改server.port，比如改成8081。
第四个是时区报错。启动时如果提示无法识别服务器时区，在数据库连接URL后面加上serverTimezone=Asia/Shanghai参数，能解决这个具有年代感的老问题。
5.3 常见运行问题与排查技巧实录
整理几个我实际遇到并且处理过的高频问题，给各位直接照做。
第一个是依赖下载不下来。要么迁移到阿里云镜像，要么检查IDEA的代理设置。如果你发现自己每次都卡在同一个jar包下载，大概率不是网络问题，而是本地仓库里有一个损坏的lastUpdated文件，去本地仓库把对应目录删掉再重新导入。
第二个是运行时提示找不到Mapper或Mapper扫描不到。在SpringBoot启动类上添加@MapperScan注解，指定Mapper接口的包路径，或者在每个Mapper接口上标注@Mapper注解。二选一即可，千万别漏掉。
第三个是跨域问题。如果前端是Vue项目通过端口8081访问后端8080，会触发跨域拦截。解决办法是后端写一个CorsFilter或者用@CrossOrigin注解，把允许的来源、方法、请求头配置好。
第四个是数据乱码。检查三处编码：数据库连接URL设characterEncoding=utf-8，数据库和表的字符集用utf8mb4，前端页面编码也是utf-8。三处对齐，乱码基本绝迹。
第五个是前端Vue打包后放到SpringBoot中。把Vue打包生成的dist目录内容拷贝到SpringBoot的src/main/resources/static，然后通过后端端口访问，省去Node环境和前后端分离部署的麻烦。这个方法非常适合毕设演示，一套jar包解决所有问题。但注意刷新页面时会出现404，因为前端路由是history模式，后端需要写一个路由回退的Controller转发到index.html。毕设场景下，最省事的方式是创建路由时改成hash模式，直接从根上避免这个问题。
6. 论文撰写与答辩准备的完整思路
6.1 论文结构怎么写才不显得凑字数
毕设论文不是代码堆叠，而是对设计思路的完整讲述。常规结构可以这样安排：第一章绪论写背景与意义、国内外研究现状、本文的主要工作；第二章相关技术介绍写SpringBoot、MyBatis-Plus、MySQL、JWT，重点是每项技术解决了什么问题，不要像抄官网文档一样罗列特性；第三章系统分析写可行性分析、需求分析、用例图、功能模块划分；第四章系统设计写总体架构图、功能结构图、数据库ER图、表结构设计；第五章系统实现按模块截图加核心代码，加上文字说明；第六章系统测试写测试用例表、功能测试过程、测试结论。
切忌大段贴代码。核心代码每个模块挑10到15行最有代表性的，加注释，其余的在文字里描述。论文看的是你“能不能把代码讲清楚”的能力，不是粘贴的篇幅。
6.2 演示文案与答辩高频问题
答辩演示建议按这个顺序来：用户注册登录、浏览资讯列表、查看详情并评论、发布资讯、管理员审核、用户数据统计。每个操作停留几十秒，让老师看清界面和响应结果，不要快手操作。
老师爱问的问题，通常是这五个方向：
- 登录后的用户信息怎么获取？答：JWT存payload里的用户ID，拦截器解析Token后放进当前上下文，后续接口从上下文拿。
- 点赞的并发问题怎么处理？答：点赞记录插入前做唯一约束校验，点赞计数用事务性更新，并发极端场景下可以加乐观锁。
- 密码是怎么存储的？答：BCrypt加盐哈希，不是明文也不是简单MD5。
- 上下架是什么机制？答：状态字段控制，前台查询强制过滤status=已发布。
- 数据库表为什么不用物理外键？答：外键影响插入性能且不适用于互联网高并发写场景，应用层保证数据一致性。
准备个三五十个这样的问答，你的答辩就稳了大半。源码包里的代码讲解文档基本涵盖了这些问题的答案，提前消化掉。
6.3 源码、文档、调试资料的组合用法
拿到整套资料后，建议按三个层次去消化：第一层是通读文档，搞清楚系统设计和部署步骤；第二层是把自己当成开发人员，从数据库脚本开始，到跑通项目，逐个功能模块验证；第三层是把自己当成面试者，试着不看代码复述每个模块的实现思路。全部走完，你基本就能无障碍应对答辩提问。从我自己带毕设的经验来看，认认真真重跑一遍的同学，答辩成绩普遍好于直接看代码的同学——这不是玄学，是知识内化的程度不同。
7. 额外值得做的小幅度锦上添花
主流程跑通之后，如果时间还有富余，有几个低成本高回报的增强项可以考虑。验证码功能，用Hutool的验证码工具类或者Redis存验证码，防表单重复提交的同时也让系统看起来更完整。操作日志，通过SpringAOP切面统一记录用户操作日志，体现AOP思想的实际应用。数据备份，写一个定时任务用mysqldump备份数据库，呼应系统的安全性需求。通知公告，管理端发布系统公告，登录后首页展示。这些项目每一块的代码量都不大，但可以在论文的功能设计和系统实现两章各占一个小节，充实度明显提升。
给一个小提醒：增强功能要适量，别把所有想法都堆上去。答辩老师不希望你做出一个功能臃肿的“大杂烩”，而是希望你围绕核心需求做出一个逻辑自洽、能完整跑通的系统。适度的亮点让系统有特点，过量的功能只会增加出错概率和演示风险。
我个人在实际操作中的感受是，校园资讯分享平台这个题目最舒服的地方在于——它不要求你成为一个算法高手或者高并发专家，而是让你完整体验一次“从需求分析到系统上线”的工程过程。这正是本科毕业设计应该有的样子。如果你手里的版本在功能上有增删，也不要慌，顺着表结构去改模块即可，思想是相通的。最后再分享一个小经验：无论你的源码包里有多少东西，请一定要自己亲手把项目从零到一跑一遍，再亲自动手改两三个功能。这一步完成了，你这篇毕业设计就真正稳了。
