香香甜甜圈“学生竞赛管理系统”这个题目，在毕业设计里真的属于出场率极高的老面孔了。只要一搜Java方向，十有八九会看到类似的标题——基于Spring Boot、基于SSM、基于Spring Cloud微服务等等。但说句实话，绝大部分同类项目都停在“能登录、能增删改查”的阶段，答辩时被导师问几个实际问题就容易卡壳。这篇博客是准备把这些年做这类系统积累的一些经验梳理一遍，从需求拆解到技术选型，再到核心模块的实现思路和踩坑记录，尽量还原一个真正能落地、经得起问的竞赛管理系统。适合正在准备毕业设计的同学参考，也适合刚接触Spring Boot想做项目练手的开发者看看。内容以项目为主线展开，偏重解题思路而不是单纯贴代码。
1. 项目初期的需求梳理与定位
1.1 这个系统到底在解决什么问题
很多同学拿到这个题目第一反应就是“做一个管理后台”，然后直接开写用户表、竞赛表、报名表。这是最大的误区。学生竞赛管理系统表面看是“管理竞赛”，但深一层其实要处理的是高校里竞赛组织和运作流程中真实的混乱。
想想实际情况：一个学校一年可能同时有几十个竞赛项目，每个竞赛有不同的级别（院级、校级、省级、国家级），有不同赛道的报名时间，有指导老师分配，有作品提交的截止时间，还有评委打分的规则。如果全靠Excel和微信群里吼，信息不全、通知不到位、成绩统计易出错，这些才是系统真实要解决的问题。
所以这个设计的第一步不是数据库建模，而是梳理流程。一个完整的竞赛生命周期通常包括五个环节：竞赛发布 → 学生报名 → 作品提交 → 评委评审 → 结果公布与证书管理。系统里所有的功能模块都应该围绕这个生命周期去展开，而不是简单地给数据建个CRUD界面。
1.2 用户角色的真实痛点
系统通常至少要拆出四种角色：学生、指导老师、评委、管理员。每种角色关心的东西完全不同。
学生关心的是“我能报什么”、“截止时间到了没有”、“我提交的东西对不对”。也就是说前端需要清晰的门户视图，能看到当前开放的竞赛、自己的报名状态、作品上传的截止提醒。评委需要的是“我的评审任务是什么”、“怎么打分”。指导老师则关注“我带的队伍有哪些”、“学生提交的作品我能不能提前审核”。管理员做的事情最多：发布竞赛、分配评委、审核报名、统计成绩、导出数据。
这一层分析直接决定系统功能清单的优先级。我在实际设计中，把“竞赛发布与管理”、“学生报名与作品上传”、“评委在线评分”三个模块作为核心，其余如个人信息管理、通知公告、成绩公示、证书生成等作为辅助模块。这样做的好处是开发进度可控，答辩时有清晰的主线。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型背后的思考
2.1 为什么选Spring Boot而不是SSM
我自己在学校里最早学的是SSM（Spring + Spring MVC + MyBatis），但上手项目的时候还是选了Spring Boot。理由很现实：配置少、起步快、生态成熟。做毕设时间紧，没必要把精力耗在繁琐的XML配置上。Spring Boot的自动配置和起步依赖机制，可以让我用尽可能少的代码搭出一个可运行的后端服务。
另外，Spring Boot的社区活跃度实在太高了。遇到问题一搜基本都有答案，这对新手来说其实是最重要的一个隐性优势。比如关于文件上传的配置报错、跨域问题、拦截器失效之类的坑，网上一大堆案例可以直接借鉴。你省下来的时间可以花在业务逻辑和答辩准备上。
但要注意一点，Spring Boot版本和JDK版本容易埋雷。我见过很多同学拿Spring Boot 3.x去配JDK 8，结果Tomcat直接起不来。这里给大家一个保守但稳妥的组合：Spring Boot 2.7.x + JDK 8，或者Spring Boot 3.x + JDK 17。如果你用的是学校机房的老环境，建议优先选前者，兼容性风险最小。
2.2 配套技术栈的取舍清单
除了Spring Boot本体，整个系统常用的周边技术栈如下：
- 数据库：MySQL 5.7或8.0。MySQL几乎是这个项目的默认选择，免费、通用、资料多。如果只是为了跑毕设，不要再折腾PostgreSQL或者国产数据库，收益不大。
- ORM框架：MyBatis-Plus。这是我用得最多的方案，比原生MyBatis省掉大量重复的CRUD代码，提供的LambdaQueryWrapper写条件查询很舒服。也支持分页插件，配合PageHelper或者自带分页都可以。
- 前端方案：前后端分离用Vue（Element Plus），后端提供JSON接口。如果你的前端基础较弱，可以用Thymeleaf模板引擎。但说实话，现在答辩老师普遍会看重前后端分离，会问跨域如何处理、Vue的生命周期这些概念，所以建议尽量用Vue。
- 本地缓存：Spring Cache配合Redis。这个不是必须的，但如果做竞赛列表的缓存和验证码存储，Redis会很顺手。
- 工具库：Lombok、Hutool、Apache Commons。Hutool里封装了很多常用工具，比如Excel导出、日期处理，能省很多事。
这里顺便说下我建议的技术路线图：Spring Boot 2.7 + MyBatis-Plus + MySQL 5.7 + Redis 7 + Vue 2/3 + Element UI。这套组合难度适中、信息量大，对毕设答辩来说既有深度又不会失控。
3. 核心模块设计与数据库建模
3.1 功能模块拆分
按照业务生命周期，我把系统拆成六大模块：
- 用户认证模块：登录、注册、验证码、角色鉴权。这是第一个要做的模块，因为它决定了其他所有模块的访问控制。
- 竞赛管理模块：竞赛的发布、编辑、上下线，设置报名时间和作品截止时间。
- 报名与队伍管理模块：学生发起报名，可以是一个人也可以组队，填写队伍信息，邀请指导老师。
- 作品提交模块：报名成功后上传作品文件，做文件大小、类型的校验。
- 评审打分模块：管理员分配评委，评委对作品打分和写评语，支持多个评委对同一作品评分。
- 数据统计模块：成绩排名、参赛人数统计、Excel导出。
模块注册的先后顺序要注意。比如依赖关系上，评审模块必须建立在报名模块之上，否则没有作品可评。所以我开发的时候是按“用户认证 → 竞赛管理 → 报名管理 → 作品管理 → 评审管理 → 统计导出”的顺序推进。
3.2 数据库表结构的几个关键设计
数据库设计的合理程度直接决定开发顺利度。我列一下最核心的几张表，这些是系统运行起来必须要有的：
用户表（t_user）：字段包括id、username、password（加密存储）、real_name、role（用整数或字符串表示角色）、phone、email、avatar、status。这里建议不要把所有角色拆成独立表，因为角色间的数据高度重合，拆表反而增加复杂度。用一个role字段区分即可，简单实用。
竞赛表（t_competition）：id、name、category（类型）、level（级别）、description、signup_start_time、signup_end_time、submit_start_time、submit_end_time、max_team_members（团队人数上限）、status（草稿/进行中/已结束）、creator_id。注意报名时间和作品提交时间是两个时间区间，不要混成一个。
队伍表（t_team）：id、competition_id、team_name、team_leader_id、instructor_id、status（报名中/已提交/已通过/已驳回）、create_time。一个队伍对应一个竞赛，一个学生可以加入多个竞赛的不同队伍，所以队伍成员关系另建关联表。
作品表（t_work）：id、team_id、work_name、description、file_url、submit_time、status。有部分竞赛支持多次提交，所以需要保留历史版本，可以加一个version字段。
评分表（t_score）：id、work_id、reviewer_id、score、comment、create_time。注意联合唯一约束（work_id + reviewer_id），防止一个评委对同一作品评分多次。
这些表初看起来不难，但有几个细节我要特别提醒。竞赛表和队伍表之间一定要通过竞赛状态做启动报名限制，不能只在接口里靠前端按钮控制，后端每次创建队伍前都要校验竞赛当前是否在报名窗口内。另外，时间字段建议统一用datetime类型，前端传入的时间字符串要做格式校验，否则很容易在验截止时间时出bug。
3.3 一个容易被忽略的设计：状态机
对竞赛和队伍的状态管理，初期建议用简单的状态字段加代码判断，不要一上来就上状态机框架。但是要提前画清楚状态流转图。竞赛的状态最少是：草稿 → 进行中 → 已结束（或取消）。队伍的状态流转是：报名中 → 已提交作品 → 已评分（或已淘汰）。
我在实际开发中就踩过这样一个坑：管理员把竞赛状态改为“已结束”后，学生还能通过直接调用接口提交作品，因为没有在提交接口里校验竞赛状态。这类问题在答辩中很容易被问到：“你怎么保证业务规则的严谨性？”所以必须记住：前端只能做展示限制，真正的规则校验在Service层做。
4. 核心功能实现的关键环节
4.1 登录认证与权限控制的落地方式
登录是每个系统都有的功能，但要做得规范还是有不少细节。我在这个系统里用的是JWT + Spring Security（也可以用拦截器 + JWT，看个人熟悉程度）。JWT的好处是服务端无需存储会话状态，配合Redis做黑名单即可处理退出登录。
具体流程先简单说：用户请求登录接口 → 校验验证码（用Redis存验证码，有效期5分钟）→ 校验用户名和密码 → 通过后生成JWT令牌返回前端 → 前端后续请求在请求头携带该令牌 → 后端的拦截器或过滤器解析令牌并放入当前用户上下文。
这里有几个容易出错的地方。其一是密码加密必须用BCrypt，不要用MD5。MD5在答辩里被追问安全性时非常尴尬。其二是JWT的密钥不要硬编码在代码里，建议放在配置文件或环境变量中。其三是拦截器放行路径要规划好，像登录、注册、验证码接口都要放行，但其余接口必须校验。如果用了Spring Security，注意放行路径和安全过滤器的执行顺序，很容易配错导致页面全部跳转登录。
4.2 竞赛管理的Service层要点
竞赛管理的核心方法是发布竞赛、更新竞赛、改变状态、查询列表。这里重点讲Service层的逻辑边界。
发布竞赛时要做的事务操作不止是插入记录，还需要初始化一些配置数据，比如生成默认评委分配规则、初始化赛程参数。如果如果还是简单的插入一条记录而没有做任何关联初始化，后面分配评委时就会缺数据。
再比如说，更新竞赛允许改哪些字段要拿捏好。报名时间已经结束时不允许改截止时间到过去，竞赛已有队伍报名时不建议修改人数上限。这些限制可以实现为“编辑提交后的业务校验”，而不是依赖页面表单的禁用。后端接口的健壮性就是这么一点一点补出来的。
竞赛列表的查询还有一个性能问题要考虑。当竞赛数量不大时无所谓，但一旦积累了几年数据，联表套联表会让页面变得很慢。建议列表接口只返回主表信息和必要的统计字段（比如报名人数），详情页再走单独接口查询完整信息。或者用MyBatis-Plus的分页插件配合一个简化的VO类，不做无谓的联表。
4.3 报名与队伍创建时的并发控制
学生报名是典型的并发场景。同一竞赛的最后几个名额，多个学生同时点击报名，如果没有控制就可能超员或产生重复队伍。这里我比较推荐在MySQL层面做一个利落的条件约束。具体的做法是：
在创建队伍表的插入语句中，可以先查当前赛事下的队伍总数，再判断是否少于max_team_数量。这是通过查库判断，在高并发下并不可靠。要用乐观锁（用版本号）或数据库唯一约束来兜底。比如竞赛ID+队长ID做成联合唯一索引，杜绝同一个人在同一竞赛创建多个队伍；再把队伍上限的判断放到事务里，配合行级锁（SELECT ... FOR UPDATE）来计数。
不过说句实在话，一个学校内部系统并发量不会多高，做一个基于数据库的计数判断和唯一约束就够用了。但你必须在答辩时讲清楚“我考虑了并发安全问题”，这个陈述加分的价值远比实现一套完整分布式锁的实操意义更大。
4.4 作品上传模块的文件处理细节
作品上传是整个系统中容易出问题的一环。你不需要做复杂的断点续传，但基本的要求要满足：文件类型限制、文件大小限制、存储路径规划、文件名防重。
我建议用本地存储作为起步，不要一开始就接对象存储OSS，除非你有现成的服务器。将上传文件保存在服务器的一个专用目录下，然后通过虚拟路径映射对外提供访问。在文件名处理上，用UUID拼接原始扩展名，避免中文名和特殊字符引发的乱码问题。
在Spring Boot中配置文件上传大小限制要改两个地方：一个是spring.servlet.multipart.max-file-size，一个是max-request-size。很多同学只设置了max-file-size，结果提交一个大表单里的多个文件时报错，就是这个原因。
4.5 评分模块的算法选择与公平性
打分模块的设计直接体现你对业务的理解。最简单的评分模式是每个评委给一个分数，取平均分。但实际竞赛中会有一些要求：去掉一个最高分和最低分再平均；按组评委的打分权重不同；评委未完成评分时有默认标记处理。
我的建议是设计成绩表时把原始分、最终分和评分状态都保存下来，最终分的计算逻辑放在Service层。比如先查出该作品的所有打分记录，按照评分规则排序，去掉最高和最低，再求平均。这个计算不复杂，但要注意评委未评分的占位问题，不能在算平均分时把0分当有效成绩，否则直接拉低平均分。
另外一个常见需求是排行榜的实时更新。成绩要动态变化，不能每次都在页面加载时全量重算。可以做一个点击“生成排名”或“成绩确认”时才落库的最终排名表。准确说就是评分过程中看分页列表用临时统计，等到管理员确认公布时再写死最终结果，避免最后一个评委改分导致前端排名频繁跳动。
5. 开发过程中常见的坑与排查技巧
5.1 跨域问题与登录失效
前后端分离时的跨域问题几乎人人都会遇到。Spring Boot处理跨域比较简单，写一个WebMvcConfigurer配置CorsMapping即可。但要记住，如果使用了Spring Security，那么必须保证安全过滤器链中对该跨域预检请求OPTIONS放行。否则后端CORS配置写了也没用，请求照样被拦截。
还有一个典型问题是JWT时长太短导致用户操作过程中突然登录失效。我给系统定的是access_token有效期为2小时，refresh_token有效期7天，因为毕设到演示环节时，最尴尬的时刻就是讲着讲着突然要求重新登录。如果只是做演示用，甚至可以把过期时间设久一些。这个建议虽然“不工程”但很实用，答辩演示的第一要义就是别出意外。
5.2 时间字段的时区大坑
数据库连接串没有配置serverTimezone时，MySQL连接经常报异常或者时间相差8小时。建议连接串明确写serverTimezone=Asia/Shanghai。同时，后端接收前端时间参数时，如果使用LocalDateTime，需要用@JsonFormat注解明确格式。这两个点处理不好，你会看到竞赛开始时间总和自己设定不一样，排查起来特别痛苦。
5.3 分页传参的模糊坑
列表页做分页时，常见报错是“total未识别”或者返回的records是空，但数据库中明明有数据。大部分原因是MyBatis-Plus分页插件没有配置分页拦截器。很多人只是引入了分页依赖但忘了加MybatisPlusInterceptor的Bean，导致分页不起作用。这个问题几乎每周能在技术群里看到好几遍，自己做过一次以后就有印象了。
5.4 状态更新的幂等性设计
修改队伍状态、审核报名、确认成绩等操作都涉及状态变更，极易出现重复点击导致数据错乱。比如管理员连点两次“通过”，如果没有做前置状态校验，吕布的“驳回”状态就会被第二次操作覆盖或者两次提交产生多条日志。解决办法其实很简单：更新语句里带上当前状态条件（UPDATE ... WHERE status = ?），或者用乐观锁字段。我推荐前者，简单直接，并且天然幂等。
6. 从“能用”到“有深度”的加分思路
6.1 加一个简单但漂亮的数据报表页
毕业设计如果只有增删改查，确实偏薄弱。在不影响核心流程的前提下，建议加一个统计报表页面。用ECharts展示：各级别竞赛数量分布、每届报名人数趋势、热门竞赛Top 10、评委评分分布图。实现上不需要太复杂，后端写一两个聚合查询返回Map或VO，前端拉到数据后交给ECharts渲染。这比空谈“我用了很多技术”更有说服力，因为它是可见的、可演示的。
6.2 增加操作日志与通知机制
另一个性价比较高的功能是操作日志和通知站内信。核心操作（创建竞赛、审核报名、打分、发布结果）都记录日志，管理员可以在后台查看操作记录。同时，状态变化时给学生发站内通知（报名成功、作品被退回、成绩已公布）。这两块的技术难度不高，但能让答辩演示时讲出“闭环”两个字。系统不是只管登记数据，而是把流程中的信息反馈也做上了。
6.3 项目文档与答辩准备的几条心得
做毕业设计不只是写代码，文档和演示话术也要提前准备。我的习惯是画两张图：一张是系统功能架构图，一张是数据库ER图，答辩演示时讲解效率会高很多。另外，把系统开发中遇到的真实问题记录下来，比如“JWT跨域设置踩坑”或者“并发报名时如何保证数据一致性”，答辩时一旦老师问“项目中遇到的难点”，直接讲这些实际案例，远比你背书式说“我的系统使用了很多主流技术”更有说服力。
还有一个摆上台面的经验：不要把项目工程文件一股脑放上去。检查下target目录、数据库脚本、README、启动文档，这些都必须整理清楚。把项目从绿色干净的环境启动起来，准备一份简单开发文档，说明JDK、MySQL、Redis、Node版本要求，能顺畅跑起来比多写两个接口重要得多。毕设答辩现场时间有限，能顺利打开页面、走通流程、讲清楚重点设计，就已经赢过一半以上的人了。
这套系统我是基于常规配置一点点搭建起来的，组合并不新奇，但它每一块都能自圆其说。最后再分享一个私人小习惯：从头到尾把核心流程录成一段短视频，答辩前自己回放一遍。很多bug和演示时的卡顿，其实在你录视频的时候就已经暴露出来了，提前解决比现场慌乱要安心得多。