每年到了毕业季计算机专业的同学几乎都会在同一个地方卡住——选题。Spring Boot相关的题目本身就占了半壁江山要是再带点“管理系统”字样那基本就是人手一个的标配了。我今年带过的几个学生里有两个都选了“高校竞赛管理系统”这个方向一个做的是纯后端接口另一个做了前后端分离带移动端适配。说实话这个题看起来平平无奇但真正做下来它的工作量、技术覆盖面、答辩可讲点都比很多花里胡哨的题目要扎实得多。作为一个前前后后帮忙看过几十个Spring Boot毕设项目的人我想用这篇东西把“高校竞赛管理系统”从选题到落地的完整链路拆开讲一遍。不管你是正在纠结要不要选这个题还是已经选了但不知道从哪里下手又或者代码写到一半卡在某个功能上这篇文章应该都能给你一些能直接拿去用的东西。先说结论这个题目适合大多数基础中等的同学它最大的优势不是“简单”而是“模块边界清晰”适合用来展示你对Spring Boot、数据库设计、业务逻辑封装的理解。但同样是因为这个题目太常见想要拿高分不能只停留在CRUD层面必须在几个关键点上有自己的想法。1. 选题价值与核心需求拆解很多人选竞赛管理系统图的是“管理系统的套路都一样”。这话对了一半。竞赛管理系统确实逃不开增删改查但竞赛业务它有自己的独特性——它的核心是“流程”不是“数据”。这个理解偏差直接决定你最后做出来的是一个“电子表格”还是一个“系统”。1.1 竞赛管理系统的真实业务场景先想一个问题一个高校里举办一场学科竞赛从开始到结束需要多少人协作、走多少步流程第一步教务处或者学院要发布竞赛通知确定竞赛名称、级别校赛/省赛/国赛、报名起止时间、参赛对象、比赛形式个人/团队、奖项设置。然后学生看到通知开始报名填写个人信息、指导老师、团队成员。如果是团队赛还要处理成员之间的组队关系。报名结束后管理员要审核参赛资格不符合条件的要打回并通知。接着是作品提交阶段——这里可能是一份文档、一个压缩包、一个视频或者答辩PPT。然后管理员分配评委评委在线打分或者下载作品线下评审后统一上传分数。最后系统按规则计算总分、排名、生成获奖名单公示并导出奖项表。这只是最主线的流程还不算上消息通知、证书编号生成、比赛数据统计这些支线功能。所以你看这个系统里的核心难点不在任何一个单独的功能上而在“流程状态”的流转上。报名状态有草稿、已提交、待审核、已通过、已驳回。作品状态有未提交、已提交、已截止。评审状态有未分配、评审中、已完成、已发布。这些状态之间的转换规则才是这个项目真正值钱的部分。1.2 为什么这个题目适合做毕业设计毕设的评分维度基本可以拆成三层第一层是功能能不能跑通这是及格线第二层是工程结构是否合理、代码是否规范、数据库设计是否符合范式这是中等偏上第三层是你能不能说清楚某个设计决策背后的理由这决定了能不能上优秀。竞赛管理系统在这三个维度上都有足够的发挥空间。功能上它的角色多——管理员、教师/评委、学生每一类角色看到的东西和能做的事情完全不一样权限设计自然就有了复杂度。工程上它的业务实体多而不乱——用户、竞赛、报名、队伍、作品、评审、公告、奖项这些实体相互关联但边界清晰非常适合用来表现你对MyBatis-Plus、关联查询、事务管理的掌握程度。答辩环节更不用担心没有东西讲——选一个“并发报名时如何防止超报”“评委打分权限如何控制”“Excel导入导出怎么实现”都能撑起三五分钟的深度问答。相比“图书管理系统”“学生宿舍管理系统”这种纯CRUD题目竞赛管理系统的亮点在于它有“状态机”的影子相比“电商秒杀系统”“推荐系统”这种硬核技术题它又不会把你逼到必须精通Redis分布式锁、消息队列才能毕业的程度。可以说是进可攻退可守的典型题目。2. 技术选型与架构设计思路技术选型这个东西我见过太多同学一上来就堆技术栈Spring Boot Spring Cloud Redis RabbitMQ Elasticsearch然后写了两周发现根本跑不起来。毕设技术选型的第一原则永远是你能否向答辩老师解释清楚每一个组件存在的必要性。2.1 Spring Boot版本选择的血泪教训先说版本。现在去Spring官网创建项目默认推荐的是3.x版本很多同学直接无脑选了3.2或者3.3结果后面踩了一堆坑。最典型的问题有两个一个是Spring Boot 3.x最低要求JDK 17而很多学校机房、实验室电脑上装的是JDK 8且教学环境下老师要求必须用JDK 8来跑另一个是Spring Boot 3.x里很多老牌的第三方库尤其是跟Java EE相关的换了命名空间你搜网上的教程到处都是基于Spring Boot 2.x写的按着抄很容易出现依赖冲突、注入失败的问题。我的建议是如果老师没有强制要求优先选Spring Boot 2.7.x。这是2.x系列的最终版本稳定、资料多、教程广对JDK 8-friendly而且主流组件跟它都能兼容。网上搜“springboot后台管理系统”十篇有八篇是2.x的代码照着改非常省事。如果你对JDK 17、Spring Boot 3.x的新特性比如GraalVM原生镜像、新的HTTP客户端有深入了解那选3.x也没问题但务必要做好“所有依赖都得用新版本、很多教程里的写法是错的”的心理准备。这玩意儿真不是越新越好。我见过一个学生用Spring Boot 3.2 JDK 21写了一个月最后在部署到老师指定的服务器时发现Tomcat版本不兼容系统起不来那种绝望感我到现在都记得。2.2 核心框架搭配方案后端框架除了Spring Boot本体我个人比较推荐下面这套组合市面上相关整合教程也是最多的持久层MyBatis-Plus。不用再手写大量的ResultMap和BaseResultMap单表CRUD直接继承BaseMapper搞定分页查询有现成的Page对象而且它的LambdaQueryWrapper写起来非常直观不容易拼错字段名。权限认证Sa-Token 或者 Spring Security JWT。如果只是想拿到一个能用的登录鉴权Sa-Token上手成本低很多代码量少而且自带踢人下线、权限注解、接口限流等功能很适合毕设场景。Spring Security功能强大但配置繁琐如果你不是特别熟悉它的过滤器链很可能会在“明明登录成功了但请求还是被拦截”这种问题上卡两天。接口文档Knife4j基于Swagger。生成接口文档特别方便答辩前给老师演示API列表也很加分。工具类Hutool。它的Excel导出、日期处理、加密工具、随机数生成都封装得很好可以省下大量重复代码。前端的话如果你不是前端方向不建议自己从零写Vue。直接找一个开源的Vue后台管理模板比如若依、vue-element-admin来改造把自己后端接口接进去就好。前端能跑通菜单、登录、增删改查页面对毕设来说完全达标了。2.3 整体架构单体还是微服务我的态度非常明确毕设一律做单体应用不要碰微服务。你想想一个竞赛管理系统用户量可能就几千人高峰期并发几十个请求用微服务纯粹是自己给自己找麻烦。你拆成用户服务、竞赛服务、报名服务、评审服务然后还需要注册中心、配置中心、网关最后还要处理分布式事务——这些东西在答辩时如果讲不透老师随便追问一句“你这个服务拆分带来了什么实际收益”你就很难自圆其说。单体应用不是技术落后。把Controller-Service-Mapper三层分包做好把异常处理、全局响应封装、统一校验做好这本身就体现了工程化能力。我甚至建议你在单体里引入一点DDD的分包思想按业务模块分包而不是按技术层次分包。比如把competition相关的Controller、Service、Mapper、Entity都放在module.competition下面把user相关的放在module.user下面。这样代码结构看起来更清爽老师翻你项目的时候第一印象就很好。3. 核心功能模块设计与数据库实现功能模块设计是整个项目的地基。很多人上来就吭哧吭哧写代码写到一半发现报名表里缺了“团队人数”字段又回头改数据库改完数据库发现Java代码里一堆地方要跟着改非常折磨。所以这个环节宁可多花两天把原型和表结构想清楚也不要在代码里做“敏捷开发”。3.1 角色权限与功能矩阵梳理竞赛管理系统里的用户角色我认为至少要划分成三种管理员、评委教师、学生。如果你还想增加复杂度可以把“指导教师”单独拎出来让指导教师在学生报名时同步确认指导关系但这属于加分项不是必选项。每个角色对应的核心功能管理员用户管理、竞赛发布、参赛资格审核、评委分配、比赛数据统计、奖项设置与发布、公告管理、系统参数配置。评委查看被分配的比赛与作品列表、下载作品、提交评分、查看自己评过的历史记录。学生查看竞赛公告、在线报名支持个人/团队、维护报名信息、上传作品、查看审核状态与最终成绩。这个功能矩阵看起来简单但落到数据库设计上就会引出一堆细节问题。举例来说评委和竞赛之间是多对多关系——一个评委可能给多个比赛打分一个比赛有多个评委。那评分表要不要单独建必须建。而且评分表的粒度要细到什么程度是按作品打分还是按作品下的多个评分项比如创新性、完成度、实用性分别打分如果按多个维度打分权重怎么算这些就是设计评审的核心问题。3.2 数据库表结构设计要点直接列出我实际用过的核心表结构你可以在建库时参考具体的字段类型和长度可以自己微调。用户表userid、用户名、密码BCrypt加密后、姓名、学号/工号、学院、角色admin/teacher/student、手机号、邮箱、创建时间、状态。竞赛表competitionid、竞赛名称、竞赛级别校/省/国、主办方、竞赛类型个人/团队、描述、报名开始时间、报名结束时间、作品提交截止时间、评审时间、状态草稿/报名中/评审中/已结束、封面图URL、最大团队人数、是否允许跨学院组队。报名表registrationid、竞赛ID、学生ID报名主申请人、团队ID如果是个人赛则为空、指导教师ID、报名状态草稿/已提交/待审核/通过/驳回、驳回原因、报名时间、审核时间、审核人ID。团队表teamid、团队名称、竞赛ID、队长ID、团队成员列表可用JSON字符串存储成员ID数组、创建时间。这里有一个设计取舍团队成员到底用关联表还是JSON字段。如果团队规模固定且很小比如3-5人用JSON字符串存成员ID数组是最简单的方案查询时只需要按团队ID查就可以。如果要做“按成员反查团队”这种需求就要单独建team_member关联表。考虑到毕设的场景我建议用关联表因为“学生报名了哪些比赛”是非常高频的查询需求你有这个关联表之后一条SQL就搞定了。作品表workid、报名ID或团队ID、竞赛ID、作品名称、作品类型文档/视频/代码压缩包等、存储路径本地路径或OSS key、文件大小、上传时间、版本号允许多次提交覆盖。评审表reviewid、竞赛ID、作品ID、评委ID、各项评分创意创新XX分、技术难度XX分、完整度XX分等、总分、评语、评审状态草稿/已提交、评审时间。这里故意把多个评分项设计成独立字段而不是用一个JSON存所有评分项目的是方便做统计——比如你想算出“所有作品的平均创新分数”独立字段一条SQL就能查出来。证书表certificateid、竞赛ID、获奖作品ID/学生ID、奖项等级一等奖/二等奖/三等奖/优秀奖、证书编号、发放状态、生成时间。公告表announcementid、标题、内容、发布人ID、置顶标识、发布时间。这张表清单基本覆盖了一个主流竞赛管理系统的数据需求。有个细节要注意很多字段在设计时要区分“业务主键”和“逻辑主键”。比如“证书编号”是业务上要展示给用户看的格式可能是XK2024-001这类字段要有唯一索引而数据库主键id是无意义的自增或雪花ID。3.3 状态机设计是系统的灵魂刚才提到的各种状态字段我建议你专门抽一个枚举类来管理。举一个例子报名状态public enum RegistrationStatus { DRAFT(0, 草稿), SUBMITTED(1, 已提交), PENDING_REVIEW(2, 待审核), APPROVED(3, 已通过), REJECTED(4, 已驳回); private final int code; private final String desc; // getter、constructor省略 }然后在代码里要统一控制状态的流转逻辑。比如只有状态为“已提交”的报名记录管理员审核操作才生效“已通过”的记录不允许学生再自行修改“已驳回”的记录学生修改后重新提交状态回到“待审核”。把这些状态流转画成一张表贴在论文或者笔记里答辩的时候直接展示给老师看效果非常好。我见过不少同学在状态处理上偷懒直接用一个int字段前端传什么数字就存什么数字结果数据库里存了一堆“5”“6”“999”这种不可读的值最后查数据还得在SQL里猜来猜去。用枚举状态机强约束代码的健壮性会高一个台阶。4. 关键功能点实现过程与避坑实录前几节把设计和结构讲完了这一节重点说代码怎么落。我会挑几个我认为最关键的功能点给出实现思路和部分代码片段。这些点也是答辩时最容易成为亮点的地方。4.1 基于JWT的登录鉴权与角色控制毕设里用JWT做登录态管理是最主流的方式。核心流程用户输入用户名密码后端用BCrypt校验密码千万不能用MD5明文存储密码。校验通过后生成JWT Token把用户ID和角色塞进Token的有效载荷里。前端拿到Token后存到localStorage每次请求在请求头里带上。后端写一个拦截器或者AOP切面拦截除登录接口以外的所有请求解析Token从中取出用户ID和角色放进ThreadLocal里供后续业务方法使用。代码核心片段Sa-Token版可以简化很多但如果你用Spring MVC原生拦截器重点在于这个注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }然后在拦截器里解析这个注解比对当前用户的角色是否满足要求。这里有个特别容易踩的坑JWT的密钥和过期时间不要写死在代码里要放到application.yml配置文件中。而且过期时间建议设置成2小时前端做自动续签或者过期后跳回登录页。很多同学把过期时间设成7天这会给系统带来安全隐患——Token一旦泄露等于账号裸奔一周。4.2 报名阶段的防重复提交与团队校验学生报名的接口是最容易出并发问题的地方。举个例子一个比赛限制报名500人第499个人和第500个人同时点击提交如果代码是“先查数量再插入”那在并发情况下可能出现两人都通过了数量校验最后数据库里实际有501条记录的情况。解决方案有两种。简单做法在报名表上加一个唯一约束竞赛ID 学生ID数据库层面直接挡住重复报名然后捕获DuplicateKeyException返回“您已报名该竞赛”。更稳妥的做法对竞赛表加一个current_applicants字段在插入报名记录时使用UPDATE competition SET current_applicants current_applicants 1 WHERE id ? AND current_applicants max_applicants这种原子操作来扣减名额如果影响行数为0说明名额已满或竞赛不存在。团队赛的校验就更复杂一点要校验团队成员是否都已注册系统、是否已经参加过该比赛、成员人数是否在合理范围内比如2-5人。这个校验逻辑建议放在Service层用事务控制保证“创建团队添加成员生成报名记录”这三个操作要么全部成功要么全部回滚。4.3 作品上传与文件名安全处理作品上传也是老生常谈但大家经常出错的点。最容易犯的错误有三个不限制文件类型、不限制文件大小、文件名直接拼接存储导致路径穿越漏洞。最快速的解决方案文件类型用MultipartFile.getContentType()判断但这个方法不一定可靠更靠谱的是检查文件扩展名文件头的魔数MAGIC NUMBER。比如判断是不是真的PDF可以读取前5个字节看是不是%PDF-。文件大小用Spring配置spring.servlet.multipart.max-file-size100MB来限制同时在前端提前校验一次避免用户上传一个2GB的压缩包到服务器才发现失败。存储文件名直接用UUID生成新名字不要使用用户上传的原始文件名。原始文件名只作为originalFilename字段存进数据库展示用。String ext FilenameUtils.getExtension(file.getOriginalFilename()); String storedName UUID.randomUUID().toString().replace(-, ) . ext; String yearMonth LocalDate.now().format(DateTimeFormatter.ofPattern(yyyy/MM)); String storePath uploads/ yearMonth / storedName;按年月分目录存储的好处是后期按时间清理或者查找都很方便。4.4 评委评分Tab页的权限与数据隔离评审功能最容易出错的是“一个评委看到了不该看的作品”。比如A评委被分配评审10个作品但他通过猜测URL参数比如调整作品ID就能看到B评委负责的作品的评分信息。这就是典型的越权访问漏洞IDOR。解决办法查询作品时必须带着“当前登录评委ID”作为条件去查而不是只按作品ID查。// 正确示例只查询分配给当前评委的作品 PageReview page reviewMapper.selectPage(pageParam, new LambdaQueryWrapperReview() .eq(Review::getJudgeId, currentUserId) .eq(Review::getCompetitionId, competitionId));这个逻辑写成SQL就是强制带上WHERE judge_id ?而不是依赖前端传什么你就信什么。毕设答辩的时候老师很喜欢针对这个点提问题“如果我是评委我能不能直接改URL参数看到别的作品”你要是能回答上来“我们在后端做了数据权限隔离查询强制绑定当前登录用户”这题基本就稳了。4.5 Excel导入导出与成绩统计管理员在评审结束后需要把成绩导出成Excel发给教务处这是竞赛管理系统的一个刚需功能。用EasyExcel阿里开源做导出比传统的Apache POI要省力很多特别是大数据量导出时内存占用低。成绩统计方面可以考虑做这几个页面竞赛报名趋势图按日期统计报名人数用ECharts画折线图。学院获奖分布按学院统计各项获奖数量用柱状图或饼图展示。评委评分对比分析不同评委打分的平均值、方差辅助管理员发现异常评分。有一个小技巧统计类的SQL尽量在数据库端完成不要先把所有数据查到内存里再用Java代码循环累加。一方面代码简洁另一方面性能也好很多。比如统计学院获奖分布就是一条GROUP BY语句的事SELECT u.college, c.award_level, COUNT(*) AS cnt FROM certificate c JOIN team t ON c.team_id t.id JOIN user u ON t.captain_id u.id WHERE c.competition_id ? GROUP BY u.college, c.award_level5. 毕设避坑与答辩准备经验写代码是第一步提交论文和准备答辩是第二步。很多同学代码写得还行但论文结构混乱、答辩说不出重点最后分数反而不如代码稀烂但很能讲的同学——你要明白毕设成绩考察的从来不只是代码本身。5.1 常见开发环境问题速查我整理几个这些年在Spring Boot毕设里频繁出现、每个都真实拦住过人的环境问题问题现象解决方案JDK版本不匹配项目启动报UnsupportedClassVersionError或java: invalid source release: 17检查IDEA中的Project Structure、Maven的JAVA_HOME、pom.xml的java.version三者是否一致端口被占用Web server failed to start. Port 8080 was already in use.用netstat -anoMaven依赖下载慢卡在Downloading...长时间不动换成阿里云Maven镜像IDEA设置里改settings.xmlMySQL时区报错The server time zone value is unrecognizedjdbc:mysql://localhost:3306/xxx?serverTimezoneAsia/Shanghai连接串加上时区前端跨域浏览器控制台报Access-Control-Allow-Origin后端写一个CORS配置类放行指定来源和请求头项目一启动就闪退看日志有Error creating bean with name定位到具体的Bean注入错误检查是否有循环依赖或Mapper接口没加Mapper注解每个问题在博客、视频里都有大量解决方案搜的时候记得加上你的Spring Boot版本号不要只看文章标题就照搬。5.2 论文写作与答辩讲解重点论文结构不要自己瞎编。学校一般会给模板照着填就行。内容上我认为要特别注意的部分是“需求分析”和“系统设计”这两章很多同学把需求分析写成“系统需要用户管理、竞赛管理、报名管理”一句话带过然后就去贴代码截图了这是不对的。需求分析要写清楚系统有哪些角色每个角色的核心业务流程是什么有哪些非功能性需求安全性、性能、易用性。最好配上用例图和活动图图比字更直观。答辩准备我建议你提前准备这四个问题的答案为什么选Spring Boot而不是SSH/SSM——答Spring Boot简化了配置、内置Tomcat、生态成熟开发效率高适合快速交付。千万不要说“因为网上教程多”这种话。用户密码是怎么存储的——答BCrypt加盐哈希不是明文也不是MD5。你可以顺带提起MD5有彩虹表风险而BCrypt每次加密结果不同。如果报名人数瞬间暴涨系统怎么应对——答虽然毕设默认不考虑大规模并发但你可以说在数据库层面做了唯一约束防止重复报名在查询层面做了索引优化并可以通过引入Redis做分布式锁来进一步加固。你自己觉得这个系统还有什么不足——答建议说一个非致命的点比如“目前没有做消息推送用户只能登录系统看通知后续可以接入邮件或短信提醒”。然后赶紧接一句“如果时间允许我最想改进的是XX”显得你有思考深度。5.3 我再看这个题目的体会带了不少学生做完竞赛管理系统之后我越来越觉得这个题目最大的价值不是让你学会某个高深技术而是逼着你把一套完整业务从头到尾想清楚、写清楚、讲清楚。你在做这个项目的过程中练出来的数据库设计能力、事务控制能力、权限模型思维放进真实的企业项目里也完全用得上。如果你最后选了或者已经在这个题目上记住一件事不要为了追求所谓的高大上技术而牺牲掉主体功能的稳定。先把流程走通再把细节打磨好最后有余力再锦上添花。一个能稳定跑起来、界面整洁、逻辑自洽的系统永远比一个功能花哨但一演示就报错的项目更打动人。最后分享一个小习惯把每个关键功能的实现思路、遇到过的坑、解决办法随手记到项目根目录的README或者笔记里。等到写论文和准备答辩的时候你会发现这些碎片记录才是你最宝贵的素材。祝你的毕设顺利落地。