Spring Boot体育中心预约系统：从数据库设计到部署全解析

“计算机毕业设计springboot体育中心预约系统的设计与实现”——你光看这题目就知道，这已经是这几届毕设题库里的“常青树”了，基本每个学校都能碰到几个选这个方向的。选它的同学通常都是冲着一点去的：Spring Boot是现在企业里最主流的后端框架，做好了既能应付答辩，又能往简历上写一手。但正因为太多人选，如果你只是机械地做一套普通CRUD，导师大概率问几句就没了兴趣，答辩现场也会很被动。

这篇内容我就是奔着“能直接落地”来写的。我会把你看到的这个标题拆开揉碎，讲清楚体育中心预约和普通的管理系统到底差在哪、核心难点是什么、数据库怎么设计、并发冲突怎么处理、权限和接口怎么接，再把部署过程和踩过的坑一并交代清楚。无论你是准备开题、已经写了一半代码，还是打算换技术方向临时补一个项目，这篇都能给你一条相对完整的参考路径。

我默认你的技术背景是：Java SE基本OK，Spring Boot刚上手，MySQL会写基本SQL，前端要么用Vue脚手架，要么用现成模板。如果这些还不太熟也没关系，遇到关键点我会把原理顺带讲明白。

1. 拿到题目先别急着写代码：把“预约”拆成一张业务地图

1.1 三个标题变体，其实讲的是同一套业务底盘

我经常看到一类情况：同学把自己毕设题目复制到搜索引擎，出来的结果一会叫“预约系统”，一会叫“智能化管理平台”，一会又叫“资源调度与服务系统”，瞬间感觉迷茫了。这里我先帮你拨一下云雾：题目里这些措辞，并不是三个不同的系统，而是同一个系统从不同角度起的名字。

我们把核心业务拉出来看：

• 预约系统：强调用户行为，也就是用户在线上完成“选场馆→选场地→选时间→提交预约”这条主链路。
• 智能化管理平台：强调管理员视角，侧重点在后台维护场馆、场地、价格、公告、订单、数据统计等运营管理能力，加上一些“智能化”的辅助决策，比如自动展示可预约时段、自动判断场次冲突、按时释放无人预约的资源。
• 资源调度与服务系统：强调后端对“资源”的分配能力。这里的资源就是“某个场馆里的某个场地在某一段时间”，系统要保证同一个资源在同一个时间段内不会被重复预约，同时要处理订单超时、取消后资源如何释放回可预约池。

说白了，这三句话加在一起才算一个完整的毕设系统。如果你只做“预约下单”，后台连场馆信息都是写死的，那你的系统约等于一个能用表单的玩具，谈不上“管理平台”；如果你只做“后台增删改查”，没有用户侧预约流程，那它就和几十年前的进销存系统没有区别。

所以第一步要形成闭环思维：用户能约，管理员能管，场地有状态，订单有生命周期，资源有释放机制。这套闭环，就是你答辩时回答“你这个系统有什么亮点”的底层逻辑。

1.2 角色与用例边界：守得住范围才叫好毕设

很多同学一开始就想做全，什么支付、优惠券、短信通知、地图选场馆，统统想塞进去。我劝你冷静。毕设周期有限，做得多不如做得稳，把基本盘打扎实，让每个模块能自圆其说，比堆砌半成品功能要好得多。

以这个题目为例，核心角色就三类：

如果你是新手，可以去掉“场馆前台”，把这个功能合并给管理员；如果你想让项目显得有层次，加这个角色也不难，本质上就是多一张角色关联表。

不要做的部分也明确一下：第三方支付、优惠券系统、复杂消息推送，不建议作为核心模块。你可以把“模拟支付”做成一个点击按钮，订单状态直接从“待支付”变为“已确认”，并在文档里说明“生产环境可对接微信/支付宝支付”。导师完全可以接受这种边界划分，关键是你把边界说清楚。

1.3 核心业务流程：把整个预约流程走通

我来画一条文字版的完整链路，你可以直接用这段描述去写开题报告或者“可行性分析”：

用户注册并登录系统 → 在首页查看体育中心场馆列表 → 进入某个场馆详情页 → 查看该场馆下不同场地（如羽毛球1号场、2号场） → 选择日期并查看当天可预约时段 → 选定时段点击预约 → 系统校验该时段是否仍可预约（后台需要做冲突判断） → 生成订单，状态为“待支付”或直接“已预约” → 用户在“我的预约”中查看订单详情 → 到线下场馆后由管理员进行核销，订单变为“已完成” → 如果在预约开始前不需要了，用户可以取消预约，对应的时段自动释放回可预约池 → 管理员在后台可以按日期/场馆/场地查看预约记录，进行管理。

中间容易出彩的三个技术点，也就是我在后面要重点展开的：“时段如何表达”“预约冲突如何避免”“订单取消/超时后资源如何释放”。这三个点如果能讲清楚并在代码里正确实现，你的项目已经超越了大部分“伪管理系统”。

2. Spring Boot选型与依赖搭配

2.1 为什么毕设圈几乎默认把后端交给Spring Boot

要回答这个问题，得先知道没有Spring Boot之前，用Spring写Web项目是什么体验。

你需要在项目里手动引入Spring MVC、MyBatis、Druid连接池等一大堆依赖，还要维护一个非常繁琐的XML配置文件，描述组件扫描范围、数据源、事务管理器、视图解析器。每引入一个新功能，就得在XML里加一段配置。很多人配着配着就报Bean创建异常了，人都麻了。

