爬一手好线杆马上又到毕业季了，每年这个时候我都会收到不少私信，问的基本是同一类问题：“博主，我想做一个某某管理系统，SpringBoot加Vue怎么搭？”今年问得最集中的就是“基于SpringBoot+Vue的体育馆预定系统”。说实话，这个选题非常聪明，业务边界清晰，不复杂但五脏俱全，而且预定系统里最核心的“时间冲突判断”和“并发控制”这两个点，放到毕业论文里可以写，放到面试里也可以聊，一鱼两吃。今天我就把整个项目的设计思路、数据库怎么建、前后端怎么配合、论文和答辩PPT怎么准备，以及搭建视频怎么录，完整拆开讲一遍。
这篇文章适合谁看？打算做这个题目的应届毕业生、想拿一个完整项目练手的前端或后端新人、甚至想快速给单位内部做个球场预订工具的运维或研发同学。内容不会只贴一堆代码，而是把每一步“为什么这么设计”讲清楚，让你既能做出来，也能讲明白。
1. 项目拆解与技术选型：为什么这个题目值得做
1.1 业务需求与角色分析
体育馆预定系统，本质上是“资源预约类系统”的一个典型代表。它和会议室预定、自习室占座、机房机时预约是同一个业务模型：有一批物理资源，用户要在有限的时间段内争抢这些资源，系统要保证同一时间同一资源不能被两个人同时占用。
从角色上看，系统一般分为两类用户：
- 普通用户：注册登录后浏览场地，选择日期和时段，提交预订，支付或等待确认，查看自己的预定记录，可以取消尚未开始的预约。
- 管理员：维护场地信息、设置场地开放时间和价格、审核预约或查看订单、处理用户反馈、查看系统统计信息。
这个角色划分决定了系统的权限控制必须存在，而且不能只是前端隐藏按钮，后端接口也要做权限校验。大多数毕业设计在这块做得比较松，但如果你想拿高分，前后端都做权限控制是一个明显的加分项。
从业务流来看，核心链路就是“查场地—选时间—提交预约—状态流转—使用完成”。听起来简单，但真正实现的时候，时间冲突判断、并发控制、状态自动过期、支付回调这些环节，每个都能写一大段论文内容。
1.2 前后端分离选型：不只为时髦，更为省事
很多同学在开题时会纠结：用传统的JSP+Servlet行不行？用Thymeleaf服务端渲染行不行？答案是可以，但效果远不如SpringBoot+Vue的前后端分离方案。
原因很实际。SpringBoot的核心价值在于“约定大于配置”，内嵌Tomcat，不用再折腾复杂的XML配置，一个@SpringBootApplication就能跑起来。而Vue作为前端框架，组件化开发让页面逻辑清晰，路由、状态管理、UI组件库都有很成熟的生态。两者结合，天然就能做出一个代码结构清爽、功能模块分明的项目，这在写论文时非常有利——需求分析、系统设计、系统实现，每一章都很好展开。
另外，前后端分离还有一个隐藏优势：可以独立调试。前端Mock数据开发，后端用Postman测接口，谁都不等谁。到联调阶段再通过代理或跨域配置把两边接起来。这种方式放到工作后的真实开发中也是主流模式，做一遍这个项目，相当于提前熟悉了一遍企业级协作流程。
1.3 技术栈全景：版本选择第一重要
这个项目涉及的技术栈说多不多，说少也不少，但每一个选型都必须注意版本匹配，这是踩坑最多的环节。
后端建议使用：
- JDK 1.8（配合SpringBoot 2.x）或者JDK 17（配合SpringBoot 3.x），千万不要SpringBoot 3.x配JDK 8，编译都过不了。
- Maven 3.6以上作为依赖管理工具。
- MySQL 5.7或8.0，数据库连接池用Druid或HikariCP。
- MyBatis-Plus或Spring Data JPA做持久层，前者更贴近国内企业实际。
- Redis用于缓存场地信息和分布式锁（加分项，但按需引入）。
前端建议使用：
- Vue 2 + ElementUI，或者Vue 3 + Element Plus。新手我更推荐Vue 3版本，毕竟再学一遍Vue 2的语法意义不大。
- Vue Router做路由，Axios做HTTP请求。
- ECharts可选，用来做后台的统计图表，论文配图会很漂亮。
版本这块一定要在项目启动前就锁定，并且用笔记记下来。很多人的项目跑不起来，不是代码问题，而是SpringBoot版本太高、JDK不匹配、Node版本太新导致依赖安装失败这一类环境问题，后面我会专门写一节避坑内容。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计：一张预定表怎么撑起整个业务
2.1 核心表结构与字段设计
数据库设计是这个项目的灵魂，也是毕业论文里必须重点画ER图的地方。我们先从最核心的四张表说起。
用户表（user）包含：id、username、password、real_name、phone、role、status、create_time。密码不要存明文，至少用MD5加盐，更推荐BCrypt加密。角色字段用普通整数或字符串都可以，1表示管理员，0表示普通用户，也可以预留多角色扩展。
场地表（field）包含：id、name、type、location、capacity、price_per_hour、status、open_time、close_time、image、description。其中status用来标识场地是否可预订，比如1正常，0维护中。type可以区分篮球场、羽毛球场、乒乓球室等，方便前端做筛选。
预定表（booking）是所有业务逻辑的焦点，字段包括：id、user_id、field_id、book_date、start_time、end_time、total_price、status、remark、create_time、update_time。status字段建议用数字或字符串枚举，比如0待支付、1已预约、2已完成、3已取消、4已过期，这样在代码里判断清晰，在论文的状态图中也好画。
订单表（order）用来记录支付信息，字段包括：id、booking_id、user_id、amount、pay_type、pay_time、status。如果你的系统简化成“预约即支付成功”，那可以不单独拆这张表，直接在booking里加一个pay字段；但如果论文想写支付流程，甚至想接支付宝沙箱或微信支付，就必须建表。
这四张表之间的关联关系很直观：一个用户可以有多条预定记录，一个场地可以对应多个预定，一个预定可以对应一个订单。ER图画出来就是经典的一对多模型，画图和讲解都很方便。
2.2 时间冲突判断：预定系统的核心难题
场地预定系统最关键的逻辑就是时间冲突判断。用户选了2月20日下午3点到5点打羽毛球，系统必须保证这个场地的这个时间段没有被其他人预占。
最直观的SQL写法，是查所有“重叠时间段”的记录。假设目标场地的id是1，日期是2025-02-20，准备预约的开始时间是15:00，结束时间是17:00，那么冲突条件等价于：已有预约的开始时间小于新预约的结束时间，且已有预约的结束时间大于新预约的开始时间。
sql复制SELECT COUNT(*) FROM booking
WHERE field_id = 1
AND book_date = '2025-02-20'
AND status IN (0, 1)
AND start_time < '17:00:00'
AND end_time > '15:00:00'
这个条件看着简单，但新手很容易写成只判断“start_time等于”或“end_time等于”，那样就会漏掉跨时段重叠。比如已有预约是14:00到16:00，新预约是15:00到17:00，两者明显重叠，但如果只判断相等是判断不出来的。
注意status要限定为“占用中”的状态，比如待支付和已预约。已取消、已过期的预约不参与冲突判断。
2.3 状态机设计：从预约到完成的完整流转
预定记录不能只有一种状态，因为现实业务里预约会有取消、超时、完成等各种变化。我建议把状态机设计成下面这样：
- 0 待支付：用户提交预约，但尚未支付，系统生成的初始状态。
- 1 已预约（待使用）：支付成功或管理员确认后，场地被锁定。
- 2 已完成：使用时间已过，记录结束。
- 3 已取消：用户主动取消，或者待支付超时后系统自动取消。
- 4 已过期：已预约但用户未在预定时间使用，到时间后系统自动核销为过期。
这个状态机在论文里是很好画的一张图：五个状态，四条转化线，清晰明了。在实现上，建议在后端用一个枚举类或者常量类管理，前端只接收数字再映射成文字，不要在前端写死业务规则。
3. 后端核心实现：把“预定”这件事做稳
3.1 分层架构与统一接口返回
后端我会严格按Controller、Service、Mapper三层来写。Controller只做参数接收和结果返回，不写业务逻辑；Service负责业务规则，比如判断时间冲突、计算价格、更新状态；Mapper负责数据库操作，用MyBatis-Plus时大部分单表操作甚至可以不用写SQL。
接口返回格式必须统一。我习惯定义一个Result类，包含code、message、data三个字段。code为200表示成功，401表示未登录，403表示无权限，500表示服务器异常。每个Controller的方法都返回这个Result，前端axios拦截器统一处理，而不是每个接口返回各自的JSON结构。
java复制public class Result<T> {
private Integer code;
private String message;
private T data;
// 省略getter/setter和静态工厂方法success、error
}
登录认证我推荐用JWT。用户登录成功后，后端生成一个token，带用户id和角色信息，前端存在本地，每次请求放在Header的Authorization里。后端写一个拦截器或过滤器，校验token，解析出用户信息放到ThreadLocal里，供后续业务使用。这样既实现了登录验证，也顺带把权限控制做了。
3.2 预订接口的并发处理：别让两个人抢到同一个场地
这个点值得单独拿出来讲，因为它是整个系统最容易被面试官追问的地方，也是论文“系统设计”章节里最有技术含量的段落。
如果只做“先查询冲突，再插入数据”两步，在高并发场景下会出问题。假设两个用户同时提交同一个场地、同一个时间段的预约，两个请求都先执行了查询，发现没有冲突，然后都走到插入，最后数据库里就多了两条重复预约。
解决办法有三种，按推荐程度排序：
第一种，对场地记录加悲观锁。在同一个事务里，先执行SELECT * FROM field WHERE id = ? FOR UPDATE，把场地行锁住，然后再做冲突查询和插入。这样同一个场地的并发预约请求会排队执行，从根本上避免重复。
第二种，依赖数据库唯一索引。前面说过冲突条件是“start_time < 新end_time 且 end_time > 新start_time”，这个条件没法直接建唯一索引，所以我们需要额外设计。一个比较巧妙的方法是新增一个字段，叫时段标记，比如“2025-02-20_15:00-17:00”，对这个字段加唯一索引。插入时如果冲突就会抛DuplicateKeyException，捕获后提示用户该时段已被约满。这个方案效率高，无锁化，但要求业务上时段格式统一。
第三种，使用Redis分布式锁。把场地的id和日期拼成一个锁key，例如lock:booking:1:2025-02-20，在提交预约之前先尝试加锁，加锁成功才执行后续逻辑，执行完释放锁。这个方案在单体应用里有点大材小用，但如果论文想写“系统扩展性”，可以设计进去。
我个人建议毕业设计用第一种方案，代码最容易理解和讲解。事务加@Transactional，把锁、冲突判断、数据插入放在一个方法里，逻辑闭环，面试时也说得清楚。
3.3 定时任务与自动取消：让系统更智能
用户提交预约后如果一直不支付，场地就会被白白占用。这里需要一个定时任务，把超过预定时间还未支付的预约自动取消，释放场地。
SpringBoot自带@Scheduled注解，可以实现简单的任务调度。我在项目里一般会在启动类上开启@EnableScheduling，然后写一个定时任务类，每30秒扫描一次待支付且下单时间超过15分钟的预约，将其状态改为已取消。
java复制@Component
public class BookingExpireTask {
@Scheduled(fixedRate = 30000)
public void expirePendingBookings() {
// 更新待支付超过15分钟的预约状态
}
}
扩展思路：如果你的系统里还有“预约即将开始”的短信或邮件提醒，也可以用同样的定时任务机制，每天上午扫描当天有预约的用户，再配合阿里云短信或邮件服务发通知。这个功能写进论文可以放到“系统特色”里，实际操作也不复杂。
4. 前端核心实现：用户能感知到的才是好评
4.1 Vue工程搭建与请求封装
前端我用Vue CLI或Vite创建项目，结构上按页面分模块：登录页、场地列表页、场地详情页、预约确认页、个人中心、后台管理。每个页面放到views目录，公共组件放到components目录，接口请求统一放api目录。
Axios必须统一封装。请求拦截器里做两件事：从localStorage取出token放入请求头；显示loading。响应拦截器里做三件事：code为200时正常返回数据；401时跳转登录页并清除本地登录态；其他错误码弹出统一提示。
javascript复制// 请求拦截器
service.interceptors.request.use(config => {
const token = localStorage.getItem('token')
if (token) {
config.headers['Authorization'] = token
}
return config
})
// 响应拦截器
service.interceptors.response.use(response => {
const res = response.data
if (res.code === 200) {
return res.data
} else if (res.code === 401) {
// 清除登录信息并跳转
router.push('/login')
} else {
Message.error(res.message)
return Promise.reject(new Error(res.message))
}
})
跨域问题在这个阶段会遇到一次。开发环境下，我一般会在vue.config.js里配置devServer的代理，把/api开头的请求转发到后端地址，这样前端代码里统一写/api开头，不会出现端口不一致的问题。
javascript复制devServer: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
4.2 场地列表与预约流程
场地列表页是整个系统最核心的展示页面。我倾向于把“日期选择器”和“场地卡片列表”放在同一屏：用户先选日期，再按场地类型筛选，每张卡片显示场地名、类型、位置、时段价格。点击卡片跳到详情页，详情页里展示该场地当天的可预约时段。
可预约时段怎么展示？这里有个设计细节。后端提供一个接口，接受场地id和日期，返回该场地当天所有被占用的时段列表；前端生成当天所有的开放时段，把已占用的时段置灰，其他时段可点击选择。这样前后端的分工非常清晰。
预约流程中比较关键的一步是提交前的前端二次校验。用户选了时间段后，前端可以再调用一次“预检查”接口确认时段仍然空闲，避免用户停留在页面太久，等提交时才发现冲突。后端接口幂等性也很重要，用户连续点击两次提交按钮，不能生成两条预约，我通常是提交时把按钮设为loading状态，同时后端事务+锁保证不会重复插入。
4.3 登录态管理与权限路由
前端路由守卫是做权限控制的标准做法。在router.beforeEach里判断当前路由是否需要登录权限，需要的话检查token是否存在；如果页面要求管理员角色，还要解析token里的角色信息，不符合则跳转到无权限页。
javascript复制router.beforeEach((to, from, next) => {
const token = localStorage.getItem('token')
if (to.meta.requiresAuth && !token) {
next('/login')
} else if (to.meta.roles && !to.meta.roles.includes(userRole())) {
next('/403')
} else {
next()
}
})
这里有个容易被忽视的点：权限校验不能只靠前端。某些同学喜欢在路由里隐藏“管理后台”入口，觉得这样就安全了。但用户完全可以手动输入URL或直接调后端接口，所以后端接口必须做角色校验，这是系统的安全底线。
另外，如果项目里做了球场监控回放功能，前端播放m3u8格式的流媒体，可以用video.js加hls插件实现。用户选择日期和时间段后，页面上的播放器拉取对应的流地址播放。这个功能属于加分项，但要注意流媒体的鉴权处理和延迟问题，建议在论文中单独作为一个小节来写。
5. 论文、PPT、演示视频：毕设的最后一道关
5.1 毕业论文的章节骨架与写作节奏
代码写完之后，论文是重头戏。大多数学校的毕业论文结构相对固定，按照“绪论—需求分析—系统设计—系统实现—系统测试—总结”这个六章骨架来写，基本不会跑偏。
绪论部分要写课题背景、国内外研究现状和研究内容。研究现状不要再写“国外信息化水平高、国内起步晚”这种空话，可以具体到某个领域，比如“国内高校体育馆预订普遍仍采用线下登记方式，在线预订系统在中小学校的覆盖率仍然偏低”，这样更接地气。
需求分析章节要画用例图，分别从用户和管理员两个角色出发，列出功能需求和非功能需求。非功能需求一定要写性能要求（并发量）、安全性（密码加密、权限控制）、易用性等，这是很多同学会漏掉的评分点。
系统设计章节，除了要画系统架构图和功能模块图，还要把数据库ER图和每张表的结构列出来。特别是预定表的设计，可以解释一下为什么这样设计，以及如何通过字段组合保证时间冲突判断的效率。
系统实现章节，按模块逐个写实现截图加核心代码片段加文字说明。代码不必全部贴，只贴核心逻辑，比如时间冲突校验、并发锁、状态转换。系统测试章节，用黑盒测试为主，列测试用例表格，至少包括正常场景、边界场景、异常场景。
5.2 答辩PPT：演示驱动而不是文字驱动
答辩PPT最常见的错误是把论文的每章标题复制过来，然后一堆文字。真正有效的答辩PPT应该以“功能演示+亮点讲解”为核心。
我的建议是：封面页之后先放技术架构图，一页讲清楚系统怎么搭的，然后直接进入功能演示。前端页面截图加上一句“这是场地列表页，用户可以按日期筛选场地”，配合流程图或时序图讲清楚预约流程。讲到一个亮点时，比如并发控制，放一段核心代码，用一两句话解释关键点。
PPT页数控制在12到15页。页数太多讲不完，页数太少显得内容单薄。每页文字不超过五句话，能用截图和箭头标注讲清楚的，就不要写大段文字。答辩现场大概率会用到演示，先把系统跑通，把数据准备好，把演示路径背熟，比背一百页PPT都有用。
另外一定要预演几个高频提问：为什么用SpringBoot而不是SSH？时间冲突是怎么解决的？如果并发用户量上来了怎么办？这些问题的答案我在前面都提到了，你可以提前在文档里写好，现场答起来就从容很多。
5.3 搭建视频怎么录：给学弟学妹留条活路
标题里提到的“指导搭建视频”，本质上是一个从零到一的环境配置和启动演示视频。录制之前，我建议你用OBS这类录屏软件，分两段录：第一段是后端启动，第二段是前端启动。
后端部分，先展示项目目录结构，再打开application.yml，把数据库地址、用户名、密码改成自己的，然后执行SQL脚本导入表数据，最后启动SpringBoot，看到Tomcat端口号8080启动成功。前端部分，用命令行执行npm install，等依赖装完，再执行npm run serve，浏览器访问localhost:8080看到页面。
视频里最容易翻车的地方，就是环境不一致。有些人是Windows，有些人是Mac，Node版本也不一样。所以视频开头务必用文字标注“本视频基于JDK1.8、Maven3.6、MySQL8.0、Node16录制，请确保本地环境版本一致”。视频录制过程中尽量不要中断，如果中途报错，也要把排查过程录下来，这反而是最有教学价值的部分。
6. 避坑手册：这些坑我替你踩过了
6.1 SpringBoot版本和JDK版本不匹配
这个坑可以说是新手翻车重灾区。网上很多教程还在用SpringBoot 2.x，你下载了一个最新的SpringBoot 3.x，然后发现项目启动直接报错，因为SpringBoot 3基于JDK17，而你本机装的是JDK8。反过来，你装了JDK17，又想用老的教程配SpringBoot 2.x，也会有一堆兼容问题。
我的建议是：如果是按教程走，教程用什么版本你就用什么版本，不要“升级”依赖。如果自己新建项目，选型逻辑是SpringBoot 2.7.x配JDK8，SpringBoot 3.x配JDK17，别混搭。另外，Maven的镜像源建议配置阿里云镜像，不然下载依赖的速度会让人怀疑人生。
6.2 Vue版本混乱导致组件库不兼容
前端同样有版本问题。Vue2配的是ElementUI，Vue3配的是Element Plus，两者语法和导入方式都不一样。如果你用Vue3写代码，却按Vue2的文章去配置路由，会报各种奇奇怪怪的错误。
还有一个高频问题：Node版本太新，导致npm install时报node-sass安装失败。解决办法是换成sass（dart-sass），或者直接用低版本Node，或者用npm淘宝镜像源安装。我在项目里直接用官方推荐的sass，少了很多麻烦。
6.3 跨域、代理与接口对接
前端跑在8080端口，后端跑在9090端口，前端调接口直接报403或跨域错误。这个问题在开发阶段用devServer的proxy代理就能解决，但有时候代理配了还是不行，原因通常是target写错了，或者路径没加/api前缀。解决方法是先打开浏览器开发者工具，看Network里的请求URL是不是正确，再检查后端能不能通过Postman访问。
如果你不做代理，也别忘了后端写一个CORS配置类，允许指定来源跨域访问。两种方式二选一即可，同时用有时候反而会有奇怪的问题。
6.4 并发测试发现重复预约
这个问题我特意放到最后，是因为它很难在开发阶段暴露。你一旦用JMeter或Postman并发请求接口，就可能发现同时间段出现了两条预约记录。
这个问题的根子在于“先查后插”的操作不是原子的。我在前面讲过三种解决方案，最稳妥的是给场地记录加SELECT ... FOR UPDATE锁，配合事务。排查的时候，先检查Service方法是否加了@Transactional，再确认锁是加在场地表记录上而不是加在无意义的地方。这个修复过程本身，也可以写进“系统测试”章节作为典型案例。
写在最后
如果你正在做这个题目，我的建议是别把精力全花在写代码上。代码功能做完后，多花时间梳理一下时间冲突判断、并发控制、权限校验这几个核心点，它们既是论文的重点，也是答辩时最能体现你“真的做了”的地方。项目本身并不复杂，但能把这个“不复杂”的题讲明白、写清楚，就是一篇合格的毕业设计。
最后再分享一个小技巧：SpringBoot项目启动时，可以去banner生成器网站做一个自定义启动图案，把项目名字打成ASCII艺术字，加到resources目录的banner.txt里。这个细节看起来没什么用，但录演示视频或在答辩现场启动项目时，效果非常好，瞬间让人觉得你是一个对项目有热情的人。很多时候，这种小细节带来的印象分，比功能本身还管用。