企业官网建设流程全解析

不用纠结系统名字到底叫“大学生科技竞赛管理系统”还是“大学生科技创新竞赛系统”，这类基于Java+SpringBoot+SSM的毕设项目，核心功能、页面形态和技术栈都大同小异。我今年已经带学生做完两套一模一样的题，源码、LW（论文）、调试文档、答辩PPT全流程走下来，踩过的坑、优化过的方案都在脑子里。这篇就把这套系统的完整玩法拆开讲透，后台管理、前台展示、教师评审、学生报名、成绩公布，整个流程怎么在SpringBoot+SSM的技术架构里落成实际项目，每一步该怎么做、为什么这么做、有哪些弯路可以提前避开，直接给你抄作业的完整方案。

这套系统解决的是高校里头最典型的一个需求：各种科技竞赛从发布通知、学生报名、提交作品，到评委打分、成绩公示，全流程都靠手工和Excel，过程乱不说，数据还容易丢。系统就是把这些流程线上化，做成一个让管理员、老师、学生三类角色各干各事的管理平台。适合正在做毕设的计算机专业学生、想练手SpringBoot+SSM的初级开发者，以及想快速搭一个完整管理系统模板的人参考。

1. 项目概述与核心需求拆解

1.1 这类系统到底在解决什么问题

高校科技竞赛的管理，看上去就是“发通知-收报名-评作品-出成绩”四步，但实际跑到线下时，痛点非常具体。通知散落在QQ群和辅导员朋友圈，学生经常错过报名时间；报名信息靠Excel汇总，字段对齐全凭人工，一个同学填错学号就往返半天；作品提交格式五花八门，文件命名完全不统一，评委下载下来还要自己对着名单找作品。等到打分环节更头疼，纸质评分表收集后手动录入Excel，汇总算分容易出错，学生质疑成绩时还拿不出透明的依据。

这套“大学生科技竞赛管理系统”就是把上面这条杂乱的线下链路，完整映射到线上。学生端能看赛事公告、在线报名、上传作品、查自己成绩；教师端能审批报名、下载作品、在线打分、提交评语；管理员端负责系统核心数据的维护，包括用户管理、赛事配置、评审计分规则设置、成绩审核发布。整个流程一闭环，催材料、录成绩、找通知的沟通成本就大幅降下来了。

1.2 标题里那些关键词的实际含义

项目标题里反复出现了“源码、LW、调试文档、讲解”这些词，说白了就是一个标准的毕业设计交付物集合。“LW”是“论文”拼音缩写，对应毕业论文文档；“调试文档”是记录环境配置、部署过程、可能遇到的问题及解决方法的说明文件；“讲解”通常指录制好的演示操作视频或答辩讲解思路。做这套系统不能只写代码，上述配套材料才是决定你能不能顺利通过答辩的关键，后面我会单独拿出一节专门讲怎么把文档配合起来写。

技术关键词则是“Java+SpringBoot+SSM”，这组词放在一起容易让人困惑——SSM本身就已经是Spring+SpringMVC+MyBatis三件套了，SpringBoot的出现是把Spring生态做成了一站式脚手架。在实际项目里，SpringBoot作为基础框架承载一切，SpringMVC接管Web层请求路由，MyBatis负责数据库操作，完整的SpringMVC分层逻辑被保留在Boot的自动化配置之上。换句话说，SpringBoot是骨架，SSM是血肉，两者不冲突。

1.3 适合什么人参考这套方案

如果你正在为选题发愁，这类系统非常适合作为毕设项目，因为它踩中了几个关键优势：技术栈主流，面试聊起来有支撑；业务逻辑清晰，没有算法上的深坑；功能模块天然适合画流程图和用例图，论文素材好凑；开发周期在三周到一个月内可控，不会卡进度。

如果你已经是个能独立写增删改查的开发者，那这套系统最大的价值不在CRUD本身，而在于它的角色权限设计、赛事状态流转、评审规则可配置化这几块，这些才有真正的设计含量。后面我会把这几部分单独展开讲。