Spring Boot最大的贡献不是发明了新框架，而是把“搭环境”这件事浓缩成了“选依赖”。它采用“约定优于配置”的思想，通过自动配置机制完成框架的默认组装：

• spring-boot-starter-web帮你把Spring MVC、内嵌Tomcat、Jackson序列化等全部打包好；
• 启动类上的@SpringBootApplication组合了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan，其中@EnableAutoConfiguration会读取自动配置类，根据你classpath里的依赖决定要不要启用对应的配置；
• 你只需要在application.yml里写自己最关心的配置项，比如端口、数据库连接、日志级别，其余全部走默认值。

从实用性上讲，Spring Boot把“让一个新手快速写出能跑的Web项目”的门槛拉低了很多。所以毕设不用Spring Boot，反而更奇怪。这不仅是技术原因，还有生态和文档的因素：你遇到任何问题，搜索引擎上几乎都能找到对应答案。

2.2 Spring Boot 2.7.18和3.x到底怎么选

这是开头最容易踩坑的问题。

我必须直言：如果你是在校学生，电脑上装的JDK是1.8，学校教学也以JDK8为主，那我建议你选 Spring Boot 2.7.18。它是2.x版本里最后一个维护版本，也是“毕设首选版本”。为什么这么说？

第一，Spring Boot 2.7.x基于JDK8编译，使用javax.servlet包下的API，网上大部分老教程、博客都是围绕这个版本写的，你搜代码示例基本都能直接贴。

第二，Spring Boot 3.0从2022年11月开始发布，它是基于JDK17的，包名从javax.*迁移到了jakarta.*。如果你不熟悉这个区别，跟着网上旧教程写，往往会出现“导入包导入不了”或者“tomcat无法启动”的问题，很多新手会在这里白白耗掉一整天。

不过如果你本身已经装了JDK17，或者是老师指定要新版本，那选Spring Boot 3.x当然没问题。它性能和长期支持更好，后续转工作也更贴合当前行业使用情况。只要记住一点：选3.x就必须把JDK升级到17+，不能拿JDK8硬跑3.x。

我把决策标准整理成一个简单的版本选择表：

另一个与版本强相关的点是循环依赖。Spring Boot 2.6以前，Spring容器默认允许循环依赖，比如A类注入B类，B类又注入A类，代码能凑合运行。但从Spring Boot 2.6开始，官方默认禁止了循环依赖，启动时直接报错。很多同学在网上找老项目参考时把老代码搬过来，一跑就出现Relying upon circular references is discouraged，这个就是版本差异引起的。解决方法最好是重构设计，把互相依赖抽出来，不要一上来就想着改配置放行。

2.3 依赖清单：按模块使用场景配齐

如果你是新建项目，我推荐一个“稳妥组合”，照着选就行：

• spring-boot-starter-web：必选，提供Web MVC、内嵌Tomcat、JSON处理等核心能力。
• spring-boot-starter-validation：必选，用于接口参数校验，比如手机号格式、非空判断等，省得自己写一堆if。
• mybatis-plus-boot-starter：持久层框架首选。MyBatis-Plus在MyBatis的基础上提供了单表CRUD方法，不用写XML就能完成大部分常规操作，对毕设来说极其友善。
• mysql-connector-j：MySQL驱动，没有它应用连不上数据库。
• lombok：减少实体类getter/setter代码。使用前记得在IDEA里安装Lombok插件并开启Annotation Processing。
• spring-boot-starter-security：做登录认证和权限管理。如果实在觉得复杂，可以先用拦截器+JWT实现自定义认证，但Spring Security在答辩时会更显得有技术含量。
• jjwt：生成和解析JWT令牌，用于无状态登录态校验。
• knife4j-openapi2-jakarta-spring-boot-starter（根据Boot版本对应选择）：接口文档工具。用Knife4j替代原生Swagger UI的主要原因有二：一是UI更美观，二是它原生支持导出离线文档，写论文时能直接贴接口文档截图。
• spring-boot-starter-data-redis：可选，用于缓存热门场馆信息、做分布式锁、存储临时验证码。不熟悉Redis的同学可以先不引入，把核心业务做完后再加。

注意：依赖不是越多越好，每多加一个依赖就多一份配置和兼容性负担。比如你项目中如果没有使用消息队列的需求，就不要先引入RocketMQ或Kafka，否则服务启动时连nameserver或broker，直接报错，处理起来费时又打击心态。

3. 项目骨架搭建与目录结构设计

3.1 IDEA从零创建Spring Boot工程

如果你用的是IDEA，创建流程很简单：

1. 打开IDEA界面，选择“New Project”。
2. 左侧选择“Spring Initializr”。如果你的IDEA版本连不上Spring Initializr服务，可以手动到 https://start.spring.io 下载压缩包，再导入IDEA，选择Maven项目即可。
3. 填写Group（一般写公司域名倒过来的格式，比如com.example）、Artifact（项目名，比如stadium-booking）。
4. Java/Type选择Java 8，Packaging选择Jar（很多同学想打包war放到Tomcat里，其实没必要，Spring Boot自带Tomcat，直接跑Jar就行）。
5. 右侧依赖里先添加Spring Web、Validation、MySQL Driver、Lombok，创建后再手动往pom.xml里补MyBatis-Plus和JWT相关依赖。

