Spring Boot自习室座位预约系统源码拆解与部署实战-嵌云网-嵌入式AI开发资源站

Spring Boot自习室座位预约系统源码拆解与部署实战

学康复的橙橙·2026-10-03·阅读 21 GEO检测（免费）

Spring Boot座位预约系统毕业设计

|难度：普通|阅读约 42 分钟

开工前先聊聊：这个系统到底解决什么问题

座位预约这事儿，只要在高校图书馆或自习室待过的人都有体会。早上八点开门，七点半门口就排起长队，推开门那一刻简直像春运抢票，先到先得全靠腿快和眼疾手快。更头疼的是，人走了书还在，座位一占占一天，真正想学习的人反而找不到位置。我做毕业设计时观察了一圈，发现这类“自习室座位预约系统”在计算机类毕设里一直很热门，因为它麻雀虽小五脏俱全，刚好能把Spring Boot项目里最常考的那套东西串起来：用户登录、数据建模、核心业务逻辑、前后端交互、甚至高并发下的预约抢座场景，都能在里面体现。

这次要拆解的，就是一套基于 Spring Boot 的自习室座位预约系统源码，完整包含了管理员端和用户端，主要功能有用户注册登录、座位状态可视化、在线预约/取消、签到签退、违约记录、后台座位管理、预约统计等。如果你是计算机专业准备做毕业设计，或者想快速掌握一个真实业务系统的开发流程，这份源码配上这篇拆解文章，基本可以让你少走一个月的弯路。

先说结论：这个系统的技术选型非常符合毕业设计的“稳妥路线”。 后端用Spring Boot + MyBatis Plus，权限用JWT做无状态认证，数据库用MySQL，缓存用Redis（处理座位状态和预约锁），定时任务处理超时未签到座位的释放。没有过度设计，但每一块都能在答辩时讲出东西来。下面我从项目设计思路、核心功能实现、部署运行到常见坑点，一条线完整拆给你看。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

1. 项目整体设计与技术选型复盘

1.1 核心需求拆解：先看清楚“自习室场景”的特殊性

一个自习室座位预约系统，表面看就是“用户选座位-提交预约-到馆签到”，但深入想，里面有几个需求点非常容易踩坑。

第一是座位状态的实时性。自习室的座位是物理存在的，一张桌子可能被拆成两个座位、四个座位，每个座位只有三种状态：空闲、已预约、使用中（已签到），外加一个“待释放”的中间态。用户打开页面时看到的状态必须是准的，否则会出现两个人都预约到同一张桌子的尴尬。这就要求数据一致性处理到位。

第二是预约与违约的闭环。座位不是预约了就完事，还要设计“超时释放”规则，比如预约后30分钟内不到场签到，座位自动释放，并给用户记一次违约。违约次数多了要限制预约资格。这个逻辑是整个系统的业务亮点，也是答辩时老师最容易追问的点——你怎么保证定时释放不误伤已经坐在那儿的人？

第三是管理员的后台管理。管理员需要能调整自习室和座位布局，查看预约记录，处理用户的违约申诉。注意，很多毕设只做了用户端，后台简陋得一塌糊涂，答辩时老师打开管理页面二十秒就关掉了。这套源码把管理端做成了单独的一整套功能，包括座位增删改查、预约流水查询、用户管理、数据统计看板，整体完成度明显高出一截。

1.2 Spring Boot为什么是毕业设计的“稳妥牌”

选Spring Boot而非其他框架，核心原因很实际：它把Java后端开发的门槛按在地上摩擦了一遍。

2017年之前写Java Web项目，要配XML配置文件、部署到Tomcat、处理各种依赖版本冲突，光是搭环境就能消耗一个周末。Spring Boot用自动配置把这些“重复造轮子”的脏活累活全包了，你只要引入依赖，写好application.yml，一个main方法直接启动内嵌Tomcat。这种体验对做毕设的学生来说极其友好——不需要单独装Tomcat，不需要折腾服务器的部署方式，写代码的时间能全部花在业务逻辑上。

而且Spring Boot生态的整合能力太强了。这套系统里用到的组件，几乎都能通过starter一键引入。比如说：

spring-boot-starter-web：提供REST接口能力，内置Tomcat
mybatis-plus-boot-starter：数据访问层，连SQL大部分都给你自动生成好了
spring-boot-starter-data-redis：对接Redis做缓存和分布式锁
spring-boot-starter-security：做认证授权（也可以直接用JWT拦截器方案）
spring-boot-starter-validation：做参数校验，规范接口入参

