SpringBoot+Vue体育馆预约平台系统开发实战：从数据库设计到冲突检测

如果你正在做一个“基于SpringBootVue的体育馆使用预约平台管理系统”大概率是课程设计、毕业设计或者想作为求职项目放进简历里。这个技术组合——SpringBoot、Vue、MySQL、MyBatis——几乎是国内Java全栈项目最经典的一套网上模板多到泛滥但真正跑起来能演示、能答辩、能说清楚设计思路的并不多。我这次直接把我做这套系统时的完整思路摊开来聊从需求拆解、数据库表设计、预约冲突处理的核心SQL到前端页面的交互细节、跨域问题、MyBatis缓存踩坑全部过一遍。坚持看完你会发现这个项目并不只是几个CRUD接口拼起来的管理后台而是有一套清晰的业务逻辑在支撑。这篇内容适合正在做课设或毕设的同学也适合想独立练手完整全栈项目的人。不管你是刚接触SpringBoot还是已经写过一些Java项目我都尽量把每一步的设计原因讲透——为什么要这么建表、为什么要用这种方式检测冲突、权限拦截放在哪一层写——让你不光会运行代码还能理解每个设计决策背后的逻辑。1. 项目概述与核心需求拆解1.1 这个体育馆预约平台到底在解决什么问题先聊需求。你去过大学体育馆或者商业健身房就会知道场地预约这件事在过去基本靠人肉排队或Excel表格登记。前台打电话确认、手写记录、口头预约管理混乱不说经常出现同一个时间段被两个人预定或者场地实际占用情况跟记录对不上的尴尬局面。这套系统要解决的核心问题就那么几个用户能在线上看到所有可预约的场地包括羽毛球、篮球、乒乓球、健身房等用户能按日期和时段发起预约系统自动检测冲突同一个场地同一时间段只能被预约一次管理员能审核和管理预约记录统计场地使用率管理场地信息和用户信息。跟传统的“信息管理系统”不同体育馆预约平台最核心的难点不在增删改查而在时间冲突检测和场地资源的状态管理。这两块做不好系统就是一堆CRUD的堆砌演示的时候也很容易被答辩老师问倒。换句话说场地数据、用户数据表谁都会建但“并发情况下同一时段被重复预约”这类问题才是真正区分设计水平的地方。1.2 技术选型为什么是SpringBoot Vue MySQL MyBatis这个技术组合几乎成了当前Java全栈项目的事实标准。SpringBoot负责后端接口服务内嵌Tomcat不用配置繁琐的web.xml一个mvn spring-boot:run就能启动Vue负责前端页面渲染配合Element UI组件库开发效率非常友好MySQL存业务数据MyBatis作为ORM框架用XML或注解写SQL灵活可控。选这套方案有几个非常现实的原因第一SpringBoot是目前招聘市场上Java后端的主流框架学了能用用了能写进简历。第二Vue在国内前端圈子里的普及率太高了前后端分离的开发模式也契合当前行业的真实工作习惯。第三MyBatis相比JPA更“透明”SQL完全可以自己控制对于需要写复杂统计查询比如场地使用率报表的场景反而更方便。第四MySQL免费开源部署环境要求低学生机、老笔记本都能轻松跑起来。提示如果只是应付课程设计这套组合几乎是最稳妥的。如果项目要求“分布式、高并发”那就要另说了但对预约平台这种典型的管理系统来说单体架构加合理设计完全够用。别为了炫技而引入微服务和消息队列老师问起来反而难圆场。2. 系统整体设计与数据库建模2.1 模块划分用户端、管理端、场地端怎么分我在设计这个系统的时候把整个功能域划分成了三个角色视角对应三组功能模块普通用户端注册登录、查看场地列表、按日期和时间段预约、查看我的预约记录、取消预约、修改个人资料。管理员端场地信息管理增删改查、预约记录管理审核、取消、导出、用户管理禁用/启用账号、公告管理。系统层登录鉴权、权限拦截、全局异常处理、统一返回值封装。这样划分的好处是边界清晰后端代码的组织可以跟着业务域走。我用的是经典的三层结构Controller接口层、Service业务逻辑层、Mapper/DAO数据访问层Entity和DTO分开。很多同学喜欢在Controller里直接写SQL这个习惯非常不好后面想扩展一个功能就得重写一大片代码答辩的时候讲起来也毫无层次感。2.2 数据库表设计与MySQL关键细节直接看核心表结构。预约平台最少需要这几张表用户表t_user字段名类型说明idbigint主键自增usernamevarchar(50)登录用户名passwordvarchar(100)BCrypt加密后的密码real_namevarchar(50)真实姓名phonevarchar(20)手机号roleint0用户1管理员2超级管理员statusint0禁用1启用create_timedatetime注册时间场地表t_gym字段名类型说明idbigint主键gym_namevarchar(100)场地名称gym_typevarchar(50)场地类型羽毛球、篮球、乒乓球、健身区locationvarchar(200)位置描述pricedecimal(10,2)每小时价格capacityint可容纳人数open_timevarchar(20)开放时间如09:00close_timevarchar(20)关闭时间如22:00statusint场地状态1可用0维护中image_urlvarchar(255)场地图片预约记录表t_booking字段名类型说明idbigint主键user_idbigint预约用户gym_idbigint预约的场地booking_datedate预约日期start_timevarchar(5)开始时间如14:00end_timevarchar(5)结束时间如15:00statusint0待确认1已确认2已取消3已结束pricedecimal(10,2)订单金额remarkvarchar(255)备注create_timedatetime创建时间说几个数据库设计上的关键点。时间字段这里我故意用了varchar(5)来存“HH:mm”格式的开始结束时间而不是直接用datetime。为什么因为预约场景下用户选择日期和时段是分开操作的日期用date类型时段只存起止时刻字符串后续做冲突检测时直接比较字符串即可业务逻辑简单直观。当然这种设计有局限——如果要做跨天预约比如晚上22点到次日8点就会出问题。我当前系统的开放时间固定当天内所以没问题。注意密码字段存的是BCrypt加密后的密文不是明文。很多课设项目喜欢把密码明文存库里答辩时老师一眼就能看出来这是很严重的安全扣分项。索引方面预约记录表必须对(gym_id, booking_date, start_time)建组合索引因为系统最频繁的查询是“查某天某场地是否已被预约”没有索引的话预约量一上来查询性能会越来越差。我实际建表时还加了一条唯一索引UNIQUE KEYuk_gym_date_start(gym_id,booking_date,start_time)作为并发场景下的兜底防线。这条索引的作用后面讲预约流程的时候会具体解释。3. 后端核心实现登录鉴权、预约流程与冲突处理3.1 SpringBoot三层架构与MyBatis的配合后端代码按“Controller-Service-Mapper”三层组织。我先说一下MyBatis在SpringBoot中的基础配置很多同学第一步就卡在这里。第一在pom.xml中添加依赖spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok等。第二在application.yml中配置数据源和MyBatis相关参数。下面是我常用的配置可以直接抄server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/gym_booking?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: yourpassword mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.gym.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl关键配置解释一下map-underscore-to-camel-case: true让数据库的snake_case字段比如real_name自动映射到Java实体类的驼峰属性realName省去大量resultMap。log-impl设为StdOutImpl开发阶段控制台能直接打印SQL排查问题非常方便。mapper-locations指向XML文件的路径如果SQL写在注解里这个配置可以省略。3.2 预约冲突检测怎么实现这是整个系统最核心的业务逻辑没有之一。设计不好后面全崩。我的实现思路是在Service层做双保险第一道保险插入预约记录前执行一个冲突查询判断该场地在该日期、该时间段是否已有有效的预约记录status为0或1第二道保险利用前面提到的联合唯一索引即使并发请求同时过来数据库层也会拒绝重复数据。先看冲突查询的SQL怎么写select idselectConflictCount resultTypejava.lang.Integer SELECT COUNT(*) FROM t_booking WHERE gym_id #{gymId} AND booking_date #{bookingDate} AND status IN (0, 1) AND #{newStartTime} lt; end_time AND start_time lt; #{newEndTime} /select核心逻辑是判断新增预约的时间段[newStartTime, newEndTime)与已存在的预约时间段是否存在重叠。两个区间重叠的条件是新的开始时间小于旧的结束时间且旧的开始时间小于新的结束时间。这个数学原理用大白话解释假设你已经约了14点到15点我要约14点半到16点。我的开始时间14:30小于你的结束时间15:00同时你的开始时间14:00小于我的结束时间16:00两个条件同时成立冲突预约失败。反过来如果我要约15点到16点因为15:00不小于15:00注意用了小于号边界不冲突条件不成立不冲突预约成功——你正好可以在上一个人结束的时候开始用场地。注意边界这里用而不是意味着“前一个预约的结束时间”和“后一个预约的开始时间”相同是允许的符合体育馆场地使用的实际逻辑。如果你的业务要求必须留缓冲时间清扫场地就把条件改成并额外校验间隔。3.3 预约流程的完整业务链路不建议把业务逻辑堆在Controller里。参考这种处理方式用户在前端选择场地、日期、时间段点击提交预约前端把数据POST到/api/booking/add。后端Controller接收请求后先做参数校验和登录状态校验再调用Service层的createBooking方法。Service层做的事依次是判断用户账号状态是否为启用禁用用户不允许预约。判断场地是否存在且状态为可用status1。判断预约日期不能是过去的日期且必须是当天起7天内的日期防止用户约得太远管理员排班不好做。执行冲突检测SQL查询count大于0就直接抛出业务异常。插入预约记录状态默认为0待确认或者根据后台配置直接置为1管理员可配置是否需要审核。返回统一的JSON结果。统一返回值我封装成Result对象格式是{ code: 200, message: 预约成功, data: { bookingId: 123 } }用统一的返回值结构前端处理会非常舒服不用每个接口单独判断返回格式。3.4 事务与并发别让一条SQL毁掉你的数据预约操作涉及多个数据库动作查冲突、插记录、更新场地状态。如果不加事务中间某一步失败就会留下脏数据。在SpringBoot里给Service方法加上Transactional注解即可Override Transactional(rollbackFor Exception.class) public Result createBooking(BookingAddRequest request) { // 校验场地状态 // 冲突检测 // 插入预约记录 // 更新其他关联数据 }rollbackFor Exception.class要特别注意。默认情况下Spring事务只在RuntimeException和Error时回滚如果是普通Exception事务不会回滚。加上这个参数遇到任何异常都会回滚保证数据一致性。在“查冲突再插数据”这段逻辑里存在一个经典的并发问题两个用户同时提交同一场地同一时段的预约都先执行了conflictCount查询发现没有冲突然后都插入记录导致超卖。解决办法有两个层面业务层面靠唯一索引兜底。插入时如果触发了唯一约束异常捕获后返回“该时间段已被预约”的友好提示。架构层面如果项目要求更高可以在Service层通过synchronized或分布式锁保证同一场地ID的预约请求串行化。但课设级别用唯一索引完全够不用把复杂度推上去。4. 前台Vue页面与交互细节4.1 Vue路由与组件拆分前端我用Vue 2 Element UI这套组合Vue Router负责页面跳转Vuex负责管理登录状态和用户信息——当然课设用localStorage也能搞定但Vuex更规范一些。页面结构大概拆成这样/login、/register登录注册页/home场地展示首页展示所有场地卡片支持按类型筛选/booking预约页选择日期、时间段提交预约/my我的预约查看预约记录取消预约/admin/gym管理员-场地管理/admin/booking管理员-预约管理/admin/user管理员-用户管理路由配置里需要给需要登录的页面加上路由守卫beforeEach判断本地有没有token没有就跳转登录页。这块不复杂但能让系统体验完整不少也让答辩时多一个可以展示的点。4.2 场地日历视图与时间段选择预约页是前端最核心的部分。场地信息展示用卡片列表点击某个场地后进入预约弹窗。预约弹窗里我做了“三步选择”的交互第一步选日期用el-date-picker禁用过去的日期同时限制只能选未来7天的日期。第二步选时间段这里有个重要细节——不让用户自由输入时间而是让系统根据场地的open_time和close_time自动生成可选时段列表。比如场地开放时间09:00到22:00就每小时一个时段生成09:00-10:00、10:00-11:00……21:00-22:00。生成后前端还要结合后端返回的“已预约时段”来置灰不可用的时段。generateTimeSlots(openTime, closeTime) { const slots []; let start new Date(2000-01-01 ${openTime}); const end new Date(2000-01-01 ${closeTime}); while (start end) { const endTime new Date(start.getTime() 60 * 60 * 1000); slots.push({ text: ${format(start, HH:mm)} - ${format(endTime, HH:mm)}, start: format(start, HH:mm), end: format(endTime, HH:mm) }); start endTime; } return slots; }第三步选完后提交预约前端POST数据后端返回结果成功则弹出提示并跳转到“我的预约”页失败则提示冲突原因。前端这块要把后端返回的message直接展示出来“该时间段已被预约”这样的提示对用户很友好。4.3 跨域问题与代理配置前后端分离项目第一个让人头疼的问题就是跨域。前端跑在8081端口后端跑在8080端口端口不一致浏览器默认会拦截跨域请求。我提供两种解决方案推荐用第二种。方式一后端开启全局跨域配置CORSConfiguration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOrigin(http://localhost:8081); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); return new CorsFilter(urlBasedCorsConfigurationSource(config)); } }方式二前端通过Vue CLI的proxy代理转发请求后端不用管跨域。在vue.config.js里配置module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };请求写到/api/...时开发环境会自动转发到后端8080端口。推荐这种方式因为上线部署时也可以用Nginx做同样的事思路完全一致。5. 权限控制与业务规则的落地5.1 用户、管理员、超管的角色权限模型权限模型我设计得比较轻量t_user表里的role字段区分角色。后端每次请求都通过拦截器验证请求头里的Token解析出用户ID和角色后再判断该接口是否允许当前角色访问。我写了两个拦截器AuthInterceptor检查请求头是否存在有效Token没有就返回401拦截所有需要登录的接口。AdminInterceptor在AuthInterceptor通过后检查当前用户角色是否为管理员role1或2否则返回403。这种拦截器方案比在每个接口里用if判断角色优雅得多代码少也好维护。但要讲清楚这是最基础的权限方案只满足课设级别生产级别的权限要上Spring Security或Sa-Token牵扯到权限树、动态路由、细粒度授权等更多东西。答辩时主动说明这一点老师会觉得你对技术边界有清晰认知。5.2 业务规则一个场地同一时间段只能被预约一次这个规则前面已经通过SQL冲突检测和唯一索引实现。这里再补充一个用户端规则同一个人不能同时预约两个不同场地的相同时间段。也就是说一个用户同一时间段只能出现在一个场地。这个逻辑同样可以做冲突检测把SQL的过滤条件从“按场地查”改成“按用户查”即可。这些规则其实都来自真实业务场景。答辩的时候如果能说出来“为什么这么设计”老师会觉得你考虑得很全面而不是单纯翻了别人的代码。5.3 管理员审核与取消预约的权限边界预约状态机我定义得很清楚待确认(0) → 已确认(1) → 已结束(3)待确认(0) 和 已确认(1) → 已取消(2)用户只能取消自己名下且状态为待确认或已确认的预约管理员可以取消任何人的预约管理员可以把待确认置为已确认也可以将未开始场次的预约置为已结束。这里有个坑要提醒取消预约后场地的时间段释放其他用户才能再次预约。取消操作里除了更新预约状态还要注意“占用”是否同步释放。我的方案里没有在预约后锁定场地状态所以直接改status即可占用的释放自动完成——因为冲突查询会过滤掉status2的取消记录。6. 常见问题与排查技巧实录6.1 MyBatis缓存引发的灵异问题开发预约模块时遇到过一个诡异现象管理员在后台修改了场地状态比如改成“维护中”前台刷新后显示的依然是“可用”。查了半天问题出在MyBatis的二级缓存没有关闭。默认情况下MyBatis二级缓存是关闭的但如果你在Mapper XML里加了cache/标签或者引入了某些配置意外开启了缓存旧数据就可能留在内存中导致“改了但看不到变化”的假象。排查步骤分享给你在application.yml里把MyBatis的log-impl打开看SQL到底有没有真正执行如果发现查询结果没变化但SQL没打出来说明命中缓存了临时处理在对应Mapper方法上加Options(useCache false)或者清掉缓存重试。其实对这种管理类系统我建议跨会话的二级缓存直接关掉没必要为了那点性能去踩缓存一致性的坑。真要关心性能对热点数据做Redis缓存更可控。6.2 MySQL时间字段的坑前面提到我用varchar(5)存时间段前期写预约逻辑很爽但做到后面要统计场地使用率时开始难受了。比如统计某天某个场地的总预约时长SQL会写成这样SELECT gym_id, SUM( (TIME_TO_SEC(CAST(end_time AS TIME)) - TIME_TO_SEC(CAST(start_time AS TIME))) / 3600 ) AS total_hours FROM t_booking WHERE booking_date 2025-01-10 GROUP BY gym_id;CAST函数虽然能用但记录量大之后这种转换就是性能瓶颈。如果一开始用datetime承载完整时间信息后面统计会简单得多。我的建议是如果只是做课设varchar方案逻辑简单、演示时不容易出错如果打算真正用起来最好用datetime。这是经过几轮迭代后的真实体会。6.3 前端跨域、时间格式化与日期组件的小问题Vue项目里还有几个踩过的坑。第一个是Element UI的日期组件返回值是Date对象直接传给后端时经JSON序列化后可能变成一串毫秒数字后端参数类型是String就会报错。解决方式是用dayjs或moment在前端格式化成yyyy-MM-dd再传输。import dayjs from dayjs; const dateStr dayjs(this.selectedDate).format(YYYY-MM-DD); // 提交dateStr到后端第二个是Vue Router在同一个路由上重复跳转时会报NavigationDuplicated错误这是Vue Router 3.x的经典问题。解决方法一个是直接升级到4.x另一个是捕获错误不处理router.push(/booking).catch(() {})6.4 排查步骤速查表现象可能原因排查步骤登录后一直返回401Token过期或未传递检查Axios请求拦截器是否携带了Authorization头预约一直提示时间段被占冲突检测SQL过滤了取消记录后仍查出冲突检查预约记录中是否有异常脏数据前端请求接口404接口路径错误或没加/api前缀检查Controller的RequestMapping和前端axios的baseURL数据库连接失败MySQL未启动或serverTimezone配置错误检查application.yml连接参数同一时间段被重复预约唯一索引未创建在t_booking表执行联合唯一索引DDL7. 实操心得与推荐扩展方向7.1 这套系统能用到真实场景吗老实说课设级别的预约系统技术栈没问题但离真正产品化还有距离。真实场馆会有会员卡、押金、计时收费、黑名单、爽约惩罚等机制这些目前都没有涉及。但作为完整全栈项目的练手和答辩作品它的完成度和逻辑闭环已经够了。给几条答辩准备建议讲清楚预约冲突检测的SQL原理这是核心亮点说清楚权限控制的实现方案以及用户、管理员、超级管理员三个角色的层级设计现场演示时先在前台找一个场地走完预约全流程再切到后台演示审核、取消流程整个闭环下来老师基本挑不出刺。7.2 想扩充功能优先级怎么排如果你觉得项目还不够打想继续叠功能我的建议是按梯度来。第一梯度引入Spring Security完善权限体系引入Redis缓存热点场地列表和已预约时段加定时任务自动处理超时未确认的预约记录。第二梯度引入WebSocket做实时通知用户预约成功后管理员实时收到消息加入模拟支付流程场地扫码签到入场。第三梯度把单体拆成微服务、引入消息队列。除非你打算拿这个项目跳槽面试否则不建议为了炫技而过度设计。我个人建议做第二梯度就够了模拟支付和扫码签到这两个功能非常贴合体育馆预约的真实场景实现难度不大但演示效果和答辩加分都明显。最后分享一个小经验课程设计也好毕业设计也好最忌讳的就是拿到代码跑起来就交差。你能把每张表为什么这么设计、每个核心方法为什么这么实现讲清楚这个项目才真正属于你。网上找个模板改个标题的做法面试官一眼就能识破。我做完这套系统后的体会是最大的收获不是跑通了功能而是把“冲突检测”“状态机”“事务边界”这些看似抽象的概念变成了自己手底下实实在在能跑的逻辑。你可以在这个基础上继续扩展但先把现有闭环吃透比什么都强。