这里我强烈建议：不要用内嵌的H2数据库代替MySQL去“偷懒”。虽然H2不需要安装、开箱即用，但它是内存数据库，数据一重启就丢；而且毕业设计答辩时，老师几乎必问“为什么用H2不用MySQL”，你答不好反而减分。老老实实装一个MySQL 5.7或8.0，把数据库独立安装好，是基本操作。

创建完成后，快速验证的第一步不是写业务代码，而是先启动空项目，确认端口能起来，浏览器访问 http://localhost:8080/ 至少要出现错误页而不是连接失败。能启动，说明骨架没问题了。

3.2 application.yml里的关键配置说明

很多同学的配置是从网上一大段复制粘贴的，自己根本不知道每一行的作用，这导致了后期问题排查很痛苦。我来拆解一下最核心的配置：

yaml复制server:
  port: 8080

spring:
  application:
    name: stadium-booking
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/stadium_booking?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 你的密码
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

这里每一行都值得说：

• serverTimezone=Asia/Shanghai：如果不设置，JDBC会默认使用服务器的时区，国内服务器如果时区不对，查出来的时间会比实际少8小时或者直接报The server time zone value is unrecognized。在参数里显式指定是最省事的方案。
• useSSL=false：本地开发不需要启用SSL证书校验，设为false避免连接警告和额外的加密开销。
• map-underscore-to-camel-case：把数据库的create_time自动映射成Java实体类里的createTime，省去大量手写映射代码。
• logic-delete-field: deleted：开启MyBatis-Plus的逻辑删除，这样执行删除操作时，代码会生成update ... set deleted=1而不是物理删除。虚拟数据能保留，复查时也方便。
• StdOutImpl：开发时开启SQL日志打印，你能在控制台看到MyBatis-Plus执行的每一条SQL，排查数据问题非常有用。项目上线前关掉或改成只打印需要关注的日志级别即可。

顺带说一句，一些同学把配置写在application.properties里觉得也挺好，但我个人偏向用YAML。YAML的层级和缩进清晰，复杂的列表结构比properties用一堆中括号和逗号优雅得多。不过两种方式等效，不需要纠结。

3.3 分层结构设计：别把所有代码堆在一个类里

我见过不少同学的Service层，在Controller里疯狂写业务逻辑，数据库操作直接写在方法里，几百行代码挤在一个Controller中。这种项目能跑，但答辩时老师问“你这个分层是怎么设计的”，你就很难回答了。

我建议按常见的分层模式组织代码，结构清晰且好解释：

code复制com.example.stadiumbooking
├── common          // 通用类
│   ├── Result.java         // 统一返回体
│   └── ResultCode.java     // 统一状态码枚举
├── config          // 配置类
│   ├── MybatisPlusConfig.java
│   ├── SecurityConfig.java
│   └── WebMvcConfig.java
├── controller      // 控制层，接收请求和返回结果
├── entity          // 数据库实体对象，对应每张表
├── mapper          // 数据库操作接口（MyBatis-Plus的Mapper）
├── service         // 业务逻辑层接口
│   └── impl         // 业务逻辑实现类
├── dto             // 数据传输对象：接收前端参数、返回给前端参数
├── exception       // 自定义异常处理
├── utils           // 工具类，如JWT工具类、日期工具类
└── StadiumBookingApplication.java

为什么要单独设一个dto包？因为如果你的实体类直接暴露给前端，数据库里的字段就是前端必传参数，这会带来安全问题和字段泄露问题。比如user表里有密码字段password，你返给前端时如果不做脱敏，就会直接暴露到浏览器网络面板里，这是最低级的失误。

3.4 统一返回体与全局异常处理

接口设计要有一个规范，不能有的地方返回Map，有的地方直接返回一个字符串，有的地方抛出异常就看Tomcat默认错误页。你的前端和后端是分离的，最好用一套统一的结果模型。

一个简单的Result<T>结构如下：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("success");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(Integer code, String message) {
        Result<T> result = new Result<>();
        result.setCode(code);
        result.setMessage(message);
        return result;
    }
}

在Controller里，所有成功返回的值都用Result.success(...)包一层，所有异常交由@RestControllerAdvice捕获并转成Result.error(...)。这样前端拿到数据后先判断code是否为200，再决定是否渲染数据，逻辑非常统一。这也是企业开发中最常规的一种做法，写在论文里也算一个“你考虑过工程化设计”的点。

4. 数据库建模：体育中心预约系统最值钱的部分

4.1 八张核心表，怎么把场馆、场地和时段串起来

毕设里最容易被导师盯上的，不是代码写得多少人看不懂，而是数据库设计。体育中心预约系统最少要包含下面这几张表，我按关键程度排序：

为什么要有venue场馆表和venue_field场地表两张表，而不是直接建一个“羽毛球场”表？因为现实中一个体育中心有多个场馆，每个场馆里又有多个场地；如果不做父子分类，未来做“按场馆过滤”“按运动类型搜索”“统计每个场馆的营收”这类功能会非常别扭。两张表通过venue_id关联，逻辑上是一对多。

如果你愿意再加一层“区域”的概念，比如中心里分为羽毛球馆、篮球馆，每个馆里又有若干场地，那就在场馆表和场地表之间加一张venue_area省去冗余。不是必须，看业务范围。

