Nicholas Qin我是去年拿这个题目过的答辩，整个过程踩了不少坑，也整理出一套比较完整的代码和文档框架。这篇博客不聊空泛的概念，直接把我做“基于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，几分钟就能对上号；写论文的时候画系统结构图和模块图也不用临时编，直接拿目录结构改一改就是一张好图。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计：从需求到表结构
2.1 核心表一：用户表与战队表
数据库设计是整个系统最值得花时间的地方。表结构设计得好，后端开发就是套模板；设计得不好，后面每写一个接口都要为了查数据写一堆奇怪的SQL，非常痛苦。我最终建了10张表，最核心的是用户表(user)、战队表(team)、赛事表(contest)、比赛表(contest_match)和报名表(registration)。
用户表不搞复杂的权限框架，只用一个role字段区分身份，0是普通用户，1是战队队长，2是管理员。之所以不引入Spring Security那套完整的RBAC权限模型，是因为毕设系统里角色固定、权限清晰，弄得太复杂反而让代码可读性下降。但这张表在密码字段上我做了MessageDigest的MD5加盐处理，而不是明文存储做演示。答辩时如果老师拉起数据库看到明文密码，很多老师会直接质疑安全问题。
战队表最关键的字段是captain_id，它指向用户表的主键，代表队长。这里我设计的是一个人只能创建一支战队，所以给captain_id加了唯一索引。战队表还需要存战队图标base64或者图片URL，这里我统一用一个image_url字段解决，不搞二进制大字段存储，前端拿到URL直接渲染图片即可。
2.2 核心表二：赛事、赛程与报名
赛事表的设计要特别提一下，因为这是整个系统的业务中心。我把赛事状态status设计为int类型，0表示草稿、1表示报名中、2表示比赛进行中、3表示已结束。为什么不用时间去实时计算赛事状态？因为在真实业务里，“报名中”和“已结束”不是单纯由当前时间和起止时间比较出来的，管理员可能提前截止报名，也可能因特殊情况临时暂停报名。状态字段必须由管理员手动控制，代码逻辑中只在创建赛事时根据当前时间和开始时间给出默认状态，后续变化全部通过管理员操作。
比赛表和赛事表是主从关系，一场赛事包含多场比赛，比赛表里用contest_id外键关联赛事，用round字段表示是小组赛还是淘汰赛，用match_time存比赛时间，用status字段表示比赛是否已经结束。报名表用于记录用户或战队报名的信息，它是赛事表和战队表的中间表，唯一索引的坑我在后面会专门讲。
这里给出最核心的几张表结构作为参考，方便你直接照着建表：
sql复制CREATE TABLE `user` (
`id` bigint NOT NULL AUTO_INCREMENT,
`username` varchar(50) NOT NULL COMMENT '用户名',
`password` varchar(100) NOT NULL COMMENT 'MD5加盐密码',
`nickname` varchar(50) DEFAULT NULL COMMENT '昵称',
`phone` varchar(20) DEFAULT NULL COMMENT '手机号',
`role` tinyint NOT NULL DEFAULT '0' COMMENT '角色：0用户 1队长 2管理员',
`avatar` varchar(255) DEFAULT NULL COMMENT '头像地址',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
sql复制CREATE TABLE `contest` (
`id` bigint NOT NULL AUTO_INCREMENT,
`title` varchar(100) NOT NULL COMMENT '赛事名称',
`game_type` varchar(30) DEFAULT NULL COMMENT '游戏项目，如英雄联盟',
`cover_url` varchar(255) DEFAULT NULL COMMENT '赛事封面',
`description` text COMMENT '赛事介绍',
`signup_start_time` datetime DEFAULT NULL COMMENT '报名开始时间',
`signup_end_time` datetime DEFAULT NULL COMMENT '报名截止时间',
`contest_start_time` datetime DEFAULT NULL COMMENT '比赛开始时间',
`contest_end_time` datetime DEFAULT NULL COMMENT '比赛结束时间',
`max_team_count` int DEFAULT NULL COMMENT '最大参赛队伍数',
`current_team_count` int NOT NULL DEFAULT '0' COMMENT '已报名队伍数',
`status` tinyint NOT NULL DEFAULT '0' COMMENT '赛事状态',
`create_by` bigint DEFAULT NULL COMMENT '创建人管理员ID',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='赛事表';
2.3 多表关联查询的SQL写法
系统中有几个非常关键的列表页需要多表查询。比如“赛事详情页”要显示当前已经报名的战队头像和战队名称，而registration表里只存了team_id，必须把registration和team两张表联查；再比如“赛程管理列表”要显示比赛双方的战队名、对应的赛事名称，这就得把contest_match、team、contest三张表一起关联。
我用MyBatis Plus自带的CRUD方法处理单表操作，遇到这些多表查询就单独手写XML Mapper。例如查询某场赛事的报名战队列表SQL是：select t.id, t.team_name, t.logo_url from registration r inner join team t on r.team_id = t.id where r.contest_id = ? and r.status = 1 order by r.create_time。这个SQL看起来简单，但它决定了后续页面上的报名列表展示、报名审核通过与否、导出参赛名单几个功能都是复用它，所以一定要提前调试好。
3. 后端核心功能实现细节
3.1 统一返回结果与全局异常处理
后端接口和前端交互时不能一会儿返回一个格式一会儿返回另一个格式，否则前端写起来会非常崩溃。我定义了一个通用Result对象，结构只有四个字段：code、message、data，比如code=200表示成功，code=401表示没有登录，code=500表示后端异常。前端拿到响应之后先判断code，不是200就直接弹错误消息，不管具体接口是什么，处理逻辑完全一致。
全局异常处理用SpringBoot的@RestControllerAdvice注解实现，在类里分别写处理业务异常、参数校验异常和兜底Exception的方法。比如系统里我自定义了一个BusinessException，当赛事状态不对、报名人数已满、用户没有权限这些情况出现时，业务层只要throw new BusinessException("该赛事报名已截止")，就会被全局异常处理器捕获并转成code=500，message=该赛事报名已截止的统一格式返回给前端。这种做法让代码里少了几百个try-catch，可读性高很多。
3.2 基于JWT的登录鉴权设计
系统所有接口除了登录、注册和赛事浏览外都不允许匿名访问，我用JWT实现这个需求。流程是：用户提交用户名密码，后端校验通过用用户ID和角色生成一个token字符串返回给前端；前端把token存在localStorage里，每次请求都在请求头加上Authorization字段；后端写一个拦截器，拦截所有非放行的请求，解析请求头中的token，解析失败直接返回401，解析成功就把用户信息放到ThreadLocal里供后续业务代码使用。
技术选型上我没直接用Spring Security，因为它的过滤器链体系比较复杂，对毕设来说学习成本太高。我是用HandlerInterceptor + JWT实现了一套轻量鉴权，核心逻辑不到一百行，自己完全能讲清楚每个环节在做什么，这一点在答辩时非常重要。老师最常问的问题之一就是“你这个登录状态是怎么保持的”，如果代码是你自己写的，就可以从token生成、存储、校验、过期时间四个方面去回答，很有底气。
JWT工具有一个核心方法是生成和解析token：
java复制public String generateToken(Long userId, Integer role) {
Map<String, Object> claims = new HashMap<>();
claims.put("userId", userId);
claims.put("role", role);
String token = Jwts.builder()
.setClaims(claims)
.setSubject(String.valueOf(userId))
.setExpiration(new Date(System.currentTimeMillis() + 1000L * 60 * 60 * 24 * 7))
.signWith(SignatureAlgorithm.HS256, SECRET_KEY)
.compact();
return token;
}
登录接口还有一个比较容易踩的坑：任何在线文档、演示页面都要能访问，但它们不属于匿名接口，必须显式地在配置类里放行。我用的API文档是springdoc-openapi也就是Swagger 3的升级版，它在SpringBoot项目里主要通过springdoc配置，Swagger页面相关接口路径是/v3/api-docs和/swagger-ui.html，要在拦截器配置里把这两个路径放行，不然项目一启动测试接口时全部报401，排查大半天才发现是拦截器把它们拦住了而不是接口本身有问题。
3.3 赛事发布与分页查询实现
赛事发布的后端实现是典型的增删改查加业务校验。创建赛事时，管理员传入赛事标题、游戏项目、报名起止时间等数据，后端要做三件事：第一是参数的非空校验，比如赛事标题不能为空、报名截止时间不能早于当前时间；第二是设置初始status为0草稿状态；第三是把创建人的管理员ID写入create_by字段，方便以后追溯数据。这三步做完再调用MyBatis Plus的insert方法。
管理员创建赛事后，前端赛事列表页能马上看到这条数据吗？我的设计是列表页根据角色区分：普通管理员能看到全部状态的赛事，以便进行编辑管理；普通用户只能看到状态为报名中和进行中的赛事。查询是分页进行的，前端每次请求传pageNum、pageSize两个参数，后端用MyBatis Plus的分页插件PageHelper或自带PaginationInterceptor实现物理分页。这里尽量别用内存分页，如果数据量大到几千条，后端一次性返回所有数据前端再自己切片，响应时间会非常难看。
3.4 报名功能与防重复提交
报名是系统中比较有业务难点的一个功能，值得重点展开。一个普通用户在赛事详情页点击“报名”按钮，实际上是把当前用户关联的战队ID和赛事ID插入到registration表。这里我遇到一个真实的坑：一个战队同一场赛事只能报名一次，但如果用户手速快连续点两次报名按钮，两次请求先后到达后端，第一请求还没完成插入，第二请求又来了，结果就是生成两条报名记录。
解决防重有两个办法，一个是在代码里先查再插，另一个是在表结构上加唯一约束，可以两个同时用。我的做法是在registration表给(contest_id, team_id)建联合唯一索引作为兜底，同时在插入之前先做一次状态判断。因为是事务方法，插入时如果触发了唯一索引冲突，直接捕获DuplicateKeyException抛出一个友好提示“您的战队已经报名过该赛事”，不要让它原样把500错误抛给前端。这个细节在论文中写到“系统安全性”章节时非常好用，在答辩时也是加分项。
报名业务里还有两个状态判断：赛事是否在报名时间段内、当前报名队伍数是否已经达到max_team_count上限。前一个判断用当前时间和数据库里的signup_end_time做比较即可，后一个判断则要利用上面提到的current_team_count字段。每次报名成功，我给这个字段加1，如果判断加1之后大于max_team_count，则说明赛事名额已满，直接报业务异常。这样虽然存在极端并发下计数不准的问题，但对毕设系统来说已经够用，评委不会拿高并发场景来苛求你。
3.5 赛程编排与积分排名计算
比赛开始前，管理员要对参赛队伍进行分组和赛程安排。这部分我在页面上提供一个简单的赛程管理表，管理员为每场比赛选择比赛双方战队、填写比赛时间、选择比赛场次。后台自动验证两个战队不能出现在同一时间段的不同比赛中，避免比赛时间冲突。考虑到电竞比赛的淘汰赛特性，赛程编排的核心是一个小组循环赛或单败淘汰赛的数据结构问题，但系统实现时我只做数据录入层面的辅助，不自动生成对阵树，将自动排赛作为后续扩展点写在论文里。
录入比赛结果时，管理员把比赛双方的比分、获胜方提交到后端，后端更新比赛表状态并计算胜者积分，同时给战队表中对应战队加上相应的胜场数和积分。积分规则不同游戏项目差别很大，但我采用的是通用竞技规则：胜一场积3分、负一场积0分，如果是小组赛还有平局则双方各积1分，这样排行榜的计算逻辑就比较统一。排行榜查询时直接对战队表按积分降序排列，然后取出前N名即可，不涉及复杂的临时计算。
4. 前端项目实现与前后端联调
4.1 Vue 3 项目创建与接口请求封装
前端我使用的是Vite创建Vue3项目，npm create vite@latest frontend -- --template vue，然后安装Element Plus、Axios、Vue Router、Pinia这几个核心依赖。项目创建好以后首先要做的是在src目录下建一个utils/request.js文件，对Axios进行二次封装。
封装Axios不是多此一举，它解决的核心痛点是统一处理token和统一处理错误。在request.js的请求拦截器里，每次请求前从localStorage里取出token放到请求头的Authorization中，这样业务代码就不用每个接口手动传token。响应拦截器里根据Result的code做统一判断，code是200就直接返回data交给页面使用，code是401则清除本地的用户信息并跳转回登录页，其他错误码则统一通过Element Plus的Message组件弹出错误提示。
javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'
const request = axios.create({
baseURL: '/api',
timeout: 10000
})
request.interceptors.request.use(config => {
const token = localStorage.getItem('token')
if (token) {
config.headers.Authorization = token
}
return config
})
request.interceptors.response.use(
response => {
const res = response.data
if (res.code !== 200) {
ElMessage.error(res.message || '请求失败')
if (res.code === 401) {
localStorage.removeItem('token')
window.location.href = '/login'
}
return Promise.reject(new Error(res.message))
}
return res.data
},
error => {
ElMessage.error(error.message || '网络异常')
return Promise.reject(error)
}
)
export default request
4.2 开发环境跨域问题的处理
前后端分离开发时遇到最多的就是跨域问题。浏览器发现前端地址是localhost:5173，后端接口是localhost:8080，端口不同，就会触发同源策略拦截。解决开发环境跨域最优雅的方式不是在SpringBoot后端写CorsFilter，而是在Vite配置里做代理转发。
我的vite.config.js配置如下：
javascript复制export default defineConfig({
plugins: [vue()],
server: {
port: 5173,
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
})
这样配置以后，前端请求/api/user/login，Vite开发服务器会自动把请求转发到localhost:8080/api/user/login，对浏览器来说请求是同源的，不存在跨域问题。要注意的是，后端接口路径本身也要有/api前缀，如果后端接口没有这个前缀，需要把proxy中的路径改写成带rewrite或者在后端统一加context-path：server.servlet.context-path=/api。我在部署上线后用Nginx也一样做了一层把前端请求转发到后端Java服务的代理，这样生产环境也没有跨域。即使后端加了CORS配置，开发环境和生产环境的跨域处理逻辑不同，很多同学只在后端配了跨域导致开发环境没问题，一部署就抓瞎，这里直接说清楚：开发用前端代理，上线用Nginx代理，后端不需要额外开启跨域。
4.3 登录态管理与路由守卫
前端管理登录状态的核心是两样东西：localStorage里的token和Vue Router的路由守卫。当用户登录成功后，我把token和用户基本信息存起来，跳转到首页。路由守卫则是在每次路由跳转前判断当前页面是否需要登录权限，如果用户没登录就想访问后台管理页面，直接强制跳转到登录页。
后端管理员的按钮权限没有做成动态路由菜单，因为角色的权限差异用前端v-if已经能覆盖。比如后台管理页面里的“赛事审核”按钮，只有当前登录用户role为2时才会显示，普通用户访问后台管理页时路由守卫会立刻拦截。虽然这种控制在前端有被绕过的风险，但真正核心的权限控制是放在后端每个管理接口的拦截器里的，前端按钮控制只为了用户体验。
4.4 赛事详情页与报名交互
赛事详情页是用户端最复杂的页面之一，从上到下要展示赛事封面、赛事介绍、报名时间和当前进度、参赛战队列表。页面在mounted生命周期里同时请求两个接口：一个是赛事详情接口获取基本信息，一个是报名战队列表接口获取参赛队伍头像墙。用户的报名按钮状态根据赛事状态动态变化，如果赛事还未开始报名或者已经截止，按钮变成灰置不可点击状态。管理员后台修改了赛事状态之后，普通用户只需刷新页面就能看到最新的报名状态，这个联动机制完全依赖后端返回的status字段，前端只负责根据状态渲染不同的展示效果，职责划分非常清晰。
5. 项目部署与常见问题排查
5.1 本地打包与服务器部署过程
毕设最终要能展示，部署是绕不开的环节。虽然很多学校答辩只是让自己电脑上演示，但提前部署在云服务器上会更有说服力，而且能避免答辩当天电脑突然出问题的手忙脚乱。打包步骤分为后端和前端两部分，后端是执行mvn clean package命令，生成一个可执行jar包；前端是执行npm run build，生成dist静态文件。
后端部署我用的是两种方式，一种最简单的是直接在服务器上装JDK和MySQL，然后java -jar运行；另一种是用Docker把SpringBoot项目打成镜像再运行容器。Docker部署虽然多了一些步骤，但好处是换一台服务器重新部署时不用再装一遍环境，docker run命令一执行，环境就是完全一致的。有一个值得注意的坑：SpringBoot应用在Docker容器里连接宿主机MySQL时，数据库地址不能写localhost，需要写成host.docker.internal（Docker Desktop环境）或者宿主机在容器网络中的IP，否则报Communications link failure。
前端则是把dist目录里的文件放到Nginx的html目录下，然后在Nginx配置里写一个location块把/api请求反向代理到后端的8080端口。这里强调一点：不要试图用SpringBoot把前端静态文件打成jar里的静态资源一起跑，虽然技术上可行，但会让前后端分离的架构失去意义，论文里画架构图时也不好解释。
5.2 报错排查速查表
整个项目做下来遇到最多的问题基本集中在环境配置和数据访问层，这里整理一个速查表，遇到同类问题可以直接对着排查：
| 错误现象 | 常见原因 | 处理方法 |
|---|---|---|
| java.sql.SQLNonTransientConnectionException | MySQL地址写错或服务没启动 | 检查localhost:3306能否连通，密码是否正确 |
| Access denied for user | 数据库账号权限不对 | 用root账号授予该账号对应数据库的权限 |
| Cause: java.sql.SQLSyntaxErrorException | XML里SQL写错或表名与关键字冲突 | 检查表名是否用了user等保留字，尽量加反引号 |
| 前端请求接口404 | 前端代理路径和后端context-path不一致 | 统一所有请求路径，保证前端baseURL和后端接口一致 |
| JWT token解析报错 | 密钥不一致或token被截断 | 检查前后端请求头Authorization字段完整格式 |
| 图片上传后无法访问 | 上传路径和静态资源映射不匹配 | 后端配置资源映射目录，前端图片URL指向映射路径 |
5.3 SpringBoot自动装配原理在答辩中的表现
很多同学在答辩时最怕被问原理，其实SpringBoot的原理准备一个深度的回答就够了：自动装配原理。我做了几百行总结背诵：SpringBoot启动类上的@SpringBootApplication组合注解由@EnableAutoConfiguration触发自动装配，内部通过@Import导入了AutoConfigurationImportSelector，这个类会去读取META-INF/spring.factories（SpringBoot 2.7及以前）或者META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里配置的自动配置类，然后通过@ConditionalOnClass、@ConditionalOnMissingBean等条件注解判断当前类路径下是否有对应的依赖类，有才执行自动配置并装配相应的Bean。比如pom里引入spring-boot-starter-web后，DispatcherServlet和内置Tomcat就会通过这个机制被自动配置出来。
老师问“为什么SpringBoot能自动配置”的时候，你回答到这个层面已经能说明你是理解框架而不仅仅会用框架了。如果老师再追问MyBatis Plus怎么和SpringBoot整合的，就讲MyBatis Plus提供的MybatisPlusAutoConfiguration自动配置类如何读取数据源并创建SqlSessionFactory，这个思路和SpringBoot自动配置一脉相承。
5.4 说明文档与论文写作的框架安排
毕设项目一般要求提供说明文档和LW，这里我给一个可以复用的论文大纲。第一章绪论写研究背景和意义，引入电竞行业近年来的发展态势；第二章相关技术介绍写Java、SpringBoot、Vue、MySQL；第三章需求分析画用例图和数据流图，分角色梳理功能需求和非功能需求；第四章系统设计包含总体架构图、功能模块图、数据库E-R图以及核心表结构说明；第五章系统实现是重点，每一小节对应一个模块的页面截图加核心代码块加实现说明，注意展示页面效果图的截图尺寸都要调整好；第六章系统测试用黑盒测试写测试用例表，再写测试结果分析；最后结论和展望。
论文里最容易扣分的是第二、三章和代码实现脱节，很多同学从百度文库复制一堆介绍性内容，老师一问细节什么都答不上来。我写论文的原则是所有写进论文的功能都有运行截图支撑，所有贴出来的代码都经过实际运行验证，宁可少贴代码也不能贴错。
6. 毕设调试过程中的几个血泪经验
调用后端接口的时候，如果遇到HTTP 500但控制台没有打印详细错误日志，大概率是MyBatis的Mapper XML文件没编译到target目录下。在pom.xml的build节点一定要加resources配置，把src/main/java目录下的xml文件一起打包，否则项目启动后Mapper接口一直报binding exception。这个问题我在开发中遇到过几次，每次都以为是自己SQL写错，折腾了很长时间才发现是资源文件没有被打包的问题。
Redis缓存这块，如果只是为了给赛事列表加缓存，在毕设阶段完全可以把Redis省掉，直接用本地内存Map加定时过期都比引入Redis省事。但是如果论文里写到了Redis，那你必须真正在项目里用了它。我最终在排行榜查询里加了一层Redis缓存，key是rank:contest:{contestId}，过期时间三十分钟，只有后台录完比赛成绩后主动删除这个缓存键，保证排行榜是新鲜的。在答辩时，这个逻辑可以清楚地说出缓存何时更新、何时失效，不是套话。
前端页面在开发过程中经常遇到这样一个体验问题：Vue 3里用reactive定义数组，然后用接口返回数据直接赋值，页面并没有更新。这是因为reactive对数组的响应式处理有限制，我用ref来定义数组类型的数据，取值时用xxx.value，赋值整体替换，就不会出现数据变了页面不刷新的问题。Element Plus的表格组件在重新请求数据后要记得重新给表格的数据源赋值，否则点击分页后表格内容不更新，这实际上也是响应式数据类型选错导致的。
论文查重也是一个要提前准备的事情。技术描述部分的重复率可以用自己的语言重新组织段落来降低，比如介绍SpringBoot时不要照抄官方文档的“Spring Boot makes it easy to create stand-alone...”标准翻译，而是写“SpringBoot项目可以通过内嵌Tomcat直接运行打包后的jar包，部署时不需要在服务器单独安装Tomcat，这给项目上线带来了很大方便”，用大白话加工程视角描述，既讲清楚了原理又降低了查重率。
整个项目从确定题目到最终论文提交，我前前后后用了大约五周时间，其中真正用来写代码的时间大约是两周半，选题和表结构设计大概三天，剩下的时间全花在写论文、画图和准备答辩PPT上。如果让我重新做一次，我会把数据库设计再多花点时间，确保每一个字段都有它存在的意义，因为后期很多调整的根源都可以追溯到数据库表结构设计不到位。如果你也想快速把毕设做出来又不想踩太多坑，建议第一版就把用户、赛事、报名、比赛这四条主线的数据打通，先跑通一个完整流程，再去补充各种细节和美化，流程通了你心里就有底了。