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 七张核心表的职责划分

抛开扩展表不谈，核心表我建议按下面这个清单设计，每张表解决一类问题。

这些表之间的关系并不复杂：场馆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 订单状态机：六个状态怎么流转

我建议订单表用整数来表示状态，配合一张状态说明表，方便查询和展示。六个状态如下：

状态机的核心原则是：任何状态之间的跳转都必须有明确的触发条件和操作入口，不能让一条订单同时处于两个状态。比如用户取消时，只有“待支付”和“已支付”状态能走取消流程；取消成功后，如果之前已支付就再进入“已退款”。超时关闭只针对“待支付”状态，已支付的订单不能被定时任务直接关闭，否则会引发支付和订单状态不一致。

4.3 三个核心接口与超时释放

预约系统的接口不必很多，但三个核心接口的逻辑要足够健壮。创建预约接口的核心是原子占位加事务；支付接口的核心是幂等，无论用户点击多少次支付按钮，或者模拟支付回调重复通知，都不能产生多笔有效流水；取消接口的核心是释放资源，不管订单状态改成了什么，最终必须把对应schedule的状态改回OPEN，让其他用户能继续约。

还有一个业务上很现实的问题：用户下单后不付款，场地被一直锁着怎么办。我在实际设计里用了“定时任务扫描+用户主动取消”双通道。定时任务每隔几分钟扫一次，把超过15分钟仍未支付的待支付订单改成超时关闭，并释放对应时间片。同时在用户端允许用户主动取消待支付订单，取消时同样释放时间片。两个通道都做，是因为任何单一机制都可能因为用户忘了关页面而导致座位被无效占用。

5. 我在开发中反复踩过的六个坑

这一部分是我最想写的。网上教程只会告诉你“应该怎么做”，但实际开发中真正让人崩溃的，往往是那些看起来不起眼、却能把整个逻辑带偏的细节。下面六个问题都是我在做类似系统时真实遇到过、也帮人排查过的。

5.1 并发下单时场地“超卖”了

前面提到了count+insert方式的隐患，这里用更实际的场景描述一遍。我最初做第一版时，创建预约的代码是先查schedule状态，再判断是否为空，然后插入订单。用Postman模拟两个请求同时打同一个时间片接口时，两个请求都打印了“当前状态为空闲”，然后都成功创建了订单。那一刻我才意识到，应用层的“先查后写”永远存在竞态窗口，解决问题必须靠数据库的原子操作。

后来改成UPDATE ... WHERE status='OPEN'之后，再并发测试就稳定了。这里给一个排查建议：凡是涉及资源抢占的逻辑，不要相信“我在代码里加了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层开启事务时没问题，一旦把实体直接返回给Controller，Jackson序列化时访问关联属性，就会抛LazyInitializationException。这个问题属于典型的“单测测不出来、联调必现”的坑。

解决方式有几个，我个人推荐在Service层就把实体转换成DTO或VO，不要在Controller里直接返回实体。这样既避免懒加载问题，也防止实体内部结构暴露给前端，还方便在DTO里组装展示字段。养成这个习惯之后，答辩时也能顺带聊聊分层设计，比单纯讲CRUD强得多。

5.6 前后相差8小时的诡异预约时间

这是一个看着玄学、查了半小时才发现的坑。用户在页面上选的18:00，存进数据库变成了10:00，或者反过来查询时全部偏了8小时。问题根源在时区：MySQL连接串没有指定serverTimezone，JVM时区和数据库时区不一致，Timestamp类型在转换时被自动调整了。

我的解决方式是统一三处约定：数据库连接串显式带上serverTimezone=Asia/Shanghai，Java侧全部使用LocalDateTime而不是Date，数据库表字段统一用datetime而不是timestamp。这里不建议用timestamp是因为它内部转换逻辑太容易受时区影响，对预约系统这种需要精确时间段的场景不太友好。

6. 答辩怎么讲：从“系统”到“并发场景下的资源预定引擎”

最后这部分很实在，因为代码写得再好，答辩讲不出来也白搭。我见过不少同学，功能都做完了，但汇报时只会打开页面一个个点，评委看到的只是“这个按钮能跳转”，自然觉得是普通管理系统。你得换一种讲法。

6.1 答辩展示的三层叙事

建议按三层来讲。第一层讲数据库设计，重点讲为什么引入时间片表、为什么把冲突校验前置到排期生成阶段，而不是下单时去扫订单表。第二层讲并发控制，把“两人同时约同一块场地”这个问题抛出来，然后展示唯一索引加原子占位更新的解决方案。第三层讲订单状态机，从待支付到超时关闭、已支付到已完成，把六个状态的流转图画清楚，同时说明超时释放的双通道设计。

演示时也可以准备两个对比场景：第一次演示正常下单；第二次用并发工具模拟两个请求同时抢同一个时间片，展示只有一个能成功。这个演示比任何PPT文字都更有说服力。切记，在论文里写了Redis、消息队列、分布式锁这类技术点，就一定要自己动手实现过，否则评委追问一个细节就可能露馅。如果只在数据库层面做了并发控制，那就诚实地讲数据库方案，这已经很扎实了。

6.2 七周开发节奏与优先级建议

我建议拿七周左右的完整周期来做这个题，每周有明确产出，避免前松后紧。大致节奏如下：

优先级上，先打通“选时间片—下单—支付—核销”这条主干道，再做取消、超时、退款这些分支逻辑，最后还有时间才做统计报表和页面美化。很多同学一开始就折腾前端动画、UI特效，最后发现核心流程还没走通，这是最可惜的。

最后说一点个人体会：这种系统最怕的不是不会写代码，而是拿到题目就闷头建表写Controller。我见过不少同学把所有表建完才开始想业务规则，结果状态没定义清楚，改了三遍代码。如果你看完这篇还是不知道从哪里下手，我的建议是：先打开一个文档，把“用户能做什么、管理员能做什么、订单有几个状态、同一个时间片被抢怎么办”这四个问题各写一段话，写明白了再动手。抓住并发和状态这两条主线，这套系统就会走得稳，答辩时也有话可讲。