2. 技术选型：为什么是SpringBoot+SSM这套组合

2.1 SpringBoot与SSM的关系辨析

先说一个很多初学者会混乱的点：SSM和SpringBoot是不是二选一？正确答案是，SpringBoot本身就是Spring生态的快速开发框架，它非但没有抛弃SSM三件套，反而把SpringMVC和MyBatis更好地整合了进来。在SSM时代，你需要自己写大量的XML配置文件——数据源配置、事务管理、Mapper扫描、视图解析器，每一步都要手动接线；到了SpringBoot这里，大部分配置变成了自动装配，你只需要引入对应Starter依赖，再在application.yml里写几行关键参数，项目就能跑起来。

具体到系统落地，SpringBoot负责提供Web运行环境和自动装配机制，SpringMVC继续承担Controller层请求分发，MyBatis（或MyBatis-Plus）负责Mapper层SQL操作。我推荐在毕设项目里使用MyBatis-Plus而非常规MyBatis，它能省掉大量单表CRUD的XxxMapper.xml映射文件，内置的BaseMapper接口直接提供insert、selectById、updateById等方法，适合开发节奏紧张的毕设场景。

2.2 各层框架的具体职责分工

在一个典型的SpringBoot+SSM分层架构里，数据流向是浏览器请求→Controller层接收参数→Service层处理业务逻辑→Mapper层读写数据库→结果逆向返回并渲染到页面。我用个生活类比：Controller像餐厅门口的迎宾员，只负责领你进门、安排座位；Service是后厨掌勺的大厨，真正决定菜怎么做、食材够不够；Mapper是采购员，只跟食材供应商（数据库）打交道，菜品逻辑一概不管。

按这个职责划分，科技竞赛系统里的代码结构就非常清晰。以“学生报名某个竞赛”这个动作为例：Controller里的EnrollmentController接收POST请求，调用EnrollmentService.saveEnrollment()方法；Service层先校验报名时间是否截止、学生是否已报过该赛事，再检查团队人数上限是否超限，全部通过后才调用Mapper层写入报名记录；Mapper层通过MyBatis-Plus提供的方法或自定义SQL完成数据落库，最后把报名成功消息返回给前端。

2.3 开发环境与版本选择建议

版本选择这里，我直接给一套我实测下来兼容性最稳的组合，可以为你省不少折腾时间。

特别提醒一点，尽量避开SpringBoot 3.x。3.0之后强制要求JDK17及以上，很多老的教程、依赖版本都不兼容，你在毕设这种时间节点去处理代码升级问题非常不划算。JDK8+SpringBoot2.7这条成熟路线，遇到问题搜索引擎一搜一大把答案，能省下大量排查时间。

3. 系统功能设计与数据库建模

3.1 三类角色与权限模型设计

这个系统的用户角色分三级：管理员、教师评委、学生，权限逐级收缩。管理员负责所有基础数据维护、赛事创建审核、评审规则配置、最终成绩发布；教师评委看到的是待评审列表、学生作品下载、评分表单填写；学生能浏览赛事、报名、传作品、查成绩。

权限控制怎么做是毕设答辩时的高频考点。我推荐用SpringMVC拦截器结合自定义注解来实现，而不是一上来就上Spring Security。拦截器方案的思路是：用户登录后把用户信息和角色ID存入Session，自定义一个AuthInterceptor拦截所有请求，匹配请求URL对应的角色权限规则，无权限时直接重定向到错误页或返回JSON提示。Spring Security功能强大，但配置量对毕设来说偏重，一旦配错排查起来也比较麻烦。自定义拦截器逻辑直观、代码量少，答辩时你可以清楚地讲出每一行在干什么。

3.2 核心功能模块清单

系统内部功能大致可以分成五个模块，每个模块各自照看一条业务线。