这套技术栈在就业市场同样是主流。哪怕是实习生的JD上，“熟悉Spring Boot”“了解MyBatis”“会用Redis”几乎是标配。你把这个项目完整做下来，写进简历里，面试时讲的每一个模块都是真实踩过坑的，这种感觉和背面试题完全不同。

1.3 项目结构规划：包结构这样拆，答辩不心虚

打开源码第一步，别急着跑，花半小时看包结构。这个项目的包划分很清爽，基本遵循了标准的Controller-Service-Mapper三层架构：

code复制com.example.studyroom
├── controller          // 接口入口层：接收参数、返回结果
│   ├── admin           // 管理员端接口
│   └── user            // 用户端接口
├── service             // 业务逻辑层：真正的核心逻辑都在这里
│   ├── impl            // service实现类
│   └── ...             // 定时任务、消息队列消费等
├── mapper              // 数据访问层：MyBatis Plus接口
├── entity              // 数据库实体类
├── dto                 // 数据传输对象：接收前端参数
├── vo                  // 视图对象：返回给前端的数据
├── config              // 配置类：拦截器、跨域、Redis等
├── utils               // 工具类：JWT工具、日期处理等
└── common              // 公共类：统一返回结果、异常处理

这里有一个很多初学者容易忽视的点：dto和vo要分开。接收前端传入的请求参数和返回给前端展示的数据结构往往不是同一个对象。比如前端请求预约时传的是ReserveRequestDTO（包含座位ID、时间段、用户ID），而返回给前端的是ReservationVO（包含座位编号、预约状态、签到截止时间、剩余时间等）。不分开写，后期一旦前端需求调整，接口数据一变，连带数据库实体类也得跟着动，那场面就是牵一发动全身。

统一返回结果Result<T>也是一个容易犯懒但必须做的事。登录成功、查询失败、参数校验不过，所有接口都返回同一种结构体，前端处理起来才会舒服。这个项目里基本所有接口返回都是Result.success(data)或Result.error(code, msg)，状态码覆盖了200成功、400参数错误、401未登录、403无权限、500系统异常，前端的拦截器就能统一处理弹窗提示，体验立刻不一样。

2. 核心功能模块与数据库设计：先把地基打牢

2.1 用户认证与角色权限

这个系统在你启动那一刻，就要面对第一个核心问题：一个人怎么知道自己是普通学生、管理员还是超级管理员？答案就是JWT（JSON Web Token）。

JWT的核心机制是服务端不存登录状态，用户登录成功后，服务端签发一个包含用户ID、用户名、角色信息的加密Token。之后每次请求，前端把这个Token放在请求头里带过来，服务端验签通过就相信你是谁。无需在服务器内存里维护session，这让系统天然支持水平扩容——你部署三台实例，任何一台都能验签同一个Token，用户体验无感。

项目里的JWT实现其实不复杂，核心代码就三层：

java复制// 生成Token：把用户信息塞进去，设置过期时间为7天
String token = Jwts.builder()
        .setSubject(user.getId().toString())
        .claim("username", user.getUsername())
        .claim("role", user.getRole())
        .setIssuedAt(new Date())
        .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000))
        .signWith(SignatureAlgorithm.HS256, secretKey)
        .compact();

java复制// 解析Token：从request里取出来，验签，取出用户信息
Claims claims = Jwts.parser()
        .setSigningKey(secretKey)
        .parseClaimsJws(token)
        .getBody();

java复制// 拦截器里判断角色权限
if (!"ADMIN".equals(claims.get("role"))) {
    throw new BusinessException(403, "只有管理员可以操作");
}