4.2 “场地 + 开始时间 + 结束时间”如何确定一个可预约资源

预约系统的本质，就是为一个确切的“时间切片”匹配一个实体资源。我做这个项目时踩过不少坑，比如一开始天真地设计成：用户在预约时自己填写“开始时间”和“结束时间”，系统只检查这两个时间点之间有没有重叠的订单。

这种方式写起来简单，但会带来很多边角问题：

1. 用户可能选择凌晨3点到4点这种不合理时间；
2. 用户选择“18:00-19:00”，与别人“18:30-19:30”是否算冲突？判断逻辑容易写得模棱两可；
3. 场地实际开放是有固定时间档的，每个档位可能有不同价格，比如工作日白天和晚上价格不同。靠用户自由填写，价格不好计算。

所以更稳妥的做法是引入“时段模板表”time_slot。以羽毛球场为例，管理员预设每块场地可预约的时段，固定为08:00-10:00、10:00-12:00、14:00-16:00、16:00-18:00、18:00-20:00、20:00-22:00六个时段。用户预约时不需要自己输入起止时间，只需要选择“2025-06-01 + 羽毛球1号场 + 18:00-20:00这个时段”，数据模型天然就是一个固定资源。

有人会问，那如果我想让用户随意自定义时长怎么办？那就要设计另一个动态排片方案，把“预约日期+场地+开始时间+结束时间”作为一个整体判断，同时在代码里做时间重叠查询。对毕业设计题目里的“体育中心场馆”来说，固定时段更符合实际线下场馆的经营习惯，也更方便做场次控制和管理。开发成本上，我强烈建议你选择固定时段模板。

这里给一个核心的场地预约明细表简化示例（在真实项目里，我建议直接把预约信息落到订单表，订单表里冗余保存场地和时段的快照字段，避免联表过多）：

sql复制CREATE TABLE booking_order (
    id            BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_no      VARCHAR(64) NOT NULL COMMENT '订单编号',
    user_id       BIGINT NOT NULL COMMENT '预约用户ID',
    field_id      BIGINT NOT NULL COMMENT '场地ID',
    slot_id       BIGINT NOT NULL COMMENT '时段ID',
    booking_date  DATE NOT NULL COMMENT '预约日期',
    start_time    VARCHAR(10) NOT NULL COMMENT '开始时间冗余字段，如18:00',
    end_time      VARCHAR(10) NOT NULL COMMENT '结束时间冗余字段，如20:00',
    amount        DECIMAL(10,2) NOT NULL COMMENT '订单金额',
    status        TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已确认 2已取消 3已完成 4已过期',
    real_name     VARCHAR(50) COMMENT '联系人姓名快照',
    phone         VARCHAR(20) COMMENT '联系电话快照',
    remark        VARCHAR(255) COMMENT '备注',
    deleted       TINYINT NOT NULL DEFAULT 0,
    create_time   DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_time   DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    KEY idx_user_id (user_id),
    KEY idx_field_date_slot (field_id, booking_date, slot_id),
    KEY idx_status (status)
) COMMENT='预约订单表';

这个表里的start_time、end_time是冗余字段。就算时段模板表改了名称，你的订单历史记录依然保留着预约当时的起止时间，这对后续做对账和展示历史订单非常友好。索引方面，idx_field_date_slot这个联合索引很关键，它是执行预约冲突查询时最重要的索引。

4.3 唯一索引：防重复预约的最后一道锁

刚才提到，冲突判断的判断逻辑基本是：查一下booking_order里有没有fieldId + bookingDate + slotId相同的记录，并且该记录状态不是“已取消”和“已过期”。

但这存在一个小小的并发窗口：如果两个请求同时在查询，发现都没有记录，然后同时插入，就可能发生重复预约。即使你的接口在单机上出现概率不高，但这是逻辑漏洞，答辩时老师会追问。要彻底兜底，最好是设计一个唯一约束。

在体育场馆预约场景中，“某天某场地的某时段只能存在一个有效订单”是一个典型业务规则，恰好适合用唯一索引限制。但问题在于订单还有取消状态，如果取消后用户重新预约，旧记录还在，同一个field_id + booking_date + slot_id会残留多条。所以这里不能直接把三者加唯一索引。

实际处理方案有两类：

1. 在订单表里增加一个“预约资源唯一键”字段resource_key，值格式类似fieldId_date_slotId。当订单状态为已取消或已过期时，把这个字段置为NULL（因为MySQL唯一索引允许多个NULL），有效订单则该字段非空且唯一，从数据库层面阻止并发重复。但要注意，这样需要业务代码在取消时额外执行一次更新resource_key = null的操作。
2. 不依靠唯一约束，单纯依靠事务内的SELECT ... FOR UPDATE悲观锁来控制。查一次，锁定对应的场地时段记录，在事务提交前，其他请求必须等待。虽然在极端高并发下吞吐量不高，但对毕设业务量完全够用。

我建议用第二种方案并配合业务状态校验，理由也很简单：更容易理解和演示。在代码中，给booking_order加唯一索引会涉及“取消后置NULL”的额外动作，逻辑反而更复杂，容易把自己绕进去。先把悲观锁方案讲明白，已经能体现你对并发问题的思考。

4.4 订单状态机：从待支付到已完成的流转

