Spring Boot高校竞赛管理系统：从选题到答辩全攻略

每年到了毕业季，计算机专业的同学几乎都会在同一个地方卡住——选题。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 数据库表结构设计要点

直接列出我实际用过的核心表结构，你可以在建库时参考，具体的字段类型和长度可以自己微调。

用户表（user）：id、用户名、密码（BCrypt加密后）、姓名、学号/工号、学院、角色（admin/teacher/student）、手机号、邮箱、创建时间、状态。

竞赛表（competition）：id、竞赛名称、竞赛级别（校/省/国）、主办方、竞赛类型（个人/团队）、描述、报名开始时间、报名结束时间、作品提交截止时间、评审时间、状态（草稿/报名中/评审中/已结束）、封面图URL、最大团队人数、是否允许跨学院组队。

报名表（registration）：id、竞赛ID、学生ID（报名主申请人）、团队ID（如果是个人赛则为空）、指导教师ID、报名状态（草稿/已提交/待审核/通过/驳回）、驳回原因、报名时间、审核时间、审核人ID。

团队表（team）：id、团队名称、竞赛ID、队长ID、团队成员列表（可用JSON字符串存储成员ID数组）、创建时间。这里有一个设计取舍：团队成员到底用关联表还是JSON字段。如果团队规模固定且很小（比如3-5人），用JSON字符串存成员ID数组是最简单的方案，查询时只需要按团队ID查就可以。如果要做“按成员反查团队”这种需求，就要单独建team_member关联表。考虑到毕设的场景，我建议用关联表，因为“学生报名了哪些比赛”是非常高频的查询需求，你有这个关联表之后，一条SQL就搞定了。

作品表（work）：id、报名ID或团队ID、竞赛ID、作品名称、作品类型（文档/视频/代码压缩包等）、存储路径（本地路径或OSS key）、文件大小、上传时间、版本号（允许多次提交覆盖）。

评审表（review）：id、竞赛ID、作品ID、评委ID、各项评分（创意创新XX分、技术难度XX分、完整度XX分等）、总分、评语、评审状态（草稿/已提交）、评审时间。这里故意把多个评分项设计成独立字段，而不是用一个JSON存所有评分项，目的是方便做统计——比如你想算出“所有作品的平均创新分数”，独立字段一条SQL就能查出来。

证书表（certificate）：id、竞赛ID、获奖作品ID/学生ID、奖项等级（一等奖/二等奖/三等奖/优秀奖）、证书编号、发放状态、生成时间。

公告表（announcement）：id、标题、内容、发布人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做登录态管理是最主流的方式。核心流程：

1. 用户输入用户名密码，后端用BCrypt校验密码（千万不能用MD5明文存储密码）。
2. 校验通过后，生成JWT Token，把用户ID和角色塞进Token的有效载荷里。
3. 前端拿到Token后存到localStorage，每次请求在请求头里带上。
4. 后端写一个拦截器或者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-size=100MB来限制，同时在前端提前校验一次，避免用户上传一个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查。

// 正确示例：只查询分配给当前评委的作品 Page<Review> page = reviewMapper.selectPage(pageParam, new LambdaQueryWrapper<Review>() .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_level

5. 毕设避坑与答辩准备经验

写代码是第一步，提交论文和准备答辩是第二步。很多同学代码写得还行，但论文结构混乱、答辩说不出重点，最后分数反而不如代码稀烂但很能讲的同学——你要明白，毕设成绩考察的从来不只是代码本身。

5.1 常见开发环境问题速查

我整理几个这些年在Spring Boot毕设里频繁出现、每个都真实拦住过人的环境问题：

每个问题在博客、视频里都有大量解决方案，搜的时候记得加上你的Spring Boot版本号，不要只看文章标题就照搬。

5.2 论文写作与答辩讲解重点

论文结构不要自己瞎编。学校一般会给模板，照着填就行。内容上我认为要特别注意的部分是“需求分析”和“系统设计”这两章，很多同学把需求分析写成“系统需要用户管理、竞赛管理、报名管理”，一句话带过，然后就去贴代码截图了，这是不对的。需求分析要写清楚：系统有哪些角色，每个角色的核心业务流程是什么，有哪些非功能性需求（安全性、性能、易用性）。最好配上用例图和活动图，图比字更直观。

答辩准备，我建议你提前准备这四个问题的答案：

1. 为什么选Spring Boot而不是SSH/SSM？——答：Spring Boot简化了配置、内置Tomcat、生态成熟，开发效率高，适合快速交付。千万不要说“因为网上教程多”这种话。
2. 用户密码是怎么存储的？——答：BCrypt加盐哈希，不是明文也不是MD5。你可以顺带提起MD5有彩虹表风险，而BCrypt每次加密结果不同。
3. 如果报名人数瞬间暴涨，系统怎么应对？——答：虽然毕设默认不考虑大规模并发，但你可以说在数据库层面做了唯一约束防止重复报名，在查询层面做了索引优化，并可以通过引入Redis做分布式锁来进一步加固。
4. 你自己觉得这个系统还有什么不足？——答：建议说一个非致命的点，比如“目前没有做消息推送，用户只能登录系统看通知，后续可以接入邮件或短信提醒”。然后赶紧接一句“如果时间允许，我最想改进的是XX”，显得你有思考深度。

5.3 我再看这个题目的体会

带了不少学生做完竞赛管理系统之后，我越来越觉得这个题目最大的价值不是让你学会某个高深技术，而是逼着你把一套完整业务从头到尾想清楚、写清楚、讲清楚。你在做这个项目的过程中练出来的数据库设计能力、事务控制能力、权限模型思维，放进真实的企业项目里也完全用得上。

如果你最后选了或者已经在这个题目上，记住一件事：不要为了追求所谓的高大上技术而牺牲掉主体功能的稳定。先把流程走通，再把细节打磨好，最后有余力再锦上添花。一个能稳定跑起来、界面整洁、逻辑自洽的系统，永远比一个功能花哨但一演示就报错的项目更打动人。

最后分享一个小习惯：把每个关键功能的实现思路、遇到过的坑、解决办法，随手记到项目根目录的README或者笔记里。等到写论文和准备答辩的时候，你会发现这些碎片记录才是你最宝贵的素材。祝你的毕设顺利落地。