这里有一个实践细节值得拿出来说：admin接口和user接口的拦截器要分开配置路径。比如/api/admin/**路径的请求要求必须登录且角色为ADMIN，/api/user/**路径只要求登录。如果都混在一起，容易把管理员接口误开放给学生调用，酿成权限漏洞——毕设答辩时被老师点到这个问题，会特别尴尬。

2.2 座位状态管理与预约核心流程

座位状态是整个系统的心脏。我先定义状态机的流转：

AVAILABLE（空闲）：未被预约，任何人可选
RESERVED（已预约）：用户已提交预约，但还未到馆签到，等待期内他人不可选
OCCUPIED（使用中）：用户到馆签到成功，座位正在被使用
DISABLED（禁用）：管理员手动维护，比如灯管坏了、插座没电、临时被征用

核心预约接口的逻辑，伪代码长这样：

java复制public Result reserveSeat(Long seatId, Long userId, LocalDateTime startTime) {
    // 1. 判断预约时间段是否在系统允许范围内
    if (startTime.isBefore(LocalDateTime.now())) {
        return Result.error("预约时间必须晚于当前时间");
    }
    
    // 2. 校验用户当天是否已经有有效预约（防止一人占多座）
    int validReservationCount = reservationMapper.countValidReservation(userId, today);
    if (validReservationCount >= 1) {
        return Result.error("您当前已有有效预约，请先取消或完成签到");
    }
    
    // 3. 锁住座位，查状态
    boolean locked = redisLock.lock("seat:" + seatId, 10, TimeUnit.SECONDS);
    if (!locked) {
        return Result.error("该座位正在被其他用户预约，请稍后重试");
    }
    try {
        Seat seat = seatMapper.selectById(seatId);
        if (seat.getStatus() != SeatStatus.AVAILABLE) {
            return Result.error("该座位当前不可预约");
        }
        // 4. 更新座位状态为RESERVED，同时插入预约记录
        seat.setStatus(SeatStatus.RESERVED);
        seatMapper.updateById(seat);
        reservationMapper.insert(new Reservation(userId, seatId, startTime));
    } finally {
        redisLock.unlock("seat:" + seatId);
    }
    
    // 5. 启动一个延迟任务，30分钟后检查是否完成签到
    scheduledTask.schedule(() -> {
        // 超时释放逻辑见下文
    }, 30, TimeUnit.MINUTES);
    
    return Result.success();
}

这里出现了一个关键方案：Redis分布式锁。为什么不是简单的“查一下状态再update”？因为两个人同时提交请求，都会先读到“AVAILABLE”，然后都去执行update，最后两个预约记录都插进去了，数据就乱了。分布式锁保证同一时刻只能有一个请求在处理同一个座位的预约操作，另外那个人必须等锁释放后重新读取状态，发现已经变成“RESERVED”，于是被正确拒绝。

如果你的项目在答辩时被问到“如何防止两个用户抢同一个座位”，这就是最合适的答案方向。至少证明你思考过并发场景，而不是只在单机测试环境跑通了流程。

2.3 数据库核心表关系

数据库一共十来张表，核心表我整理一下：

表名	核心字段	说明
`user`	id, username, password, role, credit_score	用户表，密码存的是BCrypt加密后的密文
`study_room`	id, name, floor, capacity, description	自习室表，一个自习室下有多个座位
`seat`	id, room_id, seat_no, status, type	座位表，通过room_id关联自习室
`reservation`	id, user_id, seat_id, reserve_time, status, signin_time, signout_time	预约记录表，记录每一次预约生命周期
`violation`	id, user_id, type, description, create_time	违约记录表，超时未签到、超时未签退都算
`admin`	id, username, password, role	管理员表

注意credit_score这个字段。很多系统设计违约记录只是为了记录但从不惩罚，那违约规则就形同虚设。这套源码里，用户每次违约扣10分，积分降到60分以下禁止预约3天，这个规则虽然简单，但形成了一种真实可感知的约束。设计系统时加一点类似的小细节，答辩时讲“如何保证预约资源被合理使用”就会很有说服力。

reservation表上的索引也要提一下。user_id和seat_id必建索引，因为最频繁的查询就是“查某用户当天有效预约”和“查某座位的预约历史”。另外可以用组合索引(user_id, status)，让查询快速过滤掉无效预约记录。MySQL在数据量变大之后，索引设计好坏对查询性能影响是数量级的，虽然毕设数据量小看不出差别，但养成这个意识很重要。

3. 关键功能实现与代码级拆解：这部分才是实操精华

3.1 预约主流程的前后端协同

先看用户最核心的界面操作路径：打开小程序/网页 -> 选自习室 -> 看座位图（绿色空闲/黄色已预约/红色使用中）-> 点击座位 -> 提交预约 -> 收到成功提示。这套流程能跑通，前端JavaScript的关键在于定时轮询座位状态接口。

后端核心接口就是GET /api/user/seat/list?roomId=1，返回该自习室下所有座位的状态列表，前端拿到状态后给每个div设置不同背景色。这里有一个值得优化的点：前端不要每次点击刷新按钮就调一次全量接口，可以用WebSocket做实时推送，但考虑到毕业设计的时间成本，轮询已经足够，一般3~5秒请求一次即可。商业系统会用WebSocket省流量，但轮询的写法简单、能跑、还能在答辩时讲出“我用的是轮询方案，后续可以优化成WebSocket”的过渡话术。

签到接口的逻辑要特别注意：用户到达自习室后点击“签到”，后端要做的事比想象中多——更新预约记录状态为SIGNED、更新座位状态为OCCUPIED、校验是否在允许时间内（提前签到可以但不用做特殊处理，超时未签到则走到违约流程）。这里要处理一个边界情况：用户拿手机在自习室门外提前签到怎么办？严格做可以用GPS定位或扫码进入，但毕设项目通常不做这么重。常见简化方案有两种：一是跟自习室管理员口头确认后由管理员后台代签，二是只做时间窗口校验。这套源码用的方案是签到二维码——用户端生成二维码，管理员端扫码确认签到，逻辑简单且能防作弊，算是比较巧妙的性价比方案。

3.2 定时释放座位与违约记录，藏在细节里的业务逻辑

这是整个系统业务逻辑最复杂的部分，也是最容易出bug的地方。我先说需求：用户A在10:00预约了座位，系统规定30分钟内不签到则座位释放，并且给A记一次违约。

最容易想到的写法是@Scheduled(cron = "0 0/1 * * * ?")每分钟扫一次reservation表，把所有“预约时间距今超过30分钟且状态还是RESERVED”的记录找出来，批量更新座位状态。这个方案最大问题是轮询有延迟——极端情况下用户会看到座位一直显示“已预约”，实际它早就超时了，要等下一分钟扫描才会释放。

我实际项目里推荐的做法是延迟队列。预约成功后往Redis的ZSet里扔一条延迟消息，score设置为“当前时间+30分钟的毫秒时间戳”。另起一个定时任务每10秒拉取一次score小于当前时间戳的消息，命中后去检查预约记录是否仍然未签到，是则触发释放逻辑。这样释放动作基本能在30分钟零10秒内完成，体验好很多。

坑点来了：同一个座位上，用户预约后放弃，前端没有点“取消预约”，直接把小程序关了怎么办？ 这种情况系统必须在定时任务层面兜底——不能只依赖用户主动取消。释放逻辑里要注意，预约记录状态更新和座位状态更新必须以事务方式提交，防止“座位置空但预约记录还是已预约”的数据不一致。另外，如果用户超时被释放后马上重新预约同一个座位，这个时候最好对用户做一次提示“您上一次预约因超时被释放，再次超时会被限制预约”，避免用户反复占座不签到刷积分。

违约记录的触发点不止“超时未签到”这一处。“超时未签退”也要设计——比如自习室规定预约时段结束后15分钟内必须签退，否则记违约。但签退往往没有强制手段，所以实操中很多自习室是管理员到点巡逻、发现人不在且系统显示还在使用中，就手动结束。这套源码的默认规则是：预留结束时间后15分钟未签退，系统自动标记为违约并释放座位，如果用户实际还坐在这里，由管理员后台处理申诉。

3.3 人脸识别和扫码签到，补充加分项怎么做

如果你想在这个基础上做差异化改造，最推荐加的模块就是“入座验证”。单纯靠预约记录和后台代签的合规性说服力不够强，但加上人脸验证就完全不一样了。方案可以设计成：预约成功后生成一个二维码，用户到自习室门口扫描机扫一下，后台调用人脸识别接口（可以用百度AI开放平台的人脸比对接口）比对扫描拍到的脸和注册时上传的照片是否一致，通过则自动签到并把座位状态更新为使用中。

这个方案的落地点在于：不需要自己在本地训练模型，把识别能力外包给云服务，代码里只要组织好调用参数和回调结果就行。本质上这也不难——注册时收集一张人脸照片，签到的时候上传一张当前照片，两个比对的相似度超过阈值就放行。唯一的代价是调用云接口需要联网。但它在答辩现场演示时的效果相当炸裂，老师看到“人脸签到成功”比看到一行“签到成功”要兴奋得多。如果你有时间，强烈建议在这个点上做二次开发。

4. 从零跑到上线：完整部署实操与避坑记录

4.1 本地开发环境准备，别在第一步翻车

先列一遍这份源码运行所需的软件环境，我踩过的坑都会标注清楚：

JDK版本：要求1.8以上，建议直接用JDK 8。我实测过JDK 17也能跑Spring Boot 2.7.x的项目，但有些老版本依赖对高版本JDK不友好，出问题排查成本高，毕设阶段别为了“用新版”而去折腾环境。
Maven：要求3.6.0以上。装好后配置阿里云镜像源，否则依赖下载速度会让你怀疑人生。
MySQL：推荐5.7或8.0。需要注意MySQL 8的驱动包名不同，要在pom.xml里用com.mysql:mysql-connector-j而不是老版的mysql:mysql-connector-java。
Redis：Windows用户可以下载Windows版Redis直接运行，Mac/Linux用户用brew/apt安装即可。
IDEA：推荐2022.x版，社区版即可满足需求。装好Lombok插件和MyBatisX插件（前者必要，后者能加速开发）。

准备环境时最容易翻车的点：数据库编码。建立数据库时请务必设置utf8mb4，否则中文数据存进去全是问号。命令行执行：

sql复制CREATE DATABASE study_room DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

4.2 源码导入与配置修改

拿到源码后，用IDEA以Maven项目方式导入，等待依赖下载完成后，按下面顺序修改配置：

第一处，application.yml里的数据源配置：

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/study_room?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: yourpassword
  redis:
    host: localhost
    port: 6379
    database: 0
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

server:
  port: 8080

mybatis-plus:
  mapper-locations: classpath*:mapper/**/*.xml
  global-config:
    db-config:
      id-type: auto
  configuration:
    map-underscore-to-camel-case: true