赛事管理模块是系统的中枢。管理员在这里创建一场赛事，填写赛事名称、简介、举办单位、报名开始/结束时间、作品提交截止时间、参赛须知。创建后状态默认为“草稿”，管理员可以将其发布为“报名中”，系统同时生成供前台展示的赛事公告。

报名管理模块面向学生和教师双重入口。学生在赛事列表页选择合适的竞赛，点击报名时可以选择个人参赛或组队参赛。组队参赛需要填写团队名称、成员学号（系统校验学号是否已注册）、团队队长。教师评委可通过后台查看所有报名记录，按赛事导出Excel报名名单。

作品管理模块处理学生上传的作品文件与教师下载评阅的关联。学生报名成功后，在“我的报名”列表找到对应赛事，上传作品压缩包。系统对上传文件做格式和大小校验，保存文件到服务器本地指定目录，同时在数据库记录文件的存储路径。

评审管理模块是教师角色最常使用的功能。管理员将评委与赛事关联后，评委可在“待评审”列表中查看该赛事所有作品，在线下载文件，填写评分与评语。系统支持单人评分和多人平均分两种计分模式，由管理员在创建赛事时根据规则配置。

成绩管理模块负责打分结果的汇总与公示。管理员对提交的评分进行审核，确认无误后发布成绩。学生端只能看到自己的成绩与排名，教师端可看到完整评分明细，管理员可一键导出总评成绩表用于存档。

3.3 数据库表设计与字段取舍

数据库是这套系统的地基，我最初设计时把表拆到了12张，后来精简下来，核心表只有7张，每张都能说清楚用途，论文里画ER图也干净。

用户表（sys_user）保存用户编号、用户名、密码（MD5加密）、姓名、角色ID、学号、学院、联系方式等基础信息。有一个小坑要提醒：不要用员工编号或学号直接做主键，一旦人员信息变动会导致贯穿所有业务表的外键全部要改，所以主键统一用自增ID。

赛事表（contest）的核心字段包含赛事名称、编号、类型（科创/学科/技能）、赛事说明、报名开始时间、报名截止时间、作品截止时间、创建人ID、赛事状态（草稿/报名中/评审中/已结束）、计分模式（单人/平均）、状态流转时间记录。状态字段很关键，所有业务操作前都会先判断状态是否与预期匹配。

报名表（enrollment）记录哪些学生报名了哪场赛事，字段有报名ID、赛事ID、团队名称（个人赛则填个人）、队长ID、成员列表（可以将多个成员用分隔符拼接为一个字段，也可用关联表设计，个人推荐关联表设计更规范）、报名时间、审核状态。毕设场景里用团队表+团队成员关联表的方式更能在答辩时体现设计功底。

作品表（work）保存报名ID、作品名称、作品描述、文件存储路径、上传时间、版本号。版本号这个字段很容易被忽略，但实际考虑到学生可能会多次上传修改作品，加上版本号就能记录每一次提交，评审只看最新版。

评分表（score）记录评委ID、报名ID、作品ID、作品得分、作品评语、评分时间。同一件参赛作品在多人评分模式下会出现多条记录，成绩汇总时按赛事和报名进行聚合。

其他辅助表包括赛事评委关联表、公告表、操作日志表。操作日志表是加分项，它能记录谁在什么时间发布/修改了赛事内容，用于审计追溯，答辩时讲出来是亮点。

3.4 状态流转设计：让流程不乱的关键

赛事从创建到结束，状态是单向流转的：草稿→报名中→评审中→已结束，不允许跳变。创建赛事后必须手动发布，避免不小心把没准备好的赛事公开给学生；报名截止后系统不允许学生再报名，但此时管理员还能将状态切换到评审中；等到所有评分都完成且成绩发布，状态才进入已结束。

这套状态机的好处是，代码里所有涉及“现在能不能做某件事”的判断，只依靠赛事的当前状态，接口逻辑变得非常简单。比如“学生是否可以报名”的Service方法里，第一行就是判断赛事状态是否为“报名中”，如果不是，直接抛异常提示“当前赛事不在报名时间范围内”，整个流程的健壮性因此提高了很多。