订单状态不要在数据库里用字符串随机存，最好用整数状态加一个统一状态解释。推荐这样一组：

为了不写死在各种业务代码里，我把常量维护在枚举或者常量类里：

java复制public interface OrderStatus {
    int PENDING_PAYMENT = 0;
    int CONFIRMED = 1;
    int CANCELED = 2;
    int FINISHED = 3;
    int EXPIRED = 4;
}

状态流转必须做合法性检查。比如用户点击“取消预约”，只有状态是“已确认”的订单才能被取消，如果订单已经“已完成”就不能再允许取消；同理“待支付”订单在支付时如果发现状态已经变为“过期”，要提示用户重新下单而不是把过期单改为已确认。

4.5 场地状态：可预约、维护中、已禁用

你可能还会遇到一个问题：某块场地今天要维修，它是不是也要在当天从可预约列表里消失？我用一张venue_field表是不足以表达“某天某时段不可约”的。

所以在做场馆管理的时候，我更建议增加一张“场地不可预约时段表”或者叫“闭馆设置表”。但这是否会扩张项目规模？

对毕设来说，建议先把场地设计一个整体状态字段status，字段值为0表示正常可用，1表示停用。管理员可以手动把某天某块场地“禁用预约”。如果还想要更细粒度的“仅某天某时段不可约”，可以在场地表基础上再加一个field_blocked_slot，表结构为id, field_id, block_date, slot_id, reason。这个功能是实现“资源调度”概念的点睛之笔，论文里也容易写亮点。但如果时间紧，可以先不做，不影响核心逻辑。

5. 核心实现：预约、冲突检测与资源释放

5.1 预约提交的接口设计，把每一步串起来

下面给出一个参考实现流程，不贴所有代码，但每一步的逻辑顺序你要捋清楚：

1. 前端参数传入：fieldId（场地ID）、bookingDate（预约日期）、slotId（时段ID）。
2. 后端先做基础校验：用户是否登录、场地是否存在且状态为0、时段是否属于该场地对应场馆、预约日期不能早于今天。
3. 检查业务冲突：通过booking_order表，在事务里使用悲观锁或带条件的插入方式，找到这个时段是否已存在“待支付/已确认”的订单。如果存在，直接返回“该时段已被预约”。
4. 计算价格：查询场地小时价格和该时段时长，得出订单金额。如果是固定两小时时段，价格就是场地单价乘以2；如果不同时段价格不同，还要结合时段模板表里的price_rate。
5. 生成唯一的orderNo。建议用时间戳加随机数或者结合Redis自增，比如yyyymMMddHHmmss + 4位随机数，避免订单号重复被人吐槽。
6. 插入订单记录，状态为“待支付”（如果选择不需要支付的模式，就直接置为“已确认”）。
7. 返回订单号给前端，前端跳到“我的预约”页。

这里有一个非常容易被忽略的点：在检查冲突之后、插入订单之前，代码路径应该在一个事务里执行，且事务隔离级别要能防止“伪冲突”。

5.2 用代码怎么处理并发冲突：事务 + 悲观锁示例

我在实际写的时候，Service层核心方法大致是这样的：

java复制@Transactional(rollbackFor = Exception.class)
public BookingOrder createBooking(Long userId, BookingCreateDTO dto) {
    // 1. 基础数据校验
    VenueField field = venueFieldMapper.selectById(dto.getFieldId());
    if (field == null || field.getStatus() != 0) {
        throw new BizException("场地不存在或已停用");
    }

    // 2. 这里先锁定场地的预约状态行，防止并发插入
    //    使用 fieldLockMapper 锁住 venue_field 表中的该场地行
    VenueField lockedField = venueFieldMapper.selectByIdForUpdate(dto.getFieldId());

    // 3. 查这个时段是否已有人预约（有效状态：0待支付,1已确认）
    QueryWrapper<BookingOrder> wrapper = new QueryWrapper<>();
    wrapper.eq("field_id", dto.getFieldId())
           .eq("booking_date", dto.getBookingDate())
           .eq("slot_id", dto.getSlotId())
           .in("status", Arrays.asList(0, 1));
    Long count = bookingOrderMapper.selectCount(wrapper);
    if (count > 0) {
        throw new BizException("该时段已被预约，请选择其他时段");
    }

    // 4. 生成订单并插入
    BookingOrder order = new BookingOrder();
    order.setOrderNo(generateOrderNo());
    order.setUserId(userId);
    order.setFieldId(dto.getFieldId());
    order.setSlotId(dto.getSlotId());
    order.setBookingDate(dto.getBookingDate());
    order.setStatus(OrderStatus.PENDING_PAYMENT);
    order.setAmount(calculateAmount(field, dto.getSlotId()));
    bookingOrderMapper.insert(order);
    return order;
}

其中selectByIdForUpdate就是使用SELECT ... FOR UPDATE在数据库行级别加了悲观锁。只要同一时间有两个请求想预约同一块场地同一时段，它们都会先尝试锁住这一行，第二个请求必须等第一个请求提交事务后才会继续执行，这样它再去查订单数量时，第一个订单已经提交，就会直接被拦截。

这里还有一个事务细节：@Transactional只对RuntimeException和指定异常回滚。如果你在业务里捕获异常后进行了吞掉，那事务可能不会回滚。所以建议在Service里不要到处try-catch，而是把校验异常直接向上抛，由全局异常处理器统一处理。这样代码整洁，事务边界也清晰。