MySQL连接串里有一项特别容易忽略：serverTimezone=Asia/Shanghai。不配这个，高版本驱动默认时区不对，启动后所有时间字段读写会差8个小时，签到逻辑全乱。这个坑我当年排查了一整个下午才意识到是时区问题。

第二处，确定Redis密码。如果本机Redis没设置密码，spring.redis.password留空即可；如果有密码要填写。用了云Redis实例再接本地协同调试，或者本地Redis版本太旧，都会出现连接不通的问题。建议本地调试就用本机Redis，简单直接。

第三处，数据库初始化。源码中通常附带sql目录下的初始化脚本，直接在Navicat或命令行里执行。执行完成后，打开用户表能看到默认的管理员账号和密码，注意密码是BCrypt加密的密文，不要直接在数据库里改明文，新手最容易在这里栽跟头。

4.3 发布与运行：开发环境和生产环境要分开

本地调试时，IDEA里直接运行StudyRoomApplication.java的main方法即可，然后浏览器访问http://localhost:8080。

部署到服务器时，先用Maven打成jar包：

bash复制mvn clean package -DskipTests

然后在服务器上执行：

bash复制java -jar study-room-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

这里建议养成做多环境配置的习惯。application-dev.yml放本地开发配置，数据库连localhost，日志级别DEBUG（方便看SQL）；application-prod.yml放服务器配置，数据库连云RDS，日志改WARN级别（减少日志写入压力，防止磁盘暴涨）。两套配置共用一个application.yml主文件，通过在启动参数里指定--spring.profiles.active来切换。养成这个习惯后，你的系统从本地迁到服务器，只需改配置不用动代码，能少走很多弯路。

