SpringBoot电竞比赛管理系统毕设实战：从表结构设计到答辩全流程

我是去年拿这个题目过的答辩，整个过程踩了不少坑，也整理出一套比较完整的代码和文档框架。这篇博客不聊空泛的概念，直接把我做“基于SpringBoot的电竞比赛管理系统”时的核心设计、表结构、关键接口、前端联调、部署和论文写作思路全部过一遍，希望能给正在选这个方向做毕设的同学一点可以抄作业的参考。

这个系统的定位其实非常明确：给电竞赛事主办方提供一个在线管理平台，覆盖从官方发布赛事、用户在网页端查看赛事并报名、管理员审核报名信息、安排赛程、录入比赛成绩到自动生成排行榜的全流程。只要你去把市面上的电竞类App或者网吧赛事的后台流程捋一遍，会发现它们本质上都在做这几件事。

技术选型上我采用的是Java + SpringBoot + Vue 3 + MyBatis Plus + MySQL 8，前后端完全分离。其中SpringBoot负责所有业务接口、登录鉴权和数据持久化，前端是Vue 3搭配Element Plus做管理界面和用户端页面。这套组合是很多毕业设计的标准搭配，原因很实际：网上资料足够多、出错了搜索一下就能解决、答辩时老师只要看到SpringBoot、JWT、MyBatis Plus这几个关键词就会认为你确实在做工程开发，而不是只写了几个静态页面应付了事。

1. 项目整体设计与技术选型

1.1 业务场景与功能边界

先别急着写代码，第一件事是把系统的用户角色和功能边界理清楚。电竞比赛管理系统我最终把它分成三类角色：普通用户、战队队长、系统管理员。普通用户能做的是注册登录、浏览赛事专题页、查看赛程赛果、搜索战队和选手数据；战队队长在普通用户的基础上多了创建战队、报名参赛、维护战队成员名单的权限；系统管理员则负责最高层的数据维护，包括发布赛事公告、管理注册用户、审核比赛报名、编排比赛赛程、录入赛后比分、管理全部战队信息。

有些同学做这个题目容易陷入一个误区，就是把功能设计得特别大，比如加上直播模块、弹幕模块、虚拟商品购买模块，最后数据库表建了几十张，真正实现的时候发现做不完，论文里只能写“系统预留了接口”。我在正式动工前定了一条原则：所有功能必须能在两个周内完成编码，两个周内无法完成的一律不做，改成在论文里把它放到“系统展望”部分展开。最终系统保留的核心功能是赛事管理、战队管理、报名审核、赛程管理、成绩录入和排行榜计算，这就已经足够写出一篇完整且有细节的毕业论文。

1.2 技术栈选型逻辑

为什么选SpringBoot而不是传统的SSH或者SSM框架？我当时的判断很简单：SpringBoot的自动装配机制把大量繁琐的XML配置收编成了一行注解，让我把精力放在业务代码上，而不是没完没了地折腾配置文件。比如数据源配置，SSM要写单独的jdbc.properties、spring-dao.xml、spring-service.xml、spring-mvc.xml四个配置文件，SpringBoot只需要在application.yml里写spring.datasource.url、username、password三个属性，依赖引入connection-pool的starter之后就能直接用。

这里顺便说一个很多初学者会忽略的细节：SpringBoot版本选择真的有讲究。我一开始图新鲜选了当时较新的Spring Boot 3.0，结果发现它要求JDK 17+，而我电脑里装的是JDK 8，而且很多网上的教程、MyBatis Plus旧版本写法在SpringBoot 3环境都不兼容，最后老老实实换成了Spring Boot 2.7.6 + JDK 8这一套组合。如果你不是对新技术特别熟，做毕设千万别追高版本，稳定好用是第一位的。SpringBoot版本太高引起的启动失败、依赖冲突问题，排查起来比写业务代码痛苦得多。

后端使用MyBatis Plus而不是原生MyBatis也是有实际考虑的。毕设里大部分常用接口都是单表CRUD，MyBatis Plus自带的BaseMapper能直接提供insert、deleteById、selectPage等方法，尤其是分页查询，不用再去XML里手写limit语句。当然涉及多表关联的时候我还是保留了自己手写的XML Mapper，两种方式在同一项目里是可以共存的，这也是我们实际开发里常见的状态。

前端技术栈选择Vue 3 + Element Plus + Vite。说实话如果只求稳妥，选Vue 2 + Element UI会更保险，因为配套教程最多。但我考虑到毕设答辩时老师肯定会问前端脚手架问题，Vue 3是趋势，选择它至少能让老师觉得你的知识没有停留在三年前。Vite作为构建工具比Webpack快很多，npm run dev启动项目几乎是秒开，这对开发调试过程中的效率提升非常大。

1.3 目录结构与工程规划

项目整体拆成backend和frontend两个大目录，后台代码严格按照Spring Boot习惯分包：config放配置类，controller放接口入口，service以及impl放业务逻辑，mapper放数据访问层接口和XML文件，entity放数据库实体，dto放接口参数对象，vo放返回给前端展示的对象，common里放全局异常处理、统一返回结果类和工具类。

前端按Vue 3常见结构分成src/api、src/router、src/store、src/views、src/components五个核心目录。api目录下的文件按模块划分，比如contest.js、user.js、team.js，每个文件导出一个封装好的请求函数。views里则按照页面来划分，比如登录页、赛事列表页、赛事详情页、后台管理页。这样做的最大好处是：开发时定位问题非常快，前端报错一个接口404，你顺着文件名去找controller，几分钟就能对上号；写论文的时候画系统结构图和模块图也不用临时编，直接拿目录结构改一改就是一张好图。

2. 数据库设计：从需求到表结构

2.1 核心表一：用户表与战队表

数据库设计是整个系统最值得花时间的地方。表结构设计得好，后端开发就是套模板；设计得不好，后面每写一个接口都要为了查数据写一堆奇怪的SQL，非常痛苦。我最终建了10张表，最核心的是用户表(user)、战队表(team)、赛事表(contest)、比赛表(contest_match)和报名表(registration)。

用户表不搞复杂的权限框架，只用一个role字段区分身份，0是普通用户，1是战队队长，2是管理员。之所以不引入Spring Security那套完整的RBAC权限模型，是因为毕设系统里角色固定、权限清晰，弄得太复杂反而让代码可读性下降。但这张表在密码字段上我做了MessageDigest的MD5加盐处理，而不是明文存储做演示。答辩时如果老师拉起数据库看到明文密码，很多老师会直接质疑安全问题。

战队表最关键的字段是captain_id，它指向用户表的主键，代表队长。这里我设计的是一个人只能创建一支战队，所以给captain_i