5.3 取消预约与释放资源：把“已确认”状态改掉没那么简单

用户取消订单的业务，看起来不过是执行一次Update，把状态从1改成2。但如果你只改状态，不处理其他数据，可能留下两种后遗症：

1. 其他用户看不到这个释放出来的时段，因为可预约列表中该时段仍被判定为“有有效订单”。
2. 管理员在统计当日预约数量时，会把这个取消单也算进去，导致数据不一致。

所以取消逻辑要三步走：

• 校验订单归属：只能取消自己名下的订单。
• 校验订单状态：只有CONFIRMED状态可以取消，已完成和历史订单不允许操作。
• 修改订单状态为CANCELED并记录取消时间或原因，同时，如果业务设计中有“资源库存表”或“可预约时段状态表”，要把该资源状态恢复为可约。

因为我们的订单表本身承担了锁定资源的功能，所以只要状态改为已取消，后续的冲突查询就把它过滤掉了，资源自然释放。代码执行不需要额外“释放”动作，但为了数据便于追溯，建议在更新语句里加上“只更新状态为1的记录”这个条件。

java复制@Transactional(rollbackFor = Exception.class)
public void cancelOrder(Long userId, Long orderId) {
    LambdaUpdateWrapper<BookingOrder> updateWrapper = new LambdaUpdateWrapper<>();
    updateWrapper.eq(BookingOrder::getId, orderId)
                 .eq(BookingOrder::getUserId, userId)
                 .eq(BookingOrder::getStatus, OrderStatus.CONFIRMED)
                 .set(BookingOrder::getStatus, OrderStatus.CANCELED)
                 .set(BookingOrder::getCancelTime, LocalDateTime.now());
    int rows = bookingOrderMapper.update(null, updateWrapper);
    if (rows == 0) {
        throw new BizException("订单不存在或当前状态不允许取消");
    }
}

5.4 超时未支付订单怎么处理：定时任务轮询是最省心的方案

如果订单状态有“待支付”，那你必须处理一种“僵尸单”：用户提交订单后一直不点模拟支付，这个场地时段就被“锁定”了，其他用户看着页面认为不可约，但实际上这个用户根本不会来。

我的做法是引入Spring自带的@Scheduled定时任务，每隔几分钟扫描一次待支付订单，如果创建时间超出某个阈值（比如15分钟），就把状态改为“已过期”，这会自动释放资源。

示例逻辑如下：

java复制@Component
public class OrderExpireTask {

    @Scheduled(fixedDelay = 60000) // 每60秒扫描一次
    public void expirePendingOrders() {
        LocalDateTime expireTime = LocalDateTime.now().minusMinutes(15);
        LambdaUpdateWrapper<BookingOrder> wrapper = new LambdaUpdateWrapper<>();
        wrapper.eq(BookingOrder::getStatus, OrderStatus.PENDING_PAYMENT)
               .lt(BookingOrder::getCreateTime, expireTime)
               .set(BookingOrder::getStatus, OrderStatus.EXPIRED);
        bookingOrderMapper.update(null, wrapper);
    }
}

使用定时任务时你必须在启动类或配置类上加@EnableScheduling注解。需要注意单机版定时任务跑在哪个节点上？如果你以后部署到多台服务器，同一个定时任务会产生重复执行的问题。毕设阶段单机部署完全没问题，但如果要把这个方案写到论文里，可以提一句“生产环境会使用分布式任务调度平台如XXL-JOB或使用消息队列延迟消息解决”。只要你把这个边界说出来，导师反而觉得你想得周全。

如果你的项目引入了RocketMQ，也可以用它的延迟消息来写“超时关单”，但这不是一个必须项。对大多数人而言，定时任务的解决方案更好理解，代码量也更少，跑起来稳定，已经是毕业设计中的上乘之选。真正分布式场景下，再去考虑更复杂的组件。

5.5 查询“可约列表”的推荐SQL思路

前端首页或场地详情页需要展示：选定某天后，某个场地在哪些时段是可预约的。很多新手会先查时间段模板表，再遍历每一种时段查一次是否被占用，造成N+1查询问题。

更好的做法是一次查出所有可约状态。方式也比较简单：查所有时段模板，同时查出该场地当天所有有效订单，两张数据在Java里做一轮合并匹配，将已占用时段标记为不可约。查询订单时只查一次：

java复制// 查询某天某场地的所有有效预约
QueryWrapper<BookingOrder> wrapper = new QueryWrapper<>();
wrapper.eq("field_id", fieldId)
       .eq("booking_date", date)
       .in("status", Arrays.asList(0, 1));
List<BookingOrder> orders = bookingOrderMapper.selectList(wrapper);

然后把这批订单对应的slotId收集到Set中，在时段模板循环渲染时，如果slotId在Set里就置灰不可点击。这种写法不容易出错，而且对数据库的压力小得多，也方便随后扩展到多场地对比的场景。

6. 登录鉴权与用户端接口设计

6.1 Spring Security + JWT这套组合怎么用

一开始我提过，登录模块使用Spring Security + JWT，也是项目里比较容易被导师和高年级同学追问的点。很多同学一说Security就害怕，觉得复杂。我先打破这个迷思：你不必完全精通Security内部的过滤器链，只需要掌握它的核心扩展点即可。

整体认证流程是：

