1. 为什么每年都有人做预约系统但这个题其实并不简单Spring Boot配体育场馆设施预约系统这个搭配我在毕业设计的选题名单里看了好几年可以说年年有但绝大多数人第一反应都是“不就是增删改查吗”。真到开题答辩、中期检查、最后演示的时候同一个题能分出明显差距有人只演示了页面上点击预约成功评委一问“两个人同时约同一块场地怎么办”就卡壳有人却能把并发控制、状态机、超时释放、支付幂等全部讲清楚答辩变成加分现场。先说结论预约类系统非常适合做毕设因为复杂度刚好卡在“入门之上、工程之下”的位置。你说它难它没有高深的算法你说它容易它又牵扯并发、状态流转、资源竞争和业务规则稍微处理不好就是脏数据。这篇文章我打算把做这类系统的完整思路写一遍从选题定调、功能边界、数据库设计、订单状态机到真实开发中反复踩过的坑再到答辩如何讲出含金量逐个拆开讲透。正在准备毕设的同学应该知道预约系统的套路一旦吃透图书馆座位预约、会议室预约、健身房课程预约本质都是同一套逻辑换个业务名词就能复用。1.1 毕设选型的“性价比”判断复杂度适中、就业导向明确为什么推荐这个题目三个原因。第一技术栈主流且成熟。Spring Boot是这两年企业开发的事实标准配上MySQL、MyBatis或Spring Data JPA网上资料一抓一大把遇到问题搜得到答案不至于卡死在某个冷门技术上。第二业务模型清晰但又不失深度。场馆、场地、时间片、订单、支付、状态流转一层层拆下来既有常规CRUD也有真正需要动脑的并发与状态设计工作量适合一个学期的周期。第三演示效果好。做出来的东西能看、能操作、能讲用户端加管理端界面和功能都直观比某些纯算法题更容易让答辩老师快速理解你做了什么。但这里要提醒一句正因为题目经典答辩老师也见多了这个题所以“能跑”只是及格线。如果你只做到了“用户能预约、管理员能看订单”那大概率就是及格分。拉开差距的点在于你有没有想清楚资源冲突怎么防止、订单状态怎么流转、超时订单怎么处理。这些内容不是页面堆砌出来的而是设计层面的东西必须在动手写代码之前就定下来。1.2 先把三个设计抉择定下来后面才不会返工我做这个类型的系统有一个强烈的体会返工九成不是代码写错而是业务模型没定清楚就开始建表。下面三个问题建议在动手前先回答。第一个问题预约的粒度是什么按“场地”还是按“场次”场地维度指的是用户选择某块场地比如羽毛球3号场的某个时间段进行预约适合散客自由约球场次维度指的是管理员预先排好某些固定时段比如19:00-20:00羽毛球小班课用户抢的是这个场次的名额。体育场馆实际业务中两种都存在但毕设没必要一上来就做混合模式。我建议以“场地时间段”作为核心模型时间片表作为连接场地和订单的枢纽这样最贴近真实场馆运营也最容易把并发的点设计清楚。第二个问题时间片是固定排好的还是下单时动态计算有一个省事的做法是不建时间片表用户下单时传“开始时间结束时间”服务端去订单表里扫一遍有没有冲突。这种方案在小数据量下确实能跑但问题很明显一是热门时段用户同时抢的时候冲突检测会非常频繁二是“判断是否冲突”的逻辑散落在多个接口里很容易写漏。我的建议是引入时间片表让管理员按场馆开放时间和场地类型批量生成未来N天的时间片用户只能从空闲时间片里选。这样做的一个隐藏好处是时间冲突校验被前置到了排期生成阶段下单接口只需要关心“时间片是否空闲”复杂度一下就降下来了。第三个问题单场馆还是多场馆从表结构设计角度我建议从一开始就支持“多场馆—多场地”的层级关系。哪怕你演示的时候只放一个体育馆的数据表结构上也把场馆表、场地表分开。这样写论文时可以说“系统支持多场馆扩展”答辩时也能应对“如果学校有好几个馆怎么处理”的追问。2. 功能边界与业务规则先想清楚“预约什么”再动手功能列表看似简单但很多同学列出十几个模块最后做不完就是因为没有分清“核心链路”和“包装功能”。我通常把功能分成用户端、管理端和三条业务规则先定边界再写代码。2.1 用户端和管理端到底要做哪些事用户端核心功能可以控制在六项左右注册登录、浏览场馆和场地、按日期查询可约时间片、提交预约订单、模拟支付、取消订单。再加一个历史订单列表用于查看预约状态。至于收藏、评论、积分、会员等级这些如果时间和精力允许可以锦上添花但不建议在核心链路还没跑通之前碰它们。管理端包括场馆管理、场地管理、时间片排期管理、订单管理、用户管理。时间片排期是管理端最重要也最容易忽略的功能它决定了系统能不能真正运转起来。如果时间片都是手动一条条插入数据库演示时既难看又容易出错所以一定要做一个“按日期范围场地批量生成时间片”的功能这是管理端的一个小亮点也是后面很多设计的基础。2.2 三条业务规则提前量、订单数上限、最晚取消时间功能定了之后要写明白的是业务规则这些规则会直接影响接口校验逻辑。我见过不少同学建完表直接写接口写到一半发现“这个状态什么时候能取消”“一个人能不能同时占几块场地”这些问题根本没定义代码越写越别扭。建议先定三条规则。第一可提前预约的天数。比如只能预约未来7天内的场地避免排期过远导致运营变动后数据对不上。第二单个用户同时有效的预约单数量。比如最多同时有3个“待支付已支付”状态下的订单防止有人把黄金时段全部占住。这个规则看起来简单但它是防止恶意占位的第一道防线。第三最晚取消时间。比如开球时间前2小时可以免费取消超过这个时间就不能在用户端取消了避免场地资源被临时放鸽子。这三条规则在写代码前用文字列出来数据库校验、接口逻辑、前端提示都有了依据。还有一条容易被忽略的边界场馆的开放时间。比如体育馆营业时间是8:00到22:00那时间片生成、订单校验、前端可选项都必须遵循这个范围否则就会出现凌晨三点有人预约羽毛球场的诡异数据。3. 数据库表结构七张核心表和一条并发“铁律”数据库设计是这种系统最关键的部分没有之一。因为预约系统的根问题是“数据别打架”而数据打架的问题最好在设计表的时候就彻底封死而不是靠代码小心翼翼地绕。3.1 七张核心表的职责划分抛开扩展表不谈核心表我建议按下面这个清单设计每张表解决一类问题。表名核心职责关键字段说明user用户与管理员身份username唯一、password_hash、role(USER/ADMIN)、phonevenue场馆name、location、open_time、close_time、statuscourt场地挂在场馆下venue_id、name、type(羽毛球/篮球/游泳等)、base_price、statusschedule时间片连接场地与订单court_id、date、start_time、end_time、price、status(OPEN/BOOKED/LOCKED)booking_order预约订单order_no唯一、user_id、schedule_id、court_id、date、start_time、end_time、total_price、statuspayment_record支付流水order_id、pay_no、amount、status、paid_atadmin_config业务规则配置rule_key、rule_value用于存可预约天数、订单上限等这些表之间的关系并不复杂场馆1对多场地场地1对多时间片时间片1对1订单订单1对1支付流水。真正需要用心设计的不是关系而是字段层面的约束。3.2 并发铁律把“同一时间片只可被预约一次”压进数据库这是整篇内容里我认为最重要的一段。做预约系统最核心的技术问题就是同一块场地、同一个时间段绝不能出现两个有效订单。很多同学的做法是下单时先查询一下这个时间段有没有订单没有就插入。这在单用户操作时没有任何问题但一遇到并发就露馅两个请求同时查到“空闲”然后同时插入订单超卖就发生了。正确的做法是在数据库层面把它“焊死”。具体有两道防线。第一道防线是唯一索引。schedule表上应该加上(court_id, date, start_time)的唯一约束意思是同一块场地同一天同一个开始时间只能存在一个时间片记录。这是从源头上保证时间片本身不重复。第二道防线是下单时的原子占位。用一条带状态条件的UPDATE语句抢占时间片UPDATE schedule SET status BOOKED WHERE id #{scheduleId} AND status OPEN;如果影响行数为1说明这块场地被你占住了可以继续创建订单如果影响行数为0说明别人已经抢先一步直接提示“该时段已被预约”。这个方案依赖数据库行锁避免了先查询再插入的时间窗口是最直接也最好向评委解释的方案。如果你用的是JPA等ORM框架也可以走乐观锁路线在schedule表上加一个version字段更新时带上版本号条件更新失败就重试或提示。两种方案选一种即可但建议在论文中把两种都写清楚这本身就是很好的答辩素材。3.3 字段细节与三个隐藏约定除了核心字段还有几个必须注意的细节。第一订单表要冗余场地名、场馆名、时间段、价格等信息而不是只存外键。为什么因为如果管理员后续调整了场地名称或者价格历史订单不能被影响而且列表页展示时不需要反复联表查询。第二业务订单号order_no要认真生成比如用日期加随机序列并加上唯一索引。它不只是为了好看也是后续模拟支付、对账时的标识。第三所有时间字段建议统一用datetime类型Java侧用LocalDateTime避免各种时区换算带来的诡异问题这一点后面第五部分会详细展开。还有一个容易被忽视的点schedule表的price虽然是冗余字段但它的值应该从court表的base_price复制过来而不是下单时临时算。因为场馆调价后已经生成的时间片价格不应该跟着飘。这种“快照”思想在订单系统里很常见写论文时值得单独讲一讲。4. 核心流程与六个状态一个预约订单的一生下单不是简单insert一条记录而是一系列状态流转。我建议把订单的生命周期单独作为一个设计重点因为在答辩中状态机是比CRUD高级得多的表达。4.1 从查询到入场的五个步骤一次完整预约流程可以分为五步查询可约时间片、创建预约订单、支付、核销入场、完成。查询阶段只展示状态为OPEN的时间片创建订单时通过上面说的原子占位把schedule改成BOOKED同时生成状态为“待支付”的订单支付成功后把订单改为“已支付”用户到场后由管理员核销或扫码确认订单变为“已完成”。这里有一个设计上的关键点创建订单和锁定时间片必须在同一个事务里完成否则会出现订单创建失败但时间片被锁住的情况。实现上可以这样组织先执行UPDATE占位再insert订单如果订单插入失败则抛异常回滚让UPDATE也回滚时间片自然恢复为OPEN。4.2 订单状态机六个状态怎么流转我建议订单表用整数来表示状态配合一张状态说明表方便查询和展示。六个状态如下状态值状态名含义可流转去向0待支付已锁定时间片但未付款已支付、已取消、超时关闭1已支付用户已付款等待入场已完成、已取消2已完成已被核销行程结束终态3已取消用户主动取消终态4超时关闭系统自动关闭未支付订单终态5已退款已支付订单取消后退款终态状态机的核心原则是任何状态之间的跳转都必须有明确的触发条件和操作入口不能让一条订单同时处于两个状态。比如用户取消时只有“待支付”和“已支付”状态能走取消流程取消成功后如果之前已支付就再进入“已退款”。超时关闭只针对“待支付”状态已支付的订单不能被定时任务直接关闭否则会引发支付和订单状态不一致。4.3 三个核心接口与超时释放预约系统的接口不必很多但三个核心接口的逻辑要足够健壮。创建预约接口的核心是原子占位加事务支付接口的核心是幂等无论用户点击多少次支付按钮或者模拟支付回调重复通知都不能产生多笔有效流水取消接口的核心是释放资源不管订单状态改成了什么最终必须把对应schedule的状态改回OPEN让其他用户能继续约。还有一个业务上很现实的问题用户下单后不付款场地被一直锁着怎么办。我在实际设计里用了“定时任务扫描用户主动取消”双通道。定时任务每隔几分钟扫一次把超过15分钟仍未支付的待支付订单改成超时关闭并释放对应时间片。同时在用户端允许用户主动取消待支付订单取消时同样释放时间片。两个通道都做是因为任何单一机制都可能因为用户忘了关页面而导致座位被无效占用。5. 我在开发中反复踩过的六个坑这一部分是我最想写的。网上教程只会告诉你“应该怎么做”但实际开发中真正让人崩溃的往往是那些看起来不起眼、却能把整个逻辑带偏的细节。下面六个问题都是我在做类似系统时真实遇到过、也帮人排查过的。5.1 并发下单时场地“超卖”了前面提到了countinsert方式的隐患这里用更实际的场景描述一遍。我最初做第一版时创建预约的代码是先查schedule状态再判断是否为空然后插入订单。用Postman模拟两个请求同时打同一个时间片接口时两个请求都打印了“当前状态为空闲”然后都成功创建了订单。那一刻我才意识到应用层的“先查后写”永远存在竞态窗口解决问题必须靠数据库的原子操作。后来改成UPDATE ... WHERE statusOPEN之后再并发测试就稳定了。这里给一个排查建议凡是涉及资源抢占的逻辑不要相信“我在代码里加了if判断”直接用数据库的原子更新或唯一的数据库约束验证然后用并发请求实测别只靠点页面测。5.2 内部自调用让Transactional形同虚设这是一个很经典的Spring Boot陷阱。我在取消订单时写了这样一个结构订单Service里有一个cancel方法内部调用了同类里的releaseSchedule方法而releaseSchedule上加了Transactional注解。测试时发现如果cancel方法本身在事务里调用releaseSchedule的事务还能沾点光但当我单独调用releaseSchedule时事务根本不生效。原因很简单同类内部方法调用不会经过Spring的代理对象注解自然就不起作用。解决办法也很直接把释放场地的逻辑放到另一个Service比如ScheduleService里让订单Service调用ScheduleService的方法。这样事务边界既清晰又有效。这个坑在写论文时其实可以当作一个“踩坑记录”写进去反而显得真实。5.3 时间重叠判断的边界条件如果哪天你决定不按时间片结构做而是下单时动态校验时间段那么“判断时间段是否重叠”就是一个躲不开的逻辑。很多人在这里栽过跟头。正确判断两组时间区间[aStart, aEnd)和[bStart, bEnd)是否重叠的条件是aStart bEnd bStart aEnd。用Java代码写就是public boolean isOverlap(LocalDateTime aStart, LocalDateTime aEnd, LocalDateTime bStart, LocalDateTime bEnd) { return aStart.isBefore(bEnd) bStart.isBefore(aEnd); }重点在于使用半开区间也就是开始时间包含、结束时间不包含。这样14:00-16:00和16:00-18:00两个相邻时间片会返回false不会误判成冲突。很多同学用闭区间思维把条件写成aStart bEnd bStart aEnd结果两个紧挨着的预约被当成冲突调试半天不知道原因。5.4 待支付订单把黄金时段“焊死”这个问题我在联调时才意识到有多恶心。当时为了测试我连续创建了好几个待支付订单把晚高峰的几个时间片全锁住了然后关闭页面不再操作这些时间片就永久处于BOOKED状态其他用户根本约不了。如果不做超时释放整个场馆的可约资源会慢慢被垃圾订单占满。解决方案就是前面说的定时任务加主动取消双通道。实现上我有一个心得定时任务不要扫描所有订单而是只查“状态为待支付且创建时间早于当前时间15分钟”的订单这样即使订单量大了也不会太慢。释放时间片和关闭订单这两个操作同样要在事务里完成。5.5 懒加载异常在联调时才暴露如果用Spring Data JPA做关联查询订单表里的court、venue这些关联对象默认是懒加载的。在Service层开启事务时没问题一旦把实体直接返回给ControllerJackson序列化时访问关联属性就会抛LazyInitializationException。这个问题属于典型的“单测测不出来、联调必现”的坑。解决方式有几个我个人推荐在Service层就把实体转换成DTO或VO不要在Controller里直接返回实体。这样既避免懒加载问题也防止实体内部结构暴露给前端还方便在DTO里组装展示字段。养成这个习惯之后答辩时也能顺带聊聊分层设计比单纯讲CRUD强得多。5.6 前后相差8小时的诡异预约时间这是一个看着玄学、查了半小时才发现的坑。用户在页面上选的18:00存进数据库变成了10:00或者反过来查询时全部偏了8小时。问题根源在时区MySQL连接串没有指定serverTimezoneJVM时区和数据库时区不一致Timestamp类型在转换时被自动调整了。我的解决方式是统一三处约定数据库连接串显式带上serverTimezoneAsia/ShanghaiJava侧全部使用LocalDateTime而不是Date数据库表字段统一用datetime而不是timestamp。这里不建议用timestamp是因为它内部转换逻辑太容易受时区影响对预约系统这种需要精确时间段的场景不太友好。6. 答辩怎么讲从“系统”到“并发场景下的资源预定引擎”最后这部分很实在因为代码写得再好答辩讲不出来也白搭。我见过不少同学功能都做完了但汇报时只会打开页面一个个点评委看到的只是“这个按钮能跳转”自然觉得是普通管理系统。你得换一种讲法。6.1 答辩展示的三层叙事建议按三层来讲。第一层讲数据库设计重点讲为什么引入时间片表、为什么把冲突校验前置到排期生成阶段而不是下单时去扫订单表。第二层讲并发控制把“两人同时约同一块场地”这个问题抛出来然后展示唯一索引加原子占位更新的解决方案。第三层讲订单状态机从待支付到超时关闭、已支付到已完成把六个状态的流转图画清楚同时说明超时释放的双通道设计。演示时也可以准备两个对比场景第一次演示正常下单第二次用并发工具模拟两个请求同时抢同一个时间片展示只有一个能成功。这个演示比任何PPT文字都更有说服力。切记在论文里写了Redis、消息队列、分布式锁这类技术点就一定要自己动手实现过否则评委追问一个细节就可能露馅。如果只在数据库层面做了并发控制那就诚实地讲数据库方案这已经很扎实了。6.2 七周开发节奏与优先级建议我建议拿七周左右的完整周期来做这个题每周有明确产出避免前松后紧。大致节奏如下周次任务关键产出第1周需求分析 数据库设计 页面草图文档、ER图、表结构第2周Spring Boot工程搭建 用户场馆基础CRUD可用工程、完成登录第3周时间片生成 预约下单主链路从选时间到生成订单第4周订单状态机 模拟支付 超时任务状态流转完整第5周管理端页面 前端联调前后端跑通第6周并发测试 边界修复并发过测、修复八小时时区等问题第7周写论文 准备演示 模拟答辩管理端展示不花哨核心链路流畅优先级上先打通“选时间片—下单—支付—核销”这条主干道再做取消、超时、退款这些分支逻辑最后还有时间才做统计报表和页面美化。很多同学一开始就折腾前端动画、UI特效最后发现核心流程还没走通这是最可惜的。最后说一点个人体会这种系统最怕的不是不会写代码而是拿到题目就闷头建表写Controller。我见过不少同学把所有表建完才开始想业务规则结果状态没定义清楚改了三遍代码。如果你看完这篇还是不知道从哪里下手我的建议是先打开一个文档把“用户能做什么、管理员能做什么、订单有几个状态、同一个时间片被抢怎么办”这四个问题各写一段话写明白了再动手。抓住并发和状态这两条主线这套系统就会走得稳答辩时也有话可讲。