1. 项目全貌高校体育馆预约系统到底要解决什么问题1.1 别急着写代码先弄清楚校园场馆预约的痛点每年到了计算机毕业设计选题季总有一大批同学盯着XX管理系统这类题目纠结。体育馆场地预约管理系统这个题目表面看就是一个常规的增删改查但真正动手之后你会发现它比普通的图书管理、商品管理要复杂得多也更有说头。因为场馆预约涉及一个核心问题同一块场地在同一个时间段不能被预约两次——这就是典型的资源冲突问题也是整张表结构设计和后端接口设计的灵魂所在。先来想象一下没有这套系统时高校体育馆的日常。学生想打羽毛球得跑到场馆前台看纸质登记本翻到想订的时段发现被人写上了名字只能换个时间。管理员天天跟登记本、Excel表打交道月底统计各场馆使用率得手动数数财务报表全靠拍脑袋。遇到临时调课、社团活动占场黑板通知一下经常有学生到了现场才发现场地被征用白跑一趟。这些痛点归纳起来就是三件事场地使用情况不透明、预约流程效率低、人工管理易出错。这个题目能成为热门选题正是因为它踩中了校园数字化转型的真实需求。你在毕业设计答辩时如果能把这些痛点讲清楚再对照着你做的系统展示怎么逐一解决这就比空谈本系统实现了场馆预约功能要有说服力得多。从技术角度来说它又是一个非常典型的前后端分离项目考试范围覆盖了 SpringBoot 的核心知识、MySQL 数据建模、Vue 组件化开发难度适中工作量可控非常适合作为本科阶段的综合训练。1.2 用户角色与核心需求拆解系统给谁用他们各要什么一套校园场馆预约系统使用者不只是学生一个人。我在做这类项目时习惯先画一张角色-需求对照表把每类用户的核心诉求拆清楚再去设计功能模块。这个思路也推荐给你因为需求分析是毕业设计文档里最容易被老师挑刺的部分写得好就是加分项。首先是学生用户他们的核心诉求是快速看到哪些场馆在什么时间段有空位能在线提交预约到点直接进场打完球走人。他们需要的是清晰的场地列表、直观的时间段状态、简洁的预约表单以及个人预约记录和取消功能。其次是教师用户他们除了预约场馆往往还需要为课程或社团活动批量预约固定时段所以要有区别于普通学生的权限或者特殊预约通道。场地管理员是系统的中枢负责维护场地信息、审核预约订单、处理取消与违规操作还需要查看统计报表。最后是超级管理员一般由系统开发人员或体育部老师担任负责人账号管理、权限分配、系统参数配置。基于这样的角色分析核心模块就能自然拆出来了用户认证与权限管理、场馆信息管理、预约订单管理、公告通知、个人中心、数据统计。特别提醒一点很多同学喜欢在这个题上疯狂加模块什么论坛、二手交易都塞进来这是在给自己挖坑。毕业设计的评分重点是把核心业务做扎实而不是功能数量堆砌。你要记住一句做项目的老话做减法不做加法。把预约这条主线走通、走稳就已经超过了大半同学。1.3 项目技术栈速览这套方案能不能Hold住答辩做毕业设计技术选型的第一原则是稳。不要为了炫技选一个自己完全没把握的框架答辩现场一问三不知分数直接腰斩。SpringBoot Vue 这个组合之所以是当前毕业设计的绝对主流就是因为生态成熟、资料丰富、面试官和答辩老师都认说白了它是一个打得赢的选择。后端采用 SpringBoot 2.7.x MyBatis-Plus MySQL 8.0这个组合能解决开发效率问题。MyBatis-Plus 封装了常见的 CRUD 操作代码量能减少三成而且它对学习过 MyBatis 的同学来说几乎是零门槛。权限部分用 Sa-Token 或 JWT 都可以我更推荐前者因为它的登录鉴权注解用起来非常直观而且内置了踢人下线、账号封禁等功能写起来省很多功夫。前端用 Vue 2 Element UI 或者 Vue 3 Element Plus这个看个人熟练度如果之前学过 Vue 2完全没必要硬上新版如果是从零开始建议直接学 Vue 3。缓存层用 Redis主要用来缓存场地列表、存储验证码、做分布式锁这些点说出来都是加分项。再补充一个容易被忽视的决策Maven 版本和 JDK 版本要匹配。我见过太多同学在环境配置上卡了一个星期SpringBoot 2.7 配 JDK 17 本来没问题但如果你用了某个旧版 Maven 插件就可能莫名其妙报错。建议统一用 JDK 1.8 或 JDK 11Maven 3.8.x这组合最稳搜报错信息也非常容易。下一步我就带你把这套方案真正落地。2. 数据库设计预约系统好不好用全看这几张表2.1 核心表结构拆解从用户表到订单表一张张说清楚数据库设计是这个项目里最考基本功的部分。我见过的失败案例中十有八九是栽在表结构上要么字段缺失导致后面疯狂改代码要么关系混乱导致查询逻辑绕来绕去。这里我把核心表结构按业务逻辑梳理出来你直接当模板用都行。第一张表是用户表。除了常规的 id、username、password、real_name、phone、email 之外还要有 role 字段来区分用户类型我习惯用 0 表示学生、1 表示教师、2 表示管理员配合一个 status 字段表示账号是否被封禁或停用。注意一个细节密码字段不要用 varchar(50) 存明文用 BCrypt 加密后存 60 位左右的哈希值这不仅是安全要求答辩时也能成为一个技术亮点。第二张表是体育馆表字段比较简单场馆名称、位置、容纳人数、开放时间段、场地类型、封面图 URL、管理员 ID、状态。这里容易忽略的是开放时间段到底怎么存。直接用两个字符串存08:00-22:00这种格式虽然简单但后续做场次切分时会很痛苦。我建议拆成 open_time 和 close_time 两个 time 类型的字段后端代码去判断当前时间是否在区间内灵活得多。第三张表是场地明细表这张表容易被漏掉但不能没有。体育馆是一个物理空间里面可能包含多个羽毛球场、多个篮球半场每个子场地才能独立预约。比如体育馆 A 区羽毛球 1 号场和2 号场是两个不同的可预约资源。所以需要一个场地表包含所属体育馆外键、场馆编号、类型、每小时价格、是否可预约等字段。有了这层设计你才能做出真正的多场次并发预约效果而不是所有学生挤在一个体育馆上。第四张表是预约订单表这是全系统的核心。关键字段包括订单编号、预约人 ID、场地 ID、预约日期、开始时间、结束时间、总金额、状态、创建时间、备注等。订单状态我建议用一个 int 字段管理0 待支付、1 已预约、2 已取消、3 已使用、4 已过期。这里可以用一个状态机图去描述订单的流转过程写进毕业设计文档里非常加分。最后辅以公告表、轮播图表和管理员操作日志表用于支持首页展示与后台追踪。公告表很简单标题、内容、发布时间、是否置顶。操作日志表可能会被忽略但它能在答辩时讲出系统安全性设计的故事建议保留。2.2 字段类型与规范时间字段怎么存、金额字段怎么设表结构你画出来了字段类型也要讲究。我批过不少代码常见的问题集中在时间字段和金额字段上。先说时间字段。预约日期用 date 类型开始时间和结束时间用 time 类型创建时间这类用 datetime别图省事全都用 varchar。你用 varchar 存时间数据库里没法直接排序和比较后续做查询某个时间段内所有预约订单这种需求时会非常难受。金额字段直接踩坑的重灾区有人习惯用 float 或者 double 存钱这在正经项目里是不允许的。以每小时 25 元为例浮点数误差在多次乘法运算后会累积可能算出 24.999999。正确做法是用 decimal(10, 2)精确到分后面做支付对接也不会吃亏。另外用户余额不建议拆进用户表里一起做单独设计一张账户流水表更清晰用户每次充值或消费都插入一条流水余额通过流水累计算出。还有一个容易翻车的点就是时区问题。MySQL 8.0 的默认时区通常和你的服务器时区不一致会导致后端存入的时间比实际时间早了 8 小时。这个我在第 7 节会给你一个一劳永逸的解决清单建表阶段先记住连接参数里加上 serverTimezoneAsia/Shanghai并且统一使用 LocalDateTime 类型不要用 java.util.Date。2.3 优化与索引预约查询慢的坑提前埋掉数据表结构定型之后还要做索引规划。预约系统的核心查询是给定日期和场地找出已被占用的时间段这条查询的 WHERE 条件通常长这样场地 ID 相等、预约日期相等、状态不是已取消、开始时间小于传入的结束时间并且结束时间大于传入的开始时间。这个条件如果不加索引数据量一上来就会全表扫描响应时间从几十毫秒飙升到几百毫秒甚至秒级。解决方案是在 venue_id、reserve_date 这两个字段上建联合索引再把 start_time 和 end_time 加入索引。有人可能问为什么不用复合索引直接包含四个字段因为在 InnoDB 引擎下索引列的顺序会影响查找效率把等值条件的字段放前面把范围条件的字段放后面是最常规的策略。这样写 SQL 的时候MySQL 一眼就能定位到当天该场地的所有订单再做时间重叠判断就轻松了。另外给 MySQL 加连接池参数时把 Druid 的 initialSize 设为 5、maxActive 设为 20足以满足毕业设计场景的并发量。别给自己加戏去调几百个线程池参数没有必要。2.4 表间关系与扩展性为后面功能升级留好余地最后聊聊关系的设计思路。用户表与订单表是一对多体育馆表与场地表是一对多场地表与订单表是一对多公告表独立。这里有一个可以预埋的扩展点要把体育馆和场地分离而不是让订单直接挂在体育馆下。这样设计之后未来如果学校上线了教练预约或设备租赁只需要新增一张表关联到场地表即可不会对现有表结构造成破坏。很多同学做毕设时会临时发现需要加字段比如还要记录用户预约了几个人这时候直接改原表加上 people_count 字段就行。但要记住一点如果某天你需要加一个字段到订单表而这个字段在下单那一刻就应该被冻结保存下来那就不该去关联查询场馆价格表而要在订单表里冗余存一份当时的单价。这就是订单管理系统的核心思想——记录快照。答辩老师如果问为什么订单表里要冗余场地价格这就是标准答案。3. 后端核心流程预约接口是怎么做到不重不漏的3.1 预约冲突检测如何判断同一时段场地已被占用预约系统的头号技术难点就是并发冲突检测。设想一下两个学生同时点击预订周一 18:00-20:00 的羽毛球 1 号场后端如果只是简单地先查一下有没有冲突再插入订单在高并发下两个请求可能同时查询到没有冲突然后双双写库成功这就产生了超卖问题。用生活类比就是演唱会抢票两个人同时抢到最后一张票如果系统不做原子性约束都可能付款成功。解决冲突检测有三层方案由浅入深。第一层是数据库唯一索引比如在 venue_id、reserve_date、start_time 上建立唯一索引这样同样的场地、日期和开始时间基本不会重复。但它管不住18:00-19:00和18:30-19:30这种部分重叠的情况。第二层是事务 悲观锁使用 SELECT ... FOR UPDATE 锁住该场地当天的记录行阻止并发插入。第三层是 Redis 分布式锁在服务端用一个 key 锁住某个场地某天这个维度比如锁 key 为 venue:1:2025-05-20。我建议你实现第二层方案就够了代码量少、逻辑直观毕业设计完全够用。对应到代码上插入订单前需要执行一个时间重叠判断核心 SQL 条件是这样的同一场地、同一日期、状态非取消、start_time 传入的结束时间 且 end_time 传入的开始时间。只要查询结果存在记录就说明时间段冲突。这是整个预约模块最核心的一段业务逻辑把它吃透这张订单表的设计就真正活起来了。3.2 业务校验与状态机订单状态流转千万别做成自由态订单状态字段如果设计不好系统会变成一锅粥。我建议采用一个状态机来控制流转待支付、已预约、已取消、已使用、已过期五个状态缺一不可且每种状态有明确的跳转条件和边界。比如待支付状态下用户取消订单进入已取消已预约状态下用户取消订单也进入已取消但已被管理员核销的订单不允许用户取消到达预约结束时间后系统自动判定该订单为已完成或已过期。这些规则要在 Service 层做强制校验不能让前端页面随意修改订单状态。我在项目里会专门写一个枚举类 OrderStatusEnum 来维护状态码和状态描述用状态码做存储、用状态描述做展示。在服务端接口里每次更新订单状态前都先从库里查出当前状态再用 if 判断是否允许跳转。有人图方便直接用 UPDATE ... SET status新值 覆盖那后面要统计已取消订单数时就会发现数据一团乱。后台管理员的操作也值得留意管理员核销订单时必须校验订单当前是否处于已预约状态核销后才改为已使用。如果核销一个已取消的订单就要抛出业务异常。这种防御式编程能让系统在异常操作面前不至于崩溃写进论文的系统健壮性设计章节就是干货。3.3 定时任务与状态清理过期的脏订单不能留着过年预约订单不是用户下了单就永远不变的。实际运营中用户可能预约后不来也可能多次预约但只去一次这就需要定时任务去清理过期订单。SpringBoot 提供了 Scheduled 注解使用起来非常简单在启动类加上 EnableScheduling然后在类内部写一个方法标注 Scheduled(cron 0 */15 * * * ?)表示每 15 分钟执行一次。定时逻辑是查出所有状态为待支付且创建时间超过 30 分钟的订单把它们置为已取消并释放场地查出所有状态为已预约且结束时间小于当前时间的订单把它们置为已完成。这样场地资源就能及时释放学生也不会看到一个过期的订单还挂在待支付里。定时任务虽然简单但要注意触发器表达式别写错。cron 表达式从左到右依次是秒、分、时、日、月、周。比如 0 */15 * * * ? 表示每小时的 0 分、15 分、30 分、45 分执行最后一位?表示不指定星期几。这个表达式写错任务可能永远不执行或者狂刷日志排查起来让人头大。3.4 Redis 缓存与接口性能毕业设计也能聊点高并发调优预约系统作为一个面向全校学生的平台要考虑突发流量。比如周一上午 10 点整开放本周场地预约一瞬间可能有几百上千个请求同时打进来。虽然毕业设计不用扛住真正的千万级流量但通过缓存和限流来保护数据库是一个很好的工程实践。场地列表和体育馆信息是典型的读多写少数据可以缓存到 Redis 里设置 5 分钟过期。管理员修改场地信息后主动调用删除缓存的方法下一次请求再回源数据库重建缓存。这就是经典的 Cache-Aside 模式理解了它你这套系统的性能故事就能讲得圆。另外给预约接口加上一个简易限流使用 Google 的 Guava RateLimiter 或者 Redis 的 INCR 计数在秒级时间窗口内限制同一 IP 最多请求 N 次防止脚本刷接口。答辩时讲解这些设计思路效果远比你堆一百个功能点要好。4. 前端实现Vue 3 Element Plus把预约页面做得好看又好用4.1 项目搭建与目录结构前后端分离项目的起点前端部分我推荐使用 Vue 3 Vite Element Plus。相比 Vue 2 的 Webpack 构建Vite 启动速度快、依赖安装简单、报错信息友好对初学者尤其友好。搭建方式极简在命令行执行 npm create vitelatest frontend -- --template vue然后 npm install 安装基础依赖最后 npm run dev 启动开发服务器。Element Plus 的引入也很简单在 main.js 中全量引入即可。在毕业设计阶段不需要做按需引入虽然全量引入打包体积大一点但胜在省心。记住一个铁律项目能跑起来比什么都重要。目录结构建议采用标准分层views 目录按业务模块划分存放页面组件api 目录存放所有后端的请求函数router 目录配置前端路由store 目录管理全局状态。一定不要把所有代码塞进 App.vue那是新手最容易犯的错误等页面一多改一个变量要找半天。4.2 场地列表与预约表单核心页面的交互逻辑场地列表页是用户进入系统的第一屏。用 Card 卡片式布局展示每个场地卡片上要显示场地图片、名称、位置、开放时间、价格和当前状态。状态渲染是这里的关键细节如果当前时间在开放时段内且场地有可预约的空位就显示绿色可预约按钮如果没有空位或者当前不在开放时段就置灰。这个判断逻辑放在前端只是展示层面的过滤真正的时间冲突校验必须以后端为准前端只是提升用户交互体验。用户点击预约后进入预约表单页。表单里有三个关键字段预约日期、开始时间、结束时间。日期选择器可以通过 Element Plus 的 el-date-picker 来做但我强烈建议加一个限制从今天起只能预约未来 7 天内的场地。这个规则写在后端校验里更安全前端只是做友好的提示。选好日期后可以调用后端一个单独的查询接口动态加载该场地当前日期下已被占用的时间段用日历或时间线的方式展示用户一眼就能看到哪些时段还可以订。提交预约时的前后端联调也有讲究前端时间组件拿到的是一个 Date 对象提交给后端前应该格式化成HH:mm的字符串。我见过很多同学直接把 Date 对象序列化传过去后端一接收到就报格式错误或者时区错乱。统一约定所有前端传后端的时间格式为 yyyy-MM-dd HH:mm:ss后端返回也保持一致问题就少了一大半。4.3 后台管理端数据可视化让系统立刻高级起来后台管理端是给管理员用的技术含量和前台页面其实不相上下。它通常由几个页面组成场馆管理页、场地管理页、订单管理页、用户管理页、公告管理页和统计报表页。场馆管理页是标准的表单 表格页面包含新增、编辑、删除几个操作图片上传用 Element Plus 的 el-upload 组件上传到后端后返回图片 URL 再回填表单。订单管理页是列表查询带状态筛选和多条件搜索比如按订单号、按用户、按场馆、按日期范围筛选。要说后台最出彩的功能是统计报表页。用 ECharts 绘制柱状图和折线图展示各场馆每周预约人次、每日订单量趋势、场地使用率排行。这一页做得漂亮答辩时的演示效果会非常震撼。ECharts 的引入方式在 Vue 3 中先用 npm install echarts然后在组件内用 echarts.init 初始化图表实例用 setOption 填入配置项。值得注意的是ECharts 图表容器必须有一个明确宽度和高度的 div否则会渲染成 0 高度导致白屏。这是我踩过的坑提前告诉你。4.4 路由权限拦截与状态管理前端安全不能靠自觉前端路由还需要一个容易被忽略的环节路由守卫。未登录用户直接访问 /admin 页面时前端应该自动跳转到登录页。Vue Router 的 beforeEach 导航守卫可以轻松实现每次路由跳转前检查本地存储里的 token不存在就跳转到 /login。同时根据用户角色判断是否放行管理员页面。这里要强调一点前端路由守卫只是提升用户体验的手段真正的数据安全必须由后端接口鉴权来保证。一个懂行的答辩老师肯定会问前端路由拦截了那别人直接调接口怎么办所以后端每个管理接口都要用注解标注需要什么角色这才是正经答案。状态管理方面我建议用 Pinia 来保存用户登录信息和全局配置比如 token、用户名、头像等。Pinia 是 Vue 官方推荐的状态管理库API 简洁还支持持久化插件。在写接口请求时统一封装一个 axios 实例设置 baseURL、请求超时时间、请求拦截器自动附带 token和响应拦截器统一处理 401 状态码跳转登录页。这个 axios 封装是每个 Vue 项目都要过的一道坎封装好了后面每个页面的代码都清爽许多。5. 系统整合与部署Vue 打包放进 SpringBoot 的一体化方案5.1 开发环境联调前后端各跑各的如何让数据通起来开发阶段通常用前后端分离模式前端跑在 5173 端口Vite 默认后端跑在 8080 端口。这时候前端要访问后端接口就会遇到跨域问题。跨域的解决方案在开发阶段最简单的是使用 Vite 的代理配置在项目根目录下找 vite.config.js 文件里面配置 server.proxy把所有以 /api 开头的请求代理到 http://localhost:8080。这样做的好处是浏览器看到的请求地址是同源的后端不需要额外配置 CORS前端的 axios baseURL 直接写 /api 就行。到了生产部署阶段我更推荐把前端打包后的静态文件直接放进 SpringBoot 项目中一体部署这样整个系统只有一个服务端口网络拓扑简单也方便答辩时演示。Vue 项目执行 npm run build 之后会生成 dist 目录里面有 index.html 和 assets 目录。把这些文件复制到 SpringBoot 项目的 src/main/resources/static 目录下重新打包启动后端直接访问 http://localhost:8080 就能看到前端页面。5.2 构建与启动脚本一键打包不怕答辩现场翻车一体部署虽然配置简单但每次前端改完代码都要手动打包、复制、再打包后端效率很低。所以推荐直接用 Maven 插件实现自动化在 pom.xml 里配置 frontend-maven-plugin这个插件可以在 Maven 构建时自动下载 Node.js、执行 npm install、执行 npm run build然后把 dist 目录的内容复制到 target 目录下的 static 文件夹。这样一来整个项目只需要执行 mvn clean package就能自动完成前端构建 后端打包全过程产出一个可直接运行的 jar 包。配置这个插件时要注意 Node 版本和 Maven 缓存路径的问题。如果你本机已经装了 Node可以直接在构建服务器上配置 exec-maven-plugin 执行 npm 命令省去插件自动下载 Node 的时间。这几个插件的写法网上有大量模板直接抄过来调试通过即可不用强行理解每个参数。我记得第一次配这个插件的时候光是调试下载 Node 慢到超时就花了半天后来换成 exec 方式才舒服了。5.3 部署环境准备从 jar 包到可访问的服务拿到打包好的 jar 包后部署就简单了。最简单的命令是 java -jar xx.jar 直接启动。但实际部署时建议写一个启动脚本指定 JVM 内存参数、激活的配置文件和环境变量。比如 java -Xms256m -Xmx512m -jar xx.jar --spring.profiles.activeprod这个方式可以在不改代码的情况下切换开发和生产配置。生产环境还有两个隐藏问题需要提前处理。一个是日志问题要用 logback 或 log4j2 配置按天滚动输出的日志文件方便排查线上问题。另一个是数据库初始化问题首次部署时可以让 SpringBoot 自动执行 SQL 脚本在 application.yml 里配置 spring.sql.init.modealways配合 schema.sql 和 data.sql服务器一启动表结构和初始化数据就自动建好省去手工导入数据库的麻烦。还有一个需要注意的坑是端口占用。如果 8080 端口被占用启动会立刻报错。可以先执行 netstat -ano | findstr 8080 看 PID然后在任务管理器里找到对应进程结束掉。这个操作在答辩现场几乎必上镜提前演练一遍不要到时候手忙脚乱。5.4 浏览器兼容与访问体验细节决定答辩观感最后聊两个部署后的细节问题。第一个是 Vue Router 的模式选择。开发环境下推荐用 createWebHistory 模式网址里没有 # 号好看。但在生产环境部署到 SpringBoot 的静态目录后如果用户直接刷新 /admin 页面会返回 404因为 SpringBoot 的静态资源处理器找不到这个路径对应的物理文件。解决方案有两类一类是在 SpringBoot 里添加一个控制器将未知路径转发到 index.html常见于 SPA 应用另一类是改用 createWebHashHistory 模式地址里带 # 号刷新永远不会 404但不够美观。毕业设计我建议直接用 Hash 模式稳字当头不用花时间处理转发问题。第二个是页面首屏加载速度。Vite 打包后的静态资源引入了强缓存策略如果部署后发现页面更新了但浏览器还是显示旧版那多半是缓存问题。可以在 index.html 的 head 里加一个 meta 标签禁止缓存或者在静态资源路径上拼接版本号。这个细节虽然在成绩单上不会直接加分但用户体验好老师演示时流畅不卡顿印象分自然就上去了。6. 常见问题与排查技巧实录这些坑我帮你提前踩过了6.1 后端接口报 401/403权限注解的配置时机登录功能写好后不少同学会碰到换了浏览器登录接口始终报 401的问题。这个问题的根因多半不是代码逻辑错了而是 token 有效期太短或是前端 axios 没有在后端约定的位置带上 token。SpringBoot 的 Sa-Token 默认从前端请求头 Authorization 读取 token所以你在 axios 请求拦截器中必须加上 config.headers[Authorization] token前端漏掉这一行后端怎么配置都没用。另一种 403 的情况更隐蔽某个接口在 Controller 上标了 SaCheckRole(admin)但当前登录用户实际上是普通学生角色不匹配就会返回 403。调试时先在数据库确认账号的 role 字段值再对比注解里的角色名是字符串就区分大小写这个坑我见得太多了尤其是 Admin 和 admin 这种大小写不一致的情况。6.2 时间字段前后端相差 8 小时时区问题的标准解法前端选的时间传到后端打印出来多了 8 小时这个问题几乎每个做 SpringBoot 项目的人都会遇到。原因很简单JSON 序列化时间时Jackson 默认把 LocalDateTime 转成了 UTC 时间浏览器看到后再转本地时区就发生了偏移。最简单的修复方式是在 application.yml 里配置时间格式和时区spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时MySQL 连接 URL 上也保证 serverTimezoneAsia/Shanghai。两者都配好之后从数据库读出来、传给前端的时间字符串就完全一致了。如果还有问题检查字段是否有 LocalDate 和 LocalDateTime 混用——LocalDate 不会带时分秒前端展示时不要按 datetime 格式去格式化。6.3 并发下单超卖问题事务与锁的完整示例前面提到过并发冲突检测的理论这里给一个可以落地的实现思路。核心是在 Service 方法上加上 Transactional 注解并让冲突检测和插入订单放在同一个事务里。如果使用的是 MySQL 的 InnoDB 引擎可以在查询冲突时使用悲观锁SELECT id FROM reserve_order WHERE venue_id? AND reserve_date? AND status ! 2 AND start_time ? AND end_time ? FOR UPDATE。这样同一个场地同一天的查询会被行锁锁住第二个请求必须等第一个请求的事务提交后才能查询从而避免了并发插入。另一种做法是使用 Redis 的分布式锁先尝试 SETNX 锁定 key拿到锁之后做查询和插入最后释放锁。这个方法在高并发场景下会更高效但要考虑锁超时和释放的问题。毕业答辩时提起我用了事务 悲观锁的思路老师一般就会满意。6.4 白屏、端口占用、依赖冲突环境问题速查表很多同学在部署阶段遇到的前端白屏不是因为代码问题而是静态资源路径不对。Vite 打包默认使用绝对路径 /assets/xxx.js如果你的系统部署在 Tomcat 根路径下没问题但部署在二级路径下就会 404。此时需要修改 vite.config.js 中的 base 配置设置为 ./ 相对路径。依赖冲突也是一个高频问题。SpringBoot 2.7 如果同时引入了旧版 commons-lang3 和新版 hutool可能会因为版本不兼容报 NoSuchMethodError。解决办法是引入 hutool 时排除掉传递依赖或者在 pom.xml 中显式声明 settings 版本。我也遇到过数据库连接池启动失败多半是 MySQL 连接驱动版本和数据库版本不匹配MySQL 8 的驱动类名是 com.mysql.cj.jdbc.Driver与 5.x 不一样别照抄旧配置。最后补一个很多人忽略的问题IDEA 无法正常启动 SpringBoot 项目。如果右上角根本没有启动按钮或者启动后提示找不到主类先检查 Maven 是否成功导入依赖执行 mvn clean compile 看有没有报错再检查 Project Structure 里的 SDK 版本是否和 pom 一致。环境问题虽然不考业务能力但非常消耗精力提前打好这些补丁后面就能把时间省在刀刃上。7. 项目答辩与后续扩展从毕设到真实系统的最后一公里7.1 答辩演示的重点别照着页面念要讲业务流程完成开发后答辩演示这个环节也值得认真准备。很多同学打开系统就一顿点击从登录开始讲讲完注册讲公告老师看下来毫无重点。更聪明的做法是演示前用一两句话交代系统的背景和角色然后直接进入核心链路——以学生身份预约一块场地、支付、管理员核销、查看统计报表。在这条链路上穿插讲解你遇到的技术难点和解决方案比如时间段冲突判断、订单状态机设计、定时任务清理过期订单。把怎么做的讲清楚比做了哪些功能更有深度。还可以准备一页架构图画出浏览器、Vue 前端、SpringBoot 后端、MySQL、Redis 之间的请求流向。展示时先说用户请求先经过前端路由守卫再带着 token 访问后端接口后端通过 AOP 鉴权再查缓存缓存没有查数据库这种对全链路有掌控感的回答在答辩中是真正的加分项。7.2 功能扩展方向预约之外还能加什么如果时间和精力允许这套系统还可以向几个方向扩展每一个都能撑起一段论文内容。第一个方向是多端适配做一个面向学生的微信小程序预约端复用后端接口只换前端壳。这个方向能提升系统的真实使用价值。第二个方向是消息通知预约成功、取消、开场提醒时可以给用户发短信或邮件用 SpringBoot 整合阿里云短信服务或者用 WebSocket 做站内信。第三个方向是对接校园支付目前用余额或模拟支付没问题但真实落地需要对接微信支付或支付宝沙箱这又能引出支付回调、订单关闭、对账等话题。第四个方向是数据统计大屏使用数据可视化大屏展示全校各场馆使用率、人流量热力图。只要你把核心预约闭环做扎实再往其中一个方向深挖这个毕设就能在班级里站稳第一梯队。7.3 做项目的最后一点心得我后来复盘自己做这类项目时最后悔的一件事是前期花了太多时间纠结技术选型和版本搭配真正动手写业务的时候反而被各种环境问题拖住了。做毕业设计不是做科研工程能落地、逻辑能自洽、答辩能讲圆就已经是优秀了。多花时间把核心预约流程写稳、把业务校验写全、把演示脚本背熟比反复换框架带来的成长更实在。这套 SpringBoot Vue 的体育馆预约系统如果真的从零到一完整走一遍你的收获绝对不只是拿一个毕业设计高分而是真正建立起了全栈开发的整体认知。希望这份经验对你有用。