1. 用户提交用户名和密码。
2. 后端调用AuthenticationManager.authenticate()进行认证，实际会委托给UserDetailsService加载用户信息，并用PasswordEncoder比对密码。
3. 认证成功后，用用户信息生成JWT字符串并返回给前端。
4. 前端之后每次请求都带上Authorization: Bearer <jwt>头。
5. 后端配置一个JwtAuthenticationFilter，在Spring Security过滤器链中解析JWT，校验通过后把用户信息放入SecurityContext。

在Spring Boot 2.x里，你需要自己定义一个过滤器并注册到Security过滤器链的addFilterBefore，在Spring Boot 3.x里逻辑相近，但要使用SecurityFilterChain的lambda写法。下面给一个核心的SecurityConfig片段：

java复制@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .authorizeRequests()
            .antMatchers("/api/auth/login", "/api/auth/register",
                         "/doc.html", "/webjars/**", "/swagger-resources/**", "/v2/api-docs", "/v3/api-docs", "/**.html", "/favicon.ico").permitAll()
            .antMatchers(HttpMethod.GET, "/api/venue/**", "/api/field/**", "/api/announcement/**").permitAll()
            .anyRequest().authenticated();

        // 加入JWT过滤器
        http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class);
        return http.build();
    }
}

注意，把登录注册和查看场馆信息URL放行是必要的；而预约、取消、签到、后台管理等接口必须要求登录态。不然整个系统所有接口裸奔，那认证模块形同虚设。

6.2 JWT里放什么信息，不放什么信息

我看到很多新手有一个坏习惯：把用户密码、手机号、甚至身份证都塞进JWT负载里。这是非常不安全的。JWT默认只做Base64URL编码，并未加密，任何人都可以解码看到内容。你应该只放必要字段，一般情况下放userId和username就够了。

java复制String token = Jwts.builder()
        .setSubject(String.valueOf(user.getId()))
        .claim("username", user.getUsername())
        .claim("role", user.getRole())
        .setIssuedAt(new Date())
        .setExpiration(new Date(System.currentTimeMillis() + 86400000)) // 24小时
        .signWith(SignatureAlgorithm.HS256, secretKey)
        .compact();

解析时直接取出userId，后续业务用这个ID查询数据库里的最新数据，而不是信任token里存放的旧数据。同时，一定要设置过期时间，不然token一旦泄露就永久有效。

6.3 密码存储：明文是答辩时最容易被攻击的点

登录模块如果连密码都以明文存进数据库，这属于“看着能跑，但项目不合格”的典型问题。正确做法是使用BCrypt加密，Spring Security自带的BCryptPasswordEncoder就能实现。

注册用户时，密码先通过passwordEncoder.encode()加密后再存库。登录校验时，使用passwordEncoder.matches(rawPassword, dbPassword)判断。因为BCrypt每次生成的哈希都带随机盐，我们根本不需要自己在数据库记录盐值，它会把盐和算法信息一起编码在结果字符串中。

6.4 用户端与后台管理端接口清单参考

为了让大家对接口设计有个整体认知，我列一份接口表：