打包时还有一个隐藏坑：前端资源要一起打进去。如果你的前端是Vue项目，先npm run build把Vue打包成dist文件夹，然后把dist目录下的所有文件复制到src/main/resources/static目录下，再执行Maven打包。这样jar包就同时包含后端接口和前端页面，用户只要访问http://服务器IP:8080就能看到完整页面，不需要单开Nginx代理前端。很多同学卡在这一步，就是因为忘了复制dist到static。

如果你有域名想让转发到这台服务器上，可以在云控制台配置Nginx监听80端口，把域名映射指到http://127.0.0.1:8080，用户的访问路径是http://yourdomain.com，体验更专业。Nginx配置里要注意开启Gzip压缩，前端js/css压缩后体积能减少70%以上，加载速度快一倍。

4.4 核心参数配置与调优建议

运行时有个参数我建议生产环境一定要加大——内嵌Tomcat的最大线程数。默认值是200，如果你的系统是放在公网演示，答辩现场几十个设备同时访问，不调大可能会瞬间报“Connection refused”。修改地方是application.yml：

yaml复制server:
  tomcat:
    max-threads: 500
    max-connections: 2000
    accept-count: 200

另一个参数是连接池大小。HikariCP默认最大连接数是10，对于预约类系统的读写频率其实是够用的，但如果使用了Redis来缓存座位状态、又在MySQL上执行批量的定时释放任务，高峰期连接池被打满就会引发连环故障。建议调到20~30，设置maximum-pool-size: 30。同时设置一个connection-timeout: 30000，防止连接获取超时导致大量请求堆积。