4. 核心模块实现与关键代码解析

4.1 后端工程结构搭建步骤

项目的Maven骨架我建议按这个包结构组织，既有条理又符合论文架构图展示习惯：

com.example.contest ├── Controller │ ├── AdminController.java │ ├── ContestController.java │ ├── EnrollmentController.java │ └── ScoreController.java ├── Service │ ├── ContestService.java │ └── impl/ContestServiceImpl.java ├── Mapper │ ├── ContestMapper.java │ ├── EnrollmentMapper.java │ └── ScoreMapper.java ├── Entity │ ├── Contest.java │ ├── Enrollment.java │ ├── User.java │ └── Score.java ├── Common │ ├── Result.java │ ├── AuthInterceptor.java │ └── FileUtils.java

Controller层只负责参数接收与结果返回，Service层写具体业务逻辑。以报名功能为例，Service层必须有校验步骤：查赛事是否存在、判断赛事状态、判断报名截止时间、查当前用户是否已报名、判断团队人数上限。很多人图省事把这些放到Controller里写，代码跑起来没问题，但答辩追问“为什么要分Service层”的时候会露怯。

4.2 文件上传与存储方案的设计

科技竞赛系统的核心资源是学生上传的作品，文件上传模块最容易出问题，必须重点讲。SpringBoot接收文件上传的能力来自SpringMVC内置的MultipartResolver，前端把文件通过multipart/form-data表单POST到接口，后端用MultipartFile类型接收。

存储策略不要存数据库BLOB字段，而是把文件写到服务器磁盘一个固定目录下，数据库只记录/upload/works/2025/xxx.zip这样的相对路径。这样做的好处是数据库体积小、备份快、读取文件直接用静态资源映射即可，性能和扩展性都更好。文件命名必须重新生成，千万不要用学生原始文件名，否则两个人都传同一个作业.zip就会互相覆盖。我在项目里统一按赛事ID_报名ID_时间戳_原始文件名.zip规则命名，既能唯一区分又方便追溯。