接口路径设计上有个小技巧：/api/admin/**统一放在后台角色访问区域，/api/user/**是登录用户访问，/api/venue/**这类公开查询不强制登录。Security配置里按路径区分权限，比在每个Controller里手写角色判断更优雅。

6.5 Swagger与Knife4j的注意事项

调试接口时如果每次都在浏览器手动输入JSON请求体太痛苦，建议使用Knife4j生成的接口文档页面调试。它既能展示接口参数，又能做接口调试，不需要额外装Postman。

集成Knife4j有一个细节：如果你用Spring Boot 2.x，依赖引入的是knife4j-openapi2-spring-boot-starter；如果使用Spring Boot 3.x，则需要引入knife4j-openapi3-jakarta-spring-boot-starter。包选错了，页面会打不开。

另外，当项目加上Spring Security之后，/doc.html和它依赖的静态资源路径必须在Security中放行，否则页面会一直提示未授权或登录跳转失败。这是集成Security+Swagger最常见的问题。解决方式就是SecurityConfig里把/doc.html、/webjars/**、/v3/api-docs/**等全部加入白名单，前面代码里我已经体现。

7. 从能跑到能部署：打包与运维踩坑

7.1 Maven打包不成功的常见原因

本地开发一切正常，但执行mvn clean package后却报各种各样的错，或者打出来的Jar包一运行就提示找不到主类，大多是以下原因：

第一，没有配置Spring Boot的Maven插件。你要在pom.xml里加上：

xml复制<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

不加这个插件，你的项目编译后可能只是一个普通Jar包，没有把依赖的库打进去，运行时会报ClassNotFoundException。

第二，打包时单元测试失败导致构建中断。如果项目里写了会连接数据库的测试类，执行打包时它去连接数据库失败，从而中断打包。很多同学解决这个问题的方法是：把测试类删除，或者在Maven打包命令中加-DskipTests跳过测试。

执行命令建议直接：

bash复制mvn clean package -DskipTests

第三，代码编译检查没过。比如Lombok注解需要额外配置，确保IDEA里已经安装了Lombok插件；有些情况下代码里用了var关键字而JDK版本设置不对，也会导致编译失败。遇到编译Errors时，先看具体报错信息，别急着重新打包。

打完包之后，本地验证运行：

bash复制java -jar target/stadium-booking-0.0.1-SNAPSHOT.jar

看到Spring Boot的启动日志和Tomcat started on port 8080字样，说明打包成功。

7.2 JDK1.8项目打包到Docker Desktop的操作步骤

如果你希望把项目做成一个镜像，在Docker里跑起来，最典型的做法是写一个Dockerfile，把我们刚才打出来的Jar包放入一个基于Java运行时的镜像中。

对JDK8项目，我推荐使用openjdk:8-jdk-alpine作为基础镜像，但需要注意一个坑：alpine镜像非常精简，默认没有bash和中文字体等库，如果你项目里导出了Excel或图片验证码需要依赖字体，可能出现字体缺失问题。此时推荐改用openjdk:8-jre-alpine并安装字体包，或者更省事一点，直接用openjdk:8-jdk镜像来跑，不过镜像体积会大不少。

一个比较标准的Dockerfile：

dockerfile复制FROM openjdk:8-jdk-alpine
MAINTAINER yourname
VOLUME /tmp
COPY target/stadium-booking-0.0.1-SNAPSHOT.jar app.jar
ENV JAVA_OPTS=""
# 设置时区，避免容器内时间相差8小时
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar" ]

用Docker Desktop操作时，先在项目根目录执行mvn clean package -DskipTests，然后写Dockerfile，再执行：

bash复制docker build -t stadium-booking:latest .
docker run -d -p 8080:8080 --name stadium-booking stadium-booking:latest

但这里还有一个很常见的坑：容器里的应用需要连接宿主机上的MySQL，如果数据库连接地址写成localhost:3306，那在容器里访问的会是自己容器内部的3306端口，根本连不上。

解决方案有两种：

1. 如果只想本地快速跑，MySQL连接地址可以改为host.docker.internal:3306。Docker Desktop在容器里内置了宿主机域名host.docker.internal，能用它访问宿主机的数据库。
2. 更规范的方案是用docker-compose把MySQL和Spring Boot应用编排在一起，用服务名作为网络主机名连接。这个对毕设来说可能稍显复杂，但如果你愿意学，属于加分项。

7.3 文件上传路径与静态资源映射：别把图片放到代码里

场馆图片上传是非常普遍的需求。新手往往会把上传的图片保存到项目目录下的src/main/resources/static/upload/里，这在本地调试时看似有效，但当你打Jar包运行时，会发现静态资源生成到了Jar包内部或者根本没有写入权限，要么重启后图片丢失，要么在服务器上根本找不到文件。

正确做法是：把上传的文件保存到操作系统的某个固定目录，例如Linux下的/data/upload/，或者Windows下的D:/upload/，然后通过静态资源映射，让URL访问到这个外部目录。

一个简单的WebMvc配置方法：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Value("${file.upload-path}")
    private String uploadPath;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath + File.separator);
    }
}

在application.yml里指定：

yaml复制file:
  upload-path: /data/stadium-booking/upload/

访问图片时，如果数据库存的路径是/upload/2025/06/abc.jpg，浏览器请求http://localhost:8080/upload/2025/06/abc.jpg，Spring Boot就会映射到服务器的/data/stadium-booking/upload/2025/06/abc.jpg。这个方案把程序和文件分离，下次升级部署不会把用户上传的照片弄丢，是经验上的重要优化。

7.4 如果你还要接消息队列

部分同学可能会为了增加项目复杂度，把RocketMQ或Kafka用于“预约成功后发送站内信通知”或“订单超时延迟关闭”。这种思路本身很有加分项，但请务必先跑通核心预约，再考虑消息队列。

如果要用RocketMQ，需要注意版本匹配和服务器端nameserver启动。在本地如果你没有安装RocketMQ服务，rocketmq-spring-boot-starter会把应用启动卡在RocketMQProperties初始化或者连接失败。我不是反对你使用，而是提醒你：额外引入中间件之前，先确认自己真的能启动和维护它。

用Kafka也一样，它本身对集群要求不高，本地单机就能测试，但依赖配置项也很多。这类中间件在毕设里属于“锦上添花”项，核心系统稳固才有意义。

8. 常见问题速查与答辩加分项

8.1 高频异常的排查清单

我在指导过程中总结过一版问题速查表，列在这里，遇到可以直接对照排查：

表里的每一项我基本都实际踩过。尤其时区问题，我见过不止一个同学在答辩前夜因为数据库多出的8小时而崩溃。要提前把时区统一好，而不是等出了问题再猜。

8.2 答辩时老师会从哪些角度“攻击”你的预约系统

参加答辩前，你需要准备一些“灵魂拷问”的回答。我归纳几类高频问题：

问：你这个预约系统，和普通的管理系统有什么本质区别？

答：普通管理系统偏重增删改查，预约系统不一样，它是有资源状态管理的。真正的难点在于同一时间同一场地不能被预约两次，以及用户取消或超时后，系统如何自动释放资源。然后你把前面说的事务、锁、状态机机制讲出来。

问：如果两个用户同时点击预约同一个场地，会发生什么，你怎么保证不冲突？

答：后端使用了数据库事务加行级锁，操作流程是锁定场地记录，再查询有效订单，最后插入新订单。由于同一时间只有一个事务能拿到锁，所以第二个请求会阻塞并等到第一个请求提交后再判断，发现该时段已有订单就会提示用户选择