每年一到毕业设计季基于SpringBoot的校园新闻管理系统都会出现在大量选题清单里。别看这个题目听起来只是“新闻的增删改查”真正动手做的时候业务边界、角色权限、审核状态机、文件上传路径这些问题会一个个冒出来。这篇文章就围绕这个题目把从审题、技术选型、数据库设计到核心功能实现和答辩避坑的完整思路过一遍适合正在做这个题目或者准备参考它练手的同学直接抄作业。1. 审题校园新闻管理系统不是随便搭个CRUD先说结论这个题目能长期存在是因为它恰好踩中了毕业设计想要考察的几乎全部基础能力——Web分层架构、数据库设计、权限控制、文件处理、状态建模。但你如果只做出一个“能增删改查新闻”的页面答辩时基本撑不过三分钟。1.1 这个题目的业务边界比想象中宽一圈“校园新闻管理系统”拆开看是两个端一个是面向普通浏览者的前台门户一个是面向管理人员的后台管理端。前台门户通常包含新闻列表展示、新闻详情、按分类筛选、关键词搜索、新闻评论可能还有轮播图推荐、热门新闻排行榜、浏览量统计。这些功能看起来都是标配但每一块都藏着可深挖的点。后台管理端则复杂一些管理员登录、栏目分类管理、新闻发布、新闻编辑、提交审核、审核通过或驳回、已发布新闻的下线和重新发布、评论审核与删除、用户管理、系统日志。这里最核心的业务模型是“新闻发布前要经过审核”。校园场景里普通学生或小编通常没有直接发布权限必须先提交给管理员或审核员审核通过后才能上线。这个环节一旦在数据库设计里漏掉后面补起来就要改很多代码。1.2 功能清单的完整版本从四个视角倒推做系统前最好先列角色角色决定权限权限决定菜单菜单决定页面。这个题目一般可以拆成四类角色角色能做什么对应模块游客浏览新闻、按分类查看、搜索、看评论前台门户登录用户游客全部能力 发表评论、管理个人头像前台门户 个人中心新闻编辑编写/编辑新闻、提交审核、查看自己的草稿和驳回记录后台内容管理管理员审核新闻、管理分类、管理评论、管理用户、查看统计数据后台管理端在答辩里最容易被老师追问的就是“权限控制怎么做的”。很多同学把角色字段写在用户表里然后在每个Controller里用if判断这当然能跑但一旦角色变多就会非常混乱。更合理的方式是让按钮和接口都绑定权限标识角色只负责关联权限集合。这个思路放在SpringBoot的拦截器或者Sa-Token上都很容易实现。从这四个视角倒推出来的功能清单才是这个题目应有的完整边界。2. 技术选型别跟风版本、持久层、前端方案都要有明确理由技术选型是答辩老师非常爱问的部分。单纯说“我用SpringBoot开发”是远远不够的你至少得能回答“为什么不用JSP”“为什么用MyBatis-Plus”“前端为什么选这个方案”。2.1 SpringBoot 2.7.x和3.x我建议优先选2.7.x如果这是毕业设计第一件事先确认你的JDK环境。很多实验室和机房电脑还停留在JDK8而SpringBoot 3.x强制要求JDK17及以上这会导致部署环境非常被动。我建议使用SpringBoot 2.7.x原因有三个对JDK8支持友好开箱即用稳定版资料多遇到问题能搜到的答案最丰富2.7.x和大多数毕业设计常用的MyBatis-Plus、Sa-Token、Thymeleaf版本兼容性都很好。不要觉得版本新就是加分项毕业设计更重要的是“稳定跑起来”和“能讲清楚”。如果老师问“为什么不用SpringBoot 3”你可以诚实回答当前项目运行环境是JDK82.7.x是长期维护版本能满足项目需求未来如果要升级SpringBoot的迁移成本并不高。这样的回答反而更真实。2.2 持久层选MyBatis-Plus而不是Spring Data JPA持久层用MyBatis-Plus可能是这个项目最大的取舍点。很多人纠结用JPA还是MyBatis-Plus我的经验是校园新闻管理系统涉及动态SQL、多表联查、分页统计MyBatis-Plus会让你的代码写起来更顺手。对比一下维度Spring Data JPAMyBatis-Plus单表CRUD非常方便非常方便动态SQL需要Specification写法比较绕内置LambdaQueryWrapper非常直观复杂多表查询JPQL / 原生SQL直接写XMLSQL可控性强学习成本中低答辩可讲性容易讲出“对象关系映射”容易讲出“SQL优化和分页”更重要的是毕业设计里你最需要展示的是业务实现而不是框架抽象能力。用MyBatis-Plus的LambdaQueryWrapper来做条件查询代码量小可读性高例如新闻列表按分类和状态筛选几行代码就写完了也方便配合分页插件。2.3 前端方案管理端用Thymeleaf门户端可以考虑前后端分离但要量力前端是很多非前端同学的痛点。我的建议分两种如果时间紧、目标只是把系统做完那统一用Thymeleaf服务端渲染就好。SpringBoot对Thymeleaf支持非常好页面直接放在templates目录下通过Controller返回视图名不需要考虑跨域、Token携带这些额外问题。如果时间充裕、想要在答辩时展示一些亮点可以做前台门户端前后端分离Vue3 Element Plus Axios后台管理端仍然用Thymeleaf服务端渲染。这样可以避免前后端完全分离后出现的问题比如登录状态保持、跨域配置、接口权限统一校验工作量会小很多。但别选错路线既想全站前后端分离又想直接抄现成的Vue项目模板最后前端接口调不通、跨域又没配好很容易在最后一周崩溃。我一贯的原则是毕业设计要控制风险把核心精力放在后端业务上前端够用且稳定就好。3. 数据库设计新闻系统的表比想象中多状态机必须提前设计数据库设计是这个项目最能拉开档次的部分。很多同学只建了新闻表和用户表等到做评论审核、新闻审核时才发现表不够用又开始改结构。3.1 用户、新闻、分类、评论四张核心表怎么建下面的设计经过了多个类似项目的验证直接照着建基本不会出大问题。用户表 sys_user字段包括id、username、password、nickname、avatar、role、status、create_time、update_time、deleted。role字段建议用字符串或数字表示角色比如1表示管理员、2表示编辑、3表示普通用户。不要用boolean或者把多个角色拼到一个字段里。新闻分类表 news_category字段包括id、name、sort、status、create_time、update_time、deleted。这里的sort是排序权重新闻列表页需要按分类排序时用得到。给个默认值0后台设置数字越大越靠前。新闻表 news_article核心字段如下字段类型解释idbigint主键category_idbigint所属分类titlevarchar标题summaryvarchar摘要列表页显示contenttext正文富文本内容cover_imagevarchar封面图URLstatusint0草稿1待审核2已发布3已驳回4已下线author_idbigint作者用户IDaudit_user_idbigint审核人IDaudit_remarkvarchar审核意见audit_timedatetime审核时间publish_timedatetime发布时间view_countint浏览量create_timedatetime创建时间update_timedatetime修改时间deletedtinyint逻辑删除评论表 news_comment字段包括id、article_id、user_id、content、status、parent_id、ip、create_time、deleted。status可以有0待审核、1显示、2隐藏审核不通过或隐藏评论。parent_id用于回复楼中楼如果不做回复功能这个字段可以不保留。3.2 新闻发布审核的状态流转草稿、待审、已发布、驳回这个状态机是整个系统最精华的部分。新闻的状态不能只是“已发布”和“未发布”两种而要形成一条明确的流转路径草稿(0) - 待审核(1) - 已发布(2)待审核(1)也可以被驳回变成已驳回(3)已驳回(3)可以再编辑重新提交回待审核(1)。已发布(2)可以手动下线变成已下线(4)已下线(4)也能重新发布回已发布(2)。这个流转必须在代码里做合法性校验。比如一个处于草稿状态的新闻不能直接被后台接口强行改成已发布一个已驳回的新闻审核人也不能再次通过。用一个Map或者switch方法把状态流转的合法路径维护起来比到处写if判断要清晰得多。我在实际代码里通常写一个StatusFlow类里面放一个合法流转表审核接口在更新状态前先判断“当前状态 目标状态”是否在合法路径里不在就直接抛业务异常。这样答辩时你还能顺带讲一下“状态模式”或者“状态机”的设计思想这就是加分点。3.3 容易被忽略的字段逻辑删除、创建时间、浏览量很多同学会把创建时间和更新时间放在最后才加结果导致所有实体类都要回填。建议在建表时统一加上create_time、update_time、deleted这三个字段MyBatis-Plus还能用TableField(fill FieldFill.INSERT)自动填充省很多事。deleted字段就是逻辑删除。为什么不用物理删除因为新闻系统的数据是有审计价值的编辑误删了新闻不应该直接消失而应该只是标记删除。另外逻辑删除后统计报表还能保留历史数据。还要注意一个问题浏览量用什么方式存。最直接的办法是在新闻表里放view_count每次请求详情页时执行update news_article set view_count view_count 1 where id ?。这个做法简单但对并发不太友好。毕业设计阶段用这招完全没问题但答辩如果被问到“高并发下怎么优化”你可以提一句把浏览量先放到Redis里定时批量刷新到数据库。不需要真的实现能说出方案就够了。还有封面图片字段。很多人只存一个图片路径但没考虑上传后如何访问。我建议数据库里存相对路径比如/upload/20250415/xxx.jpg不要存http://localhost:8080/upload/xxx.jpg这种带域名和端口的绝对地址。否则以后换域名、换端口所有图片路径全要改。4. 核心功能实现复盘登录、发布、上传、评论这一部分把功能实现的关键环节拆开讲。每个环节都有“看起来简单但做起来容易翻车”的点。4.1 登录鉴权用Sa-Token还是Spring Security如果你在Spring Security和Sa-Token之间纠结过你大概也翻过Spring Security那一大堆过滤器配置。我的建议是别在毕业设计里跟Spring Security死磕用Sa-Token会舒服很多。Sa-Token的优势是API极简登录后一行代码就能获取当前登录用户权限校验用注解即可。示例代码大致是这样// 登录参数为登录用户的唯一id StpUtil.login(userId); // 当前登录用户id Long userId StpUtil.getLoginIdAsLong(); // 权限校验注解需要admin角色才能访问 SaCheckRole(admin) GetMapping(/admin/news) public Result getAdminNews() { ... }这样Controller层不需要写一堆request.getSession()和if判断。里面这个SessionId默认通过Cookie传递前端什么都不用管尤其适合服务端渲染的Thymeleaf页面。需要注意的是如果你选择了前后端分离Sa-Token也支持前端通过请求头传递Token比Session模式更稳妥。但会多出跨域配置、前端Axios拦截器等步骤。登录密码一定要做加密存储不要明文入库。简单方案用BCrypt不要用MD5。答辩时如果老师看到数据库里的密码是密文这一项印象分就会好很多。4.2 新闻发布与审核事务边界放在哪新闻发布和审核涉及多个表联动事务的边界要清晰。以发布新闻为例前端传来的数据包含标题、摘要、正文、封面图、分类ID。后端代码要做这几件事校验分类是否存在、当前用户是否有编辑权限保存/更新新闻记录状态初始化为草稿保存一条操作日志记录“谁在什么时间创建了这篇新闻”。这三步必须放在同一个事务里。因为如果保存日志失败新闻记录不能让用户看到“保存成功但日志没记录”的状态。最简单的方式是在Service方法上加Transactional(rollbackFor Exception.class)。审核时的代码逻辑更考验细节NewsArticle article getArticleById(id); // 校验当前状态是否允许审核 if (!StatusFlow.canTransit(article.getStatus(), NewsStatus.PUBLISHED)) { throw new BusinessException(当前状态不允许审核通过); } article.setStatus(NewsStatus.PUBLISHED); article.setAuditUserId(currentUserId); article.setAuditTime(new Date()); article.setPublishTime(new Date()); // 更新文章状态 写审核日志这里要注意审核意见驳回时建议让编辑能够看到审核人的备注。所以也要在日志表里记录audit_remark。很多同学只更新了status没记录驳回原因导致编辑永远不知道新闻为什么被驳回逻辑上是残缺的。4.3 图片上传本地存储还是OSS毕业设计环境一般没有买云对象存储那我建议果断用本地文件存储。实现方式不复杂但有一个关键点要把上传目录设置成项目外部目录不要放在项目的target/classes目录或者src/main/resources下面。为什么要放外部目录因为SpringBoot打包后是jar包如果你把图片写入到工程的资源目录里那启动jar时不会自动创建这个目录而且在运行过程中写入的资源不可能写回jar包内。这个坑我见过太多次了本地IDE运行正常一打包部署就404。本地存储的核心配置思路# application.yml file: upload-path: /data/news-upload/然后写一个配置类把本地磁盘路径映射成HTTP访问路径Configuration public class WebMvcConfig implements WebMvcConfigurer { Value(${file.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }上传接口要做三件事校验文件类型、校验文件大小、重命名文件。类型建议用白名单比如jpg、png、gif、webp不要用黑名单因为黑名单永远防不住新后缀。重命名用UUID或者日期UUID避免中文文件名乱码和重复。文件大小建议控制在5MB以内写一个WebMvcConfigurer里的文件上传大小限制或者用Spring的MultipartFile就能读到大小手动判断也行。4.4 评论模块防XSS、防重复提交、敏感词过滤评论模块虽小但最容易暴露问题。首先是XSS攻击。如果支持富文本评论一定不要直接把用户输入原样存进数据库再原样渲染否则一个
