作为一个带过不少毕业设计、也在高校信息化这块踩过坑的人，我特别理解为什么“计算机毕设 java 大学生学科竞赛管理系统”这类题目会长期热门。它听起来像最普通的“增删改查”，但真做起来，里面藏着报名时间窗口、团队人数限制、评审打分规则、文件上传安全、权限控制这一整套业务闭环。这篇文章会把这个项目从头拆到尾，讲清楚每个核心模块为什么这么做、代码怎么落、有哪些坑要提前避开，无论是拿它当毕设还是课程设计，都能少走不少弯路。
高校学科竞赛管理，说到底解决的是一个很现实的效率问题。以前很多学校办竞赛，靠的是QQ群发通知、Excel收集报名信息、邮箱收作品、评审专家收到一堆压缩包，然后人工汇总成绩。数据一多就乱，时间一长就忘，出错是常态。做一个基于 Java 的竞赛管理平台，就是把“发布竞赛公告、学生在线报名、组建团队、提交作品、专家评审打分、管理员核发成绩与证书”这条完整流程搬到线上。这个方向非常适合毕设，因为业务场景真实、模块边界清楚、技术栈范围可控，同时又有足够的空间展示数据库设计、事务处理、文件上传、权限控制这些面试和答辩常问的东西。
1. 项目整体设计与思路拆解
1.1 高校学科竞赛管理的核心痛点
做系统之前，得先把自己当成使用者，去走一遍竞赛从发起到底结束的完整流程。竞赛管理员要先发一个通知，说清是什么比赛、谁可以参加、报名截止时间、作品格式要求、评审规则。学生看到通知后要报名，还得拉上队友，三个人还是五个人，每个队的成员信息要核对。报名截止后，参赛队要上传作品文档、演示视频或者工程压缩包。评审专家要在线打分，不能互相看见结果，最后系统自动算平均分、排名，管理员再导出成绩表。证书有的比赛要发电子版，有的要发纸质版，这些都由系统支撑。
传统手工方式的问题在这里非常突出。报名信息用多个Excel版本传来传去，经常出现最新版本覆盖旧版本的冲突；作品通过邮箱发送，超过附件大小限制就被退回，文件名混乱、覆盖同名文件；评审阶段专家各自打分，统计时需要反复核对，还容易算错。从这个视角看，竞赛管理系统的功能需求一点也不虚，每个模块都能对应到真实的痛点。这也是我做这个项目时反复强调的：不要一上来就写代码，先把业务痛点和流程画出来，你的功能设计自然就有了依据。
1.2 毕设选型思路：为什么用 Java 生态做这题
不少同学会纠结，选 Java 还是别的语言。我的建议是，如果学校主流的课程、毕业设计案例都是 Java，那就不要轻易换赛道。Java 生态里做管理系统的方案太成熟了，Spring Boot 加 MyBatis Plus 的组合，能让你把精力从配置地狱里解放出来，专注在业务逻辑上。这个项目用 Java 做还有一个隐形的优势：在答辩时，你可以很自然地说清楚三层架构、依赖注入、事务管理是怎么回事，这些概念在 Java 里讲起来最顺。
我在实际指导模拟项目时，见过有人把技术栈定为 Spring Boot + Vue 前后端分离，结果前端工程目录都没创建好就放弃了；也有人用 JSP + Servlet 写到一半，发现页面渲染太痛苦，模板代码重得没法维护。对这个项目而言，Spring Boot + Thymeleaf 或者 Spring Boot + Vue 都是可行的，关键是看你的时间成本和前端基础。如果是想稳稳毕业，用户管理、竞赛管理这些后台页面用服务端渲染就够了；如果你想去面互联网公司，想多展示一些前端能力，那就选择前后端分离。技术选型不是越新越好，而是越合适越好。
1.3 功能模块与角色权限的整体设计
竞赛管理系统通常有四种核心角色：平台管理员、学院管理员、评审专家、学生。平台管理员负责创建竞赛、设置评审规则、发布公告、最终审核；学院管理员主要看本院报名情况，偶尔代为登记；评审专家只在自己被分配的竞赛作品范围内打分；学生负责报名、组队、上传作品、查看成绩。围绕这些角色，功能模块可以拆成这几个大块：
- 系统管理：用户管理、角色管理、菜单权限、操作日志。
- 竞赛管理：创建竞赛、设置时间节点、配置报名条件、管理竞赛类别。
- 报名管理：学生报名、队伍创建、成员审核、报名名单导出。
- 作品管理：作品上传、作品替换、格式校验、文件下载。
- 评审管理：专家分配、评分表配置、在线打分、总分统计。
- 结果管理：成绩发布、获奖等级计算、证书生成与查看。
- 公告与统计：站内公告、报名人数分析、获奖趋势统计。
第一版只需要把这些核心模块做完，保证流程能闭环，就是一份很有说服力的毕设。很多同学容易犯的错是，一开始就追求花哨的权限框架或者微服务，结果基础功能都写不完。我建议把“流程跑通”放在第一位，权限安全、性能优化都是后话。
2. 技术选型与数据库设计
2.1 后端框架、前端渲染与部署方案的搭配
这个项目的技术栈，我给一个被验证过很多次的推荐方案：Spring Boot 2.7 + MyBatis Plus + MySQL 8 + Redis + JWT + Thymeleaf + Bootstrap。如果做前后端分离，把 Thymeleaf 替换成 Vue 3 + Element Plus，后端额外提供 REST API 和跨域配置即可。由于是毕设，尽量用稳定版本。Spring Boot 3 + JDK 17 也可以，但要注意 MyBatis Plus 和 Spring Security 的兼容版本，容易踩坑。
Spring Boot 负责提供 HTTP 接口和页面渲染，内嵌 Tomcat 让部署变得非常简单，一个 jar 包就能跑起来。MyBatis Plus 相比原生 MyBatis 最大的优势是单表 CRUD 不需要写 SQL，分页查询也有现成的插件，这对开发效率提升明显。Redis 用来存验证码、登录 token、以及竞赛状态这种会被高频读取的数据；如果机器上没装 Redis，也可以先用 Caffeine 本地缓存顶一顶，但毕设答辩时有 Redis 是加分项。密码存储用 BCrypt，这一点千万别省。
2.2 数据库表结构设计：核心实体与关系
数据库设计的好坏，直接决定后面写代码是顺滑还是痛苦。竞赛管理系统最少需要这样几张表：
user：用户账号表，字段包括 id、username、password（BCrypt 密文）、real_name、college_id、role_type、phone、email、create_time。competition：竞赛主表，字段包括 id、title、type、description、报名开始/结束时间、提交开始/结束时间、评审开始/结束时间、状态、创建人、create_time。team：团队表，字段包括 id、competition_id、team_name、captain_id、creation_time、member_count、状态。team_member：团队成员关联表，字段包括 id、team_id、student_id、role_in_team。work：作品表，字段包括 id、competition_id、team_id、work_title、abstract、file_path、file_size、submit_time、status。review_rule：评审规则表，配置每个竞赛有哪些评分项，比如创新性、完整性、实用性和每项的权重。score：评分表，字段包括 id、work_id、reviewer_id、rule_id、score_value、comment、review_time。winner：成绩结果表，字段包括 id、competition_id、team_id、total_score、rank、award_level。
表之间的关系要清楚：竞赛和团队是一对多，团队和学生是多对多，通过 team_member 关联；作品和团队是一对一；评分表和作品、专家、评审规则分别是多对一。关键字段要加索引，比如报名表的(student_id, competition_id)联合唯一索引，这个索引能避免同一个学生重复报名同一个比赛。下面这段 SQL 是核心的三张表，数据库类型用的 MySQL，字符集统一用utf8mb4，这样中文和特殊符号都不会出问题：
CREATE TABLE `competition` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `title` varchar(200) NOT NULL COMMENT '竞赛名称', `type` varchar(50) DEFAULT NULL COMMENT '竞赛类别', `signup_start` datetime DEFAULT NULL COMMENT '报名开始时间', `signup_end` datetime DEFAULT NULL COMMENT '报名结束时间', `submit_start` datetime DEFAULT NULL COMMENT '提交开始时间', `submit_end` datetime DEFAULT NULL COMMENT '提交结束时间', `status` tinyint(4) DEFAULT 0 COMMENT '0草稿 1报名中 2评审中 3已结束', `deleted` tinyint(4) DEFAULT 0, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `team` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `competition_id` bigint(20) NOT NULL, `team_name` varchar(100) NOT NULL, `captain_id` bigint(20) NOT NULL, `member_count` int(11) DEFAULT 1, `status` tinyint(4) DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_competition_id` (`competition_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `team_member` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `team_id` bigint(20) NOT NULL, `student_id` bigint(20) NOT NULL, `role_in_team` varchar(20) DEFAULT '成员', PRIMARY KEY (`id`), UNIQUE KEY `uk_student_competition` (`student_id`,`team_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;表名和字段名尽量用有意义的英文，注释写清楚，公司里的代码规范也是这样要求的。答辩时老师会看你的数据字典，设计得越完整，说明你对业务理解越到位。
2.3 文件存储和缓存方案怎么设计
文件上传是竞赛管理系统逃不掉的功能。作品可能是几百兆的压缩包，也可能是PDF文档和视频，不能一股脑塞进数据库。比较稳妥的做法是把文件存到服务器本地磁盘，路径按“日期/竞赛ID/队伍ID/UUID文件名”的规则组织，数据库只存相对路径。上传时用 UUID 重命名文件，既能防止中文文件名导致的编码问题，也能避免路径穿越攻击。把文件存 OSS 也是好方案，但毕设项目一般没有云资源，本地存储就够用，答辩时也能解释清楚。
Redis 在这个项目里主要做三件事：第一是登录验证码的存取，第二是登录后 JWT token 的黑名单或续期处理，第三是竞赛状态、公告等热点数据的缓存。比如用户打开首页要查“有哪些报名中的竞赛”，如果每次查数据库，压力有点大，可以把这个列表缓存到 Redis，竞赛状态变更时删掉缓存。这里要注意缓存一致性，我的建议是“先更新数据库，再删除缓存”，不要反过来。
3. 核心功能实现：从登录鉴权到竞赛流程闭环
3.1 用户认证与权限控制的实现方式
登录鉴权是每一个系统都绕不开的模块。我推荐用 JWT + Spring Boot 拦截器的方式，别看它简单，足够应付这个项目。整体思路是：用户输入账号密码和验证码，后端用 BCrypt 检查密码，匹配成功后生成一个包含用户 id、username、角色 roleType 的 token，过期时间设为2小时。前端把 token 放在浏览器的 localStorage 或者通过 Cookie 保存，之后每次请求在 Header 里带上Authorization: Bearer <token>。
后端写一个拦截器，对所有需要登录的接口做校验。这里不仅要做登录验证，还要做角色判断，即在 Controller 的方法上通过自定义注解标注允许访问的角色。用拦截器 + 自定义注解的好处是权限逻辑集中，不用在每个 Controller 里重复写 if 判断。比如平台管理员要删除用户、创建竞赛，评审专家只能提交评分，学生只能报名和传作品。角色判断的详细逻辑可以放在工具类里，代码会很干净。密码加密一定用BCryptPasswordEncoder，不要用 MD5，更不要明文存储。
3.2 竞赛发布与报名流程的前后端配合
管理员创建竞赛的核心不是填个标题，而是设置好时间节点。时间节点一旦错乱，后续报名、提交、评审都会出问题。我建议建一张配置表或者直接在竞赛表里加字段存储“报名开始时间、报名结束时间、作品提交截止时间”，并且在前端表单里做联动校验，比如报名结束时间必须晚于报名开始时间，提交截止时间必须晚于报名结束时间。后端也要校验一次，不能只信前端。
学生报名流程建议设计成两步。第一步创建队伍，队长填写队伍名称，选择竞赛；第二步邀请或者直接添加队员，每个队员在系统里要有账号（可以由管理员预先导入）。这样设计的理由是，队伍是一种可以被复用的实体，同一个队伍可能参加多个竞赛，虽然绝大多数业务里一个队伍只参加一个竞赛，但概念上要注意。报名时最重要的校验是：
- 当前时间必须在报名开始和结束之间。
- 学生没有在该竞赛中已有有效报名记录。
- 队伍成员数不能超过该竞赛配置的上限。
这些校验必须同时出现在前端提示和后端事务里，否则并发情况下容易重复报名。用@Transactional把创建队伍和添加成员包在一个事务里，中间任何一步失败，整个队伍都不应存在。下面是一个后端的校验片段：
@Transactional(rollbackFor = Exception.class) public Long createTeam(CreateTeamRequest req) { Competition competition = competitionMapper.selectById(req.getCompetitionId()); // 判断时间窗口 LocalDateTime now = LocalDateTime.now(); if (now.isBefore(competition.getSignupStart()) || now.isAfter(competition.getSignupEnd())) { throw new BizException("不在报名时间内"); } // 判断当前用户是否已有队伍 Integer count = teamMapper.countByCompetitionAndStudent(req.getCompetitionId(), getCurrentUserId()); if (count != null && count > 0) { throw new BizException("你已经报名过该竞赛"); } Team team = new Team(); team.setCompetitionId(req.getCompetitionId()); team.setTeamName(req.getTeamName()); team.setCaptainId(getCurrentUserId()); team.setMemberCount(1); teamMapper.insert(team); TeamMember captain = new TeamMember(); captain.setTeamId(team.getId()); captain.setStudentId(getCurrentUserId()); captain.setRoleInTeam("队长"); teamMemberMapper.insert(captain); return team.getId(); }这段代码的核心在于把“业务规则校验”放在一个事务边界内。实际生产里还可以把时间校验提取成一个公共方法，后面提交作品、评审打分时都要用。
3.3 作品提交与附件上传下载的实现细节
作品提交是竞赛系统里技术含量最高的模块之一。首先得定义文件限制，我通常把作品总大小上限设为 50MB，单文件设置成 50MB，防止因为误传超大型视频把服务器磁盘打满。上传接口接收 MultipartFile 之后，先判断当前是否在提交时间窗口，再校验文件扩展名和大小。扩展名校验要用白名单，不要用黑名单；比如.zip、.rar、.pdf、.docx、.mp4是允许的，其他一律拒绝。
文件保存路径不要直接把原始文件名拼接进去。比如提交的文件名是../../etc/passwd，路径拼接很容易出问题。正确做法是使用UUID.randomUUID().toString()生成新的文件名，并把扩展名保留下来，然后通过Paths.get(uploadDir).resolve(fileName).normalize()保证最终路径不会越界。保存文件后，把相对路径、原始文件名、文件大小、所属队伍、所属竞赛写进作品表。
下载接口要注意设置响应头，否则浏览器可能会直接预览而不是下载。核心代码是：
response.setContentType("application/octet-stream"); response.setHeader("Content-Disposition", "attachment; filename=" + URLEncoder.encode(originalFilename, StandardCharsets.UTF_8));另外，作品上传之后要允许队伍在截止时间之前重新提交，实现时可以给作品表加一个版本号或者“最新状态”字段，每次重新上传逻辑上覆盖旧作品，物理删除旧文件。删除文件时注意路径拼接同样要严谨。
3.4 评审打分与成绩结算的状态控制
评审模块的设计要满足两个关键场景：一个竞赛有多个专家，一个作品要被多个专家评，最终成绩要按加权平均或者去掉最高最低分计算。先把评审规则设计成一张可配置的表，管理员在创建竞赛时可以设置评分项，比如“创新性20%、完整性30%、实用性30%、演示效果20%”。专家进入评审页面后，只看被分配的作品，输入每个评分项的分数，系统自动算总分。
为了避免专家之间互相影响，评分结束后才统一发布成绩。在数据库层面，给评分表加一个唯一约束，比如(work_id, reviewer_id, rule_id)唯一，防止同一个专家对同一作品重复打分。如果允许重新评分，则需要加一个version字段做乐观锁，提交分数时检查版本号一致再更新。成绩发布后，后台按每个作品的平均分排序，然后根据竞赛配置的一二三等奖比例生成获奖等级。这里要注意，处于“评审中”的竞赛，所有人都不应该看到分数；分数发布后，学生端统一展示排名和奖项，这个过程用竞赛状态字段来控制，简单可靠。
4. 关键难点与工程化细节
4.1 多角色、多状态的操作权限控制
很多同学写着写着就会陷入一堆 if else 判断。比如，管理员能创建竞赛，学院管理员能导出本院学生名单，学生能修改自己队伍的信息，专家能评分。如果你把这些判断全部散落在 Service 里，代码会越写越乱。我的建议是先把“谁在什么状态下能操作什么数据”这个矩阵写清楚。以竞赛为例，状态有草稿、报名中、评审中、已结束，可执行的操作有编辑、删除、发布、报名、传作品、评分、导出成绩。不同角色能执行的操作完全不同。
我自己在模拟项目里用的是简单策略：Controller 层只做参数校验和角色判断，Service 层只做业务逻辑。角色判断通过自定义注解或拦截器处理，业务状态判断抽成方法，比如checkCompetitionCanSignUp()、checkCompetitionCanSubmit()、checkCompetitionCanReview()，谁调用谁清楚。这种命名方式看着普通，但维护起来非常舒服，答辩的时候让老师看到你有这种“状态机意识”，非常加分。
4.2 文件上传的路径安全与存储目录设计
这里要专门提醒一个经验：不要把上传目录放在项目的 classpath 下，也不要放在/tmp这类会被系统清理的位置。建议单独建一个配置目录，比如/data/contest-upload/，然后在application.yml里配置upload.base-dir。这样即使系统重启或者重新打包部署，文件也不会丢。访问上传文件时，Spring Boot 默认不会把你磁盘上的任意路径映射成静态资源，需要自己写一个 Controller 接口或者配置资源映射。用 Controller 接口的好处是可以顺便做权限验证，比如只有该队伍的成员、管理员、评审专家才能下载对应作品，避免任何知道 URL 的人都能下载他人作品。
我在实际开发中遇到过一个问题：上传文件名包含中文，下载时浏览器显示乱码。解决办法是在 Content-Disposition 里使用filename*=UTF-8''格式，并对原始文件名做 URL 编码，前文已经给出过代码。还有一点是删除旧文件时不要用File.delete()后马上判断返回 false 就报错，有些环境因为文件句柄未释放会删不掉；建议用Files.deleteIfExists()。
4.3 并发报名、重复评分与数据一致性问题
虽说是毕设，老师也会关心并发问题。报名瞬间可能几十个人同时点提交，如果不加限制，同一个学生可能创建多个队伍。解决这种问题有两种思路：一种是数据库加唯一索引，捕获 DuplicateKeyException 后提示“请勿重复报名”；另一种是使用 Redis 分布式锁，锁的 key 可以设为signup:lock:{competitionId}:{studentId}。对毕设来说，数据库唯一索引是必须做的，分布式锁可以作为亮点提。
队伍人数限制也有并发问题，比如竞赛要求最多5人，第6个人同时申请加入时，如果只是先查 count 再判断，可能会同时通过。正确做法是在更新队伍成员数时使用带条件的 SQL：UPDATE team SET member_count = member_count + 1 WHERE id = ? AND member_count < #{maxMember}，影响行数为0就说明人数已满。这个写法很实用，能避免在业务代码里二次查询。
评审打分阶段也一样，如果专家连续点击提交，可能插入两条评分。除了唯一约束，还可以在 Service 里加乐观锁检查。数据一致性是答辩时容易出彩的点，花点时间把并发控制想明白，收益很大。
4.4 数据统计与图表展示怎么做
高校学科竞赛管理系统往往需要一个数据看板，用来展示竞赛数量、报名人数、获奖人数等。后端提供几个聚合统计接口，前端用 ECharts 画柱状图、饼图。比如统计“近一年各学院报名人数”的 SQL：
SELECT c.id AS competition_id, c.title AS competition_name, u.college_name, COUNT(DISTINCT tm.student_id) AS student_count FROM competition c LEFT JOIN team t ON c.id = t.competition_id LEFT JOIN team_member tm ON t.id = tm.team_id LEFT JOIN user u ON u.id = tm.student_id WHERE c.status = 3 GROUP BY c.id, u.college_name ORDER BY c.id;统计接口要注意性能。如果竞赛数量不多，直接用 MyBatis 写关联查询没问题；如果数据量大，可以提前在竞赛结束时把统计结果快照到一张统计表，前台展示查快照表，速度更快。前端展示时注意日期格式，很多后端接口返回时间戳，前端要格式化后再显示。
5. 常见问题与排查技巧实录
5.1 Spring Boot 启动时报端口被占用怎么办
开发过程中最常见的报错就是Port 8080 was already in use。可能是之前启动的程序没关掉。Windows 下可以用netstat -ano | findstr 8080找到 PID，然后在任务管理器里结束对应进程；或者图省事，在application.yml里把server.port改成8081。建议不要随意换端口，特别是前后端分离时前端代理写死了后端口，换来换去容易乱。
5.2 数据库查询出的中文显示乱码
中文乱码一般有三个原因：MySQL 数据库表的字符集不是 utf8mb4、JDBC 连接串缺少编码参数、页面返回时响应没有设置 UTF-8。连接串务必写成这样：
jdbc:mysql://localhost:3306/contest?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai如果数据库已经建好了，用一条 SQL 把表转成 utf8mb4 也行。另外，Spring MVC 的响应乱码可以在配置文件里设置强制 UTF-8。最省事的办法是创建数据库时统一执行ALTER DATABASE xxx CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci。
5.3 上传大文件时报 multipart 超过限制
Spring Boot 默认单个文件最大 1MB，总请求 10MB，所以上传 50MB 作品必超限。解决方式是在application.yml里显式配置：
spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB配置后如果还是报错，注意排查是不是用了 Nginx 反向代理，Nginx 的client_max_body_size也需要调整。
5.4 分页查询不生效或返回数据是同一页
如果用了 MyBatis Plus 的Page，但没有配置分页插件，你会发现selectPage返回的总条数不对，或者 SQL 里根本没有LIMIT。记得新建一个配置类：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }排查分页问题的最快方法是打开 MyBatis 的 SQL 日志，看打印出来的语句里有没有 LIMIT。
5.5 前后端分离模式下接口跨域报错
如果你选择了前后端分离，后端接口地址是http://localhost:8080，前端开发服务器是http://localhost:5173，之间必然产生跨域。后端可以写一个跨域配置类实现 WebMvcConfigurer，直接允许本地请求的跨域访问。答辩演示时域名可能不同，写成一个允许指定来源的配置，别用*全开放。
6. 项目扩展与答辩准备心得
6.1 项目亮点怎么在答辩时讲清楚
答辩时不要从头到尾背代码，老师更想听你把“业务理解”讲明白。建议按照这样的逻辑组织：先讲这个系统解决了哪些手工操作痛点，再说核心数据表是怎么设计的，然后演示一条完整流程，最后讲一两个技术难点，比如文件安全上传、并发报名控制、评分状态管理。如果项目里用了 Redis 缓存、JWT 鉴权、AOP 日志，都要主动提，这些是老师特别关注的加分项。
我带的模拟项目里，很多同学会忽略对“异常处理”的设计。如果你能在全局异常处理里统一拦截BizException并返回友好提示，而不是让系统弹出500错误页，答辩印象分会明显提升。还可以加上操作日志功能，记录管理员在关键节点的修改动作，这个不仅实用，还能展示你在工程化方面的思考。
6.2 扩展方向：消息通知、证书生成、小程序端
核心流程做完后，如果还有余力，可以考虑几个高性价比扩展方向。第一是消息通知模块，报名截止前通过站内信或者邮件提醒学生，展示率很高。第二是电子证书生成，用 POI 或 PDF 库读取模板，填上队伍名、奖项名，导出带学校 Logo 的 PDF 证书，这个功能演示效果非常好。第三是移动端适配或者小程序端，做一个简化版查询页面，学生可以用手机查看竞赛动态和获奖结果，也符合当前高校信息化建设的趋势。这些扩展方向的代码量不会太大，但能显著提升项目的完整度。
扩展时要控制范围，不要想着全做完。对毕设来说，核心流程稳定可用，再有一两个亮点足以拿高分。最怕的是 AOP 还没搞清楚就去写微服务，到最后整个项目跑不起来。
6.3 最后分享一点个人实际操作的体会
做完这个竞赛管理系统，我最大的体会是：写系统之前先花两天时间把“流程”想清楚，比上来就敲代码重要得多。竞赛管理系统本质上就是一条时间线：报名、提交、评审、发布，每一个阶段都有严格的起止时间，状态一改，所有角色的操作权限都会变化。把这个状态流转模型先画清楚，后面写代码会顺畅很多。
开发过程中还要养成“每个异常都认真看堆栈第一行”的习惯。很多同学一报错就慌了，把整个控制台日志复制下来贴到群里问，其实 Spring Boot 的异常信息已经写得很明确。我建议你遇到问题先试着翻译成中文描述，再用关键词搜一下，绝大多数坑在网上都能找到答案。最后一个小技巧：在项目里多写业务校验的提示信息，比如“当前不在报名时间范围内”“该竞赛已截止提交”，把提示写得像给真实用户看的，演示的时候就不会干巴巴了。