上传接口核心代码如下，transferTo这个方法指定了落盘路径，路径不存在时先通过File.mkdirs()创建目录：

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file, @RequestParam("enrollmentId") Long enrollmentId) { if (file.isEmpty()) { return Result.error("上传文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); if (!".zip".equalsIgnoreCase(ext) && !".rar".equalsIgnoreCase(ext)) { return Result.error("仅支持zip或rar格式的压缩包"); } if (file.getSize() > 50 * 1024 * 1024) { return Result.error("文件大小不能超过50MB"); } String fileName = enrollmentId + "_" + System.currentTimeMillis() + ext; String dirPath = uploadDir + "/works/" + LocalDate.now().toString(); File dir = new File(dirPath); if (!dir.exists()) { dir.mkdirs(); } try { file.transferTo(new File(dirPath + "/" + fileName)); workService.saveWork(enrollmentId, "作品名称", dirPath + "/" + fileName); } catch (IOException e) { log.error("文件保存失败", e); return Result.error("文件上传失败，请重试"); } return Result.success("上传成功"); }

注意：如果你在本地Windows环境测试上传功能一切正常，但打包部署到Linux服务器后上传失败，八成是application.yml里没有显式配置上传目录的绝对路径，默认使用相对路径解析错了位置。运维部署时统一用配置项强制指定绝对路径。

4.3 成绩计算与排名汇总的实现细节

成绩模块要支持两种计分模式，我用一个简单的策略分支来处理。单人评委模式：每个作品的最终得分就是评委给出的原始分数。多人评委平均分模式：先按enrollment_id分组查询所有评分记录，再对有效评分求平均值。

排名汇总的SQL用MyBatis-Plus的QueryWrapper不好写复杂聚合，所以我直接用自定义SQL，在Mapper接口对应方法上加@Select注解：

@Select("SELECT enrollment_id, AVG(score) AS avg_score " + "FROM score WHERE contest_id = #{contestId} " + "GROUP BY enrollment_id ORDER BY avg_score DESC") List<ScoreVO> getAvgScoresByContest(@Param("contestId") Long contestId);

查出来之后在Service层把名次字段rank按顺序填充。这里有一个业务规则要注意：如果赛事设置了奖项名额，成绩发布之后只给前N名标记“获奖”，其余显示为“未获奖”。排序和截断逻辑都在Service层，而不是SQL里，答辩时可以顺便解释“业务规则与数据查询分离”的设计思路。

4.4 前端页面与后端接口的对接方式

前端技术选型有两条路线，我用加粗标注差异，你按自己的前端基础来选。

第一种是服务端模板渲染：SpringBoot集成Thymeleaf，页面放在templates目录下，后端Controller返回ModelAndView，把数据直接填充进HTML。这种方式适合后端为主、前端不太熟练的同学，开发效率高，写起来像是传统JSP时代的感觉。

第二种是前后端分离：后端提供JSON接口，前端用Vue+Element UI单独构建，前端工程通过Axios调用后端的RESTful API。这种方式更贴近企业实际开发，答辩时也更拿得出手，但工作量会多出不少，开发链路长，前后端联调阶段的跨域问题也逃不掉。

如果选了前后端分离，后端要做全局跨域配置。在配置类里写一个CorsFilter的Bean，或者直接在Controller类上加@CrossOrigin注解，指定允许的前端地址。我用的是后者，简单直接，一个注解解决开发环境下的联调跨域问题。

@CrossOrigin(origins = "http://localhost:8081") @RestController @RequestMapping("/api/contest") public class ContestController { }

上线部署阶段再单独配Nginx反向代理，让前后端同域访问，避免线上跨域。开发与生产环境的上联方式不一样，你在毕设说明文档里要把这套差异写清楚，老师看完会觉得你理解得很深入。

5. 部署、调试与毕设配套文档的准备

5.1 从零到一：完整启动流程实录

我先给出一套我在新电脑上从克隆代码到跑起来的完整过程记录，照着做基本不会卡壳。

第一步，安装基础软件：JDK8（配置JAVA_HOME和PATH环境变量）、Maven 3.8、MySQL 8.0、开发工具IDEA。第二步，在MySQL中创建数据库contest_db，字符集选utf8mb4，然后导入项目自带的contest_db.sql初始化脚本，脚本里包含建表语句和初始管理员账号，这一步不是可选项，我见过太多次因为不导入脚本导致登录报“数据库找不到表”的案例。第三步，修改application.yml里的数据库连接地址、用户名密码，确认这些配置和本地环境一致。第四步，在IDEA中打开项目，等待Maven自动下载依赖，如果下载慢就换阿里云镜像仓库。第五步，运行主类ContestApplication的main方法。第六步，浏览器访问http://localhost:8080，用初始化脚本里的管理员账号登录，能进入后台管理页即说明系统启动成功。

有一个非常常见的问题是Maven依赖下载完成后，启动报Error creating bean with name 'dataSource'，通常就三种原因：MySQL服务没启动，用户名密码写错，或者驱动依赖没引入。处理顺序就是先连数据库看是否能连通，再看配置是否正确，最后看Maven依赖树里有没有对应驱动包。

5.2 论文（LW）写作的章节结构与避坑指南

毕业设计论文和代码一样重要，很多同学代码写得很好，论文却一塌糊涂。论文的推荐章节目录如下：摘要；绪论（研究背景与意义、国内外现状、研究内容）；相关技术介绍（Java、SpringBoot、SSM、MySQL，每个技术概述之后要写“该技术在系统中的应用”）；系统分析（可行性分析、需求分析、用例图）；系统设计（总体架构图、功能模块设计、数据库ER图与表结构）；系统实现（核心功能界面截图加关键代码说明）；系统测试（测试用例表格、性能测试记录）；总结与展望；参考文献与致谢。

论文的常见雷区有三个。第一个，截图不够，老师看不到系统实际长什么样，而且每张图必须配套文字说明，不能光贴图不解释。第二个，技术介绍写得像背书，老师问“这个技术在你的系统里用了哪些特性”答不上来。写“相关技术”章节时，每个技术最后加一段“在本系统中的具体应用”，用自己代码里的真实例子说明。第三个，数据库表结构说明过于简略。每一张表都应该有一张字段表格，包含字段名、类型、含义注释。

5.3 调试文档与讲解演示的准备技巧

调试文档不是简单的“如何运行项目”，而是记录“如何复现这个项目、出了问题怎么办”的操作手册。标准结构分为：环境要求列表；部署步骤，一步一步从数据库导入到项目启动；核心配置说明，包括数据库连接、文件上传路径、Tomcat端口等；常见错误与解决方案表格。

答辩讲解的核心思路是“讲场景，不讲代码”。你拿一个具体场景开头，比如“一位学生登录系统，看到正在报名的赛事，点击报名并上传作品；随后评委登录，下载作品并打分；管理员审核后发布成绩，学生查到自己的排名”，把这条线完整演示一遍，再配合几张关键页面截图和ER图，基本就能把系统的价值讲明白。提前准备两三个“为什么这么设计”的问题，例如“为什么成绩不在评委打分后立刻显示”，回答因为成绩需要管理员审核以保证公平，这个细节能让答辩老师看到你的思考深度。

5.4 演示数据的准备策略

在没有真实用户数据的情况下演示系统，一定要提前造一批“活”数据，这是让系统演示效果好看起来的重要细节。只用一个管理员账号空跑系统，评委端看不到待评作品，学生端看不到可报赛事，整个系统就像一个空壳。

我的做法是造三组数据：一组学生账号，包含不同学院、不同学号的学生，报名状态覆盖已报名、未报名、已上传作品；一组评委账号，对应不同赛事；一组赛事，覆盖不同状态。再准备两个真实的小压缩包当作作品文件，批量造好评分记录。演示时就可以直接展示完整的数据流和结果页，比现场录入数据顺畅得多。

6. 常见问题排查与避坑经验实录

6.1 环境类问题：启动失败与依赖冲突

遇到过最多的情况是端口被占用。SpringBoot默认端口8080，如果本地已经有应用占用了8080，启动会直接报Port already in use。解决方案有三个：关掉占用进程、换电脑端口、在application.yml里改成其他端口号。我最推荐第三种，简便且不会影响其他项目。

Maven依赖冲突的典型表现是项目里同时引入了不同版本的坐标依赖，运行时报NoSuchMethodError或ClassNotFoundException。排查命令用mvn dependency:tree查看依赖树，逐个找出冲突。Starer依赖内部传递的版本和显式声明的版本不一致时，用排除依赖方式解决，例如：

<dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>4.1.2</version> <exclusions> <exclusion> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> </exclusion> </exclusions> </dependency>

6.2 数据库连接问题的常见报错与解决

MySQL 8.0连接时的经典报错是Public Key Retrieval is not allowed，解决方法是在数据库连接URL里加一个参数allowPublicKeyRetrieval=true。时区相关的报错是The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，这是MySQL默认时区与驱动不一致导致的，在URL的serverTimezone参数里设置成Asia/Shanghai即可。

每条连接参数都可以直接在初始化SQL脚本里配置，也可以写进application.yml，不必在Java代码里写死。我贴一段标准的配置作为参考：

spring: datasource: url: jdbc:mysql://localhost:3306/contest_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

6.3 业务逻辑层面的隐藏问题

第一个隐藏问题：过期的报名表审核状态不能恢复，推荐设定固定规则“报名截止后不可撤回”。这个逻辑看起来严苛，但能规避很多不可预期的管理纠纷，代码实现也简单。

第二个隐藏问题：成绩计算精度。平均分计算结果保留两位小数，四舍五入策略用RoundingMode.HALF_UP，不用默认的四舍五入，否则0.5分会被奇怪地截断。成绩汇总后先缓存一份快照，避免评委后续补打分引起排名波动。

第三个隐藏问题：前端页面的分页处理。MyBatis-Plus提供了Page对象，使用时分页参数必须显式传给构造方法。很多初学者写分页只调了selectPage却忘记设置current和size，导致结果要么不分页要么页码缺失。

6.4 答辩时被高频追问的问题清单

答辩前把下面几个问题准备充分，基本可以从容应对。第一个必问：“你的系统核心业务是什么，有哪些参与者？”你要用40秒讲清楚三类角色的闭环流程，这里讲顺了，整体印象分就稳了。第二个常问：“你的权限控制是怎么实现的？”把我的拦截器方案前因后果讲清楚，强调为什么不用Spring Security。第三个必问：“你遇到过的最大的坑是什么？”选一个真实的技术问题，比如跨域导致的登录失效或文件上传路径不一致，讲本质原因和解决过程。第四个加分问：“如果让你增加一个功能，你会加什么？”可以回答比赛数据可视化分析，具体到一个赛场各学院报名数量的柱状图，把图表技术方案也顺带提出来，老师一般都会满意于这种延伸思考。

7. 进阶优化与个人心得

7.1 数据分析与导出功能增强方向

基础PPT功能做完之后，如果想给项目增加亮点，推荐做数据分析和导出方向的功能增强：成绩排名前能看到评分明细占比；按学院统计报名人数并生成图表；Excel导出报名名单、成绩汇总表；新增通知公告的自动推送。这些优化每一项都可以作为论文里的创新点。

图表展示可以引入ECharts，用纯前端渲染，后端只提供统计数据接口。在/admin/statistics页面里用柱状图展示各学院报名人数，饼图展示各赛事获奖比例，页面直观又有说服力。

7.2 我在落地这套系统时踩过的几个坑

第一坑是写报名功能时只做了“报名成功”的通知，没考虑“拒绝报名”的通知。学生提交报名，管理员不通过，系统没有任何反馈，学生在页面上看到报名状态就是“待审核”，又不知道该怎么改。后来增加了“报审驳回原因”字段，管理员拒绝时填原因，学生端能收到通知。

第二坑是作品上传的版本编号问题。学生第一次传了作品，第二次想修改，如果直接把文件名中的时间戳覆盖掉，就无法追溯历史版本。后来改成同一报名记录下允许多个作品文件，但列表页只展示最新版本，评分按钮链接也只指向最新版本。这个设计在答辩时用来解释“数据可追溯性”非常加分。

第三坑是管理员忘记关闭报名入口导致超时报名。最初不考虑自动判断时间，后来改成报名Service里同时判断“赛事状态是否是报名中”和“当前时间是否在报名窗口内”两个条件，窗口自动收紧，不会有人过了截止时间还能报名成功。

这些坑都在调试文档里记录了吗？写文档时把解决方案写进“常见问题”章节，答辩老师如果问“遇到过什么棘手问题”，你直接引用文档里的记录就能讲得非常真实。

7.3 后续扩展思路与学习建议

这套系统做完以后，还能延伸出很多方向。比如加权平均分的规则优化，比如不同比赛类型使用不同评审模板，比如引入MinIO做分布式文件存储应对海量作品文件，比如对接学校统一身份认证实现一键登录，比如把部署迁移到服务器和Nginx完成上线。建议先把这个核心版本吃透，按需选择1-2个方向深化改造，效果会比盲目堆功能好很多。

如果是准备面试，把这个项目写到简历上之后，建议把三个点彻底吃透：SpringBoot的自动装配原理、SpringMVC的请求执行流程、MyBatis和MyBatis-Plus的底层差异。量不算大，但每一个都能体现SSM项目的真实功底，面试官顺着这些点往下问的时候，你也会有据可答。