5. 常见问题与排查技巧实录：这个系统的“祛魅”指南

5.1 启动阶段高频报错

报错1：Failed to configure a DataSource

这个报错最常见，原因是application.yml里没有正确配置数据源，或者MySQL没启动。排查顺序：先确认MySQL服务是否在运行（命令行执行mysql -u root -p能连上吗），再检查配置里的用户名密码是否正确，最后确认url里的数据库名是否存在。三步排查完基本能定位。

报错2：Access denied for user 'root'@'localhost'

数据库用户名或密码错误。注意如果密码里包含特殊字符（比如@、#），在YAML里必须加引号包裹。踩过一次的坑：密码是abc@123，直接写在YAML里会被解析成奇怪的内容，必须写成password: "abc@123"。

报错3：Whitelabel Error Page

Spring Boot默认的错误页。原因通常是接口路径写错，或者后端代码抛了空指针但没有全局异常捕获。这个系统里有统一的GlobalExceptionHandler，加了@RestControllerAdvice注解，理论上大部分异常都会被拦截，出现白页说明你的请求根本没到达Controller层，重点检查路径是否匹配、拦截器是否放行了该路径。

5.2 预约逻辑运行时问题

问题1：两个用户同时抢同一个座位

这是并发场景最典型的面试追问。如果源码已经用了Redis锁，正常不会出问题。我建议你在本地做一次压测验证：用JMeter模拟20个并发请求预约同一座位，看返回结果是否只有一个成功。如果全部成功，说明锁没生效，大概率是锁没有覆盖“查询座位状态”和“更新座位状态”的完整操作区间，或者锁在finally里没有释放。

问题2：超时未签到，但座位一直显示“已预约”

排查顺序：先确认定时任务是否启用（是不是在启动类上少了@EnableScheduling注解），再检查ZSet的score比较方向是不是写反了。另外注意，延迟任务执行时机的不确定性意味着释放不是严格秒级，实际允许有10秒左右误差，前端轮询状态下感知不明显。

问题3：签到时系统提示“预约记录不存在”

这个大概率是预约时间跨天导致的。比如用户预约23:00的座位，但结束时已经到了第二天凌晨，前端传的日期参数如果带了不正确的时间zone或者丢失了时分秒，后端查询时就匹配不上。处理方式：所有时间字段在数据库统一存datetime类型，后端对比时用LocalDateTime.parse()严格带时分秒，前后端传输时统一用yyyy-MM-dd HH:mm:ss格式字符串。

5.3 答辩高频追问的“知识储备”

最后补一个答辩专用清单，面试官/答辩老师大概率追着这几点问：

追问1：为什么用Redis锁而不是数据库的行锁？

答：行锁（SELECT ... FOR UPDATE）更稳但会阻塞并发性能，而且事务过程中长时间持有锁容易死锁；Redis锁基于内存操作，性能更高。同时Redis锁如果实现不当会存在“加锁后程序崩溃导致锁永不释放”的问题，所以项目里设置了过期时间并用Lua脚本保证“判断+删除”的原子性，给锁续期的场景也做了看门狗机制。

追问2：预约记录的原子性怎么保证？

答：核心就是@Transactional事务注解包裹整个“插入预约记录+更新座位状态”的方法，任何一步异常都会回滚。更稳妥的做法是再结合Redis预扣减座位占用数量，但当前系统数据量不大会保持一致即可。如果被追问到分布式事务，可以提一下Seata AT模式的原理，说明当前规模不需要上分布式事务。

追问3：眼镜蛇循环“预约后取消再预约再取消”的恶意操作怎么防？

答：系统对同一用户同一天有效预约次数做了限制，同时取消次数异常会触发信用分惩罚，信用分低到阈值会被限制预约。通过违约记录+信用分机制来抑制恶意操作，属于轻量级的反作弊手段。

好的，基础的问题排查写到这里。最后再分享一个个人心得：做毕业设计不要贪功能多，而要贪逻辑深。你做一个平平无奇的增删改查系统，和做一个带并发控制、带定时释放、带有惩罚机制的自习室预约系统，在答辩老师眼里完全是两个档次的项目。这个系统的源码我没有直接展示全部代码，因为每行都贴出来反而没有重点，我更建议你按上面的拆解自己动手改造一两个模块，比如加一个“收藏常用座位”，或者把签到改成扫码验证，哪怕只是加上一个信用分排行榜，整个过程带来的成长远比运行通过代码本身要大得多。祝你一次答辩通过，顺利毕业。