SpringBoot+Vue自习室预约系统实战：并发冲突与超时释放设计

自习室预约系统这种题目，如果你在毕业设计选题列表里见过它，或者正打算拿它练手，那这篇文章就是写给你的。我做这套系统的时候，核心选了 SpringBoot + Vue 的组合，后端用 MyBatis 操作 MySQL，前端用 Vue 渲染座位图和预约流程，把 MVC 分层落到了每个模块里。整套源码已经整理到可以拿来直接改的程度，但比源码更值钱的，是我在预约冲突、座位状态、超时释放这些细节上踩过的坑。这篇就把设计思路和实现链路完整过一遍，从建表到接口，从前端调用到并发处理，尽量说透，而不是只给你一张截图。

1. 自习室预约系统解决的是什么问题：占座、统计与管理的现实痛点

1.1 学习场景里最真实的座位矛盾

自习室座位这个话题，几乎每个学校都绕不开。高峰期的时候，图书馆和教学楼自习室的位置要靠抢，甚至有人拿书本、水杯、充电器占座，人到了中午才出现，真正想学习的同学反而找不到位置。如果你去问自习室管理员，他们最大的麻烦不是高峰期本身，而是根本不知道哪些座位是"看起来被占、实际没人"的。传统做法是拿一张纸质登记表，或者Excel登记，谁想用座位就过来签个到，管理员只能在晚上闭馆之后统计一天的使用情况，等发现问题早就晚了。

这套系统的出发点就是解决这三个问题：用户可以提前预约座位，减少现场抢座的随机性；座位在预约后被锁定，超时没有签到就自动释放，治占座不履约的毛病；管理员能从后台看到每个时段、每个自习室的预约量和上座率，而不是月底靠翻Excel做总结。

1.2 这套系统到底管哪些事

我做这个系统的时候，把功能收敛成了两个角色、五类操作，没有贪多。

用户端主要做四件事：

• 查看自习室的实时座位图，绿色是空闲、红色是占用、灰色是维护中
• 选择一个具体时间段提交预约，系统自动判断是否冲突
• 查看"我的预约"列表，支持签到和主动退座
• 收到预约成功和超时提醒（超时释放这种能力靠后端定时任务实现）

管理员端主要做三件事：

• 维护自习室和座位的基础数据，比如新增自习室、调整座位状态为维护中
• 查看所有预约流水，可以手动取消异常的预约记录
• 查看数据看板：当日预约数、上座率、高峰时段分布

功能看似不多，但把一个预约场景从提交到释放的完整状态流转做通，比堆十个增删改查页面有价值得多。很多课设项目就是死在"看起来页面多、实际上逻辑浅"这上面，我这个项目宁可少做两个页面，也要把预约冲突检测和超时释放这两个核心逻辑做扎实。

1.3 什么人适合拿它当参考

如果你是准备毕设或者课设的学生，这套系统的技术栈组合非常适合做开题报告里的"创新点"——SpringBoot负责后端接口、Vue负责前端交互、MyBatis作为ORM层、MySQL做数据持久化，MVC分层清晰，每一层都能在答辩的时候展开讲两句。如果你是自学的初学者，那么这个项目的核心价值在于：你能看到一张座位表和一个预约表是怎么通过Service层协调起来的，而不是一上来就面对残缺的半成品。

当然也要说实话：这种管理系统在业务上并不复杂，它真正考验人的是边界情况——时间重叠怎么判断、并发抢同一个座位怎么办、用户超时不签到怎么释放座位。这些才是源码之外值得仔细琢磨的地方。

2. 技术栈落位：SpringBoot + Vue + MyBatis 在 MVC 三层中的分工

2.1 为什么是 SpringBoot + MyBatis，而不是 SSM 或 JPA

选型这个问题，答辩老师大概率会问，你自己心里也得有数。SSM（Spring + SpringMVC + MyBatis）技术栈不是不能用，但配置太繁琐，光一个XML配置文件就能绕晕初学者。SpringBoot把自动配置做好了，内嵌Tomcat，一个main方法就能启动项目，省下来的精力可以全部放在业务代码上。

ORM层我用MyBatis而不是JPA，原因很实际：这类系统里有不少多表关联查询和动态条件查询，比如"查某个时间段内某间自习室的所有可用座位"，MyBatis的SQL是直接手写的，可控性很强，一眼就能看出查询条件是什么。JPA虽然封装程度高，但在这种报表类查询里反而不直观——你写的是方法名推导的规则，出了问题定位起来绕圈子。

从面试角度讲，MyBatis也是Java后台岗位面试里的高频考点，一级缓存、二级缓存、#{}和${}的区别、动态SQL这些都能在这个项目里找到对应代码。做课设的同时把面试题顺便复习了，这笔账是赚的。

2.2 前后端目录结构长什么样

后端我用标准的Controller-Service-Mapper三层去组织代码，这也是MVC里M（Model）、V（View）、C（Controller）的落地形态。前端Vue负责的其实是View层职责，后端Controller暴露JSON接口给Vue调用。

后端核心目录如下：

src/main/java/com/studyroom/ ├── controller/ │ ├── UserController.java │ ├── RoomController.java │ ├── SeatController.java │ └── ReservationController.java ├── service/ │ ├── ReservationService.java │ └── impl/ │ └── ReservationServiceImpl.java ├── mapper/ │ ├── UserMapper.java │ ├── RoomMapper.java │ ├── SeatMapper.java │ └── ReservationMapper.java ├── entity/ │ ├── User.java │ ├── Room.java │ ├── Seat.java │ └── Reservation.java ├── config/ │ └── CorsConfig.java └── StudyroomApplication.java

Controller只做参数接收和结果返回，不写业务逻辑。Service层负责预约校验、状态流转这类核心规则。Mapper层只负责SQL和执行。这样拆开之后，哪怕后面要换掉前端，后端接口完全不用动，这就是分层的好处。

前端我用Vue配合Element UI库写管理界面，路由分了两条线：

src/ ├── api/ │ ├── reservation.js │ └── user.js ├── views/ │ ├── login.vue │ ├── seatMap.vue │ ├── myReservations.vue │ └── admin/ │ ├── dashboard.vue │ └── reservationManage.vue ├── router/ │ └── index.js └── store/ └── index.js

路由用懒加载的方式引入页面组件，这样构建出来的JS不会挤在一个大文件里，首屏加载会快一些。

2.3 版本搭配与环境准备

版本搭配看起来是小问题，但坑起来真要命。我实测下来这套组合是最稳的：

组件	推荐版本	说明
JDK	1.8	SpringBoot 2.x 生态最成熟
SpringBoot	2.7.x	与 JDK8 兼容性最好
MySQL	5.7 或 8.0	8.0 注意配置 serverTimezone
MyBatis	3.5.x	配合 mybatis-spring-boot-starter
Node.js	14+	前端构建环境
Vue	2.6 / 3.x	配 Element UI 或 Element Plus

如果你用的SpringBoot版本太高，比如3.x，那你需要JDK17起步，MyBatis的starter也要换成新坐标，很多老教程里的配置会失效。我在项目里锁定在Java 8 + SpringBoot 2.7这个组合上，就是为了让新手照着一模一样的步骤也能跑起来，不折腾版本环境。

3. 数据库建模与冲突检测：座位状态与预约记录为什么必须分开

3.1 四张表的字段设计与外键关系

数据库是整个系统的地基。我设计了四张表：用户表、自习室表、座位表、预约记录表。很多初学者会犯一个错误——把座位状态直接做成座位表的一个字段，然后预约记录里再存一份座位状态，两张表互相打架。

正确的做法是：座位表只维护座位的物理属性和当前可用的粗状态，预约记录表负责记录每一次预约的明细和生命周期状态。这就像餐厅的桌台管理：桌台本身存在"空桌/在用/维护"三种状态，但每一拨客人的预订、入座、离席应该单独记流水账。如果你把"这桌被谁订了"直接写在桌台表里，那历史记录、统计分析全都无从谈起。

核心建表SQL如下：

CREATE TABLE tb_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, role TINYINT DEFAULT 2 COMMENT '1管理员 2普通用户', nickname VARCHAR(50), phone VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tb_room ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, location VARCHAR(200), open_time TIME DEFAULT '08:00:00', close_time TIME DEFAULT '22:00:00', description VARCHAR(500) ); CREATE TABLE tb_seat ( id INT PRIMARY KEY AUTO_INCREMENT, room_id INT NOT NULL, seat_no VARCHAR(20) NOT NULL, status TINYINT DEFAULT 0 COMMENT '0空闲 1占用 2维护', row_num INT, col_num INT, UNIQUE KEY uk_room_seat (room_id, seat_no) ); CREATE TABLE tb_reservation ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, seat_id INT NOT NULL, reserve_date DATE NOT NULL, start_time TIME NOT NULL, end_time TIME NOT NULL, status TINYINT DEFAULT 0 COMMENT '0待签到 1已签到 2已完成 3爽约 4已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_date (user_id, reserve_date), KEY idx_seat_date (seat_id, reserve_date) );

预约表里我加了两个普通索引，idx_user_date和idx_seat_date。这两个索引对应两个高频查询场景：一个用户查自己某天的预约记录；系统查某个座位某天是否有冲突预约。没有索引的话，数据量一旦上千，查询就会开始变慢，答辩的时候如果被问到"你的系统能支撑多大并发"，索引就是你能拿出来的第一个优化点。

3.2 预约时间冲突的判断逻辑

预约系统最核心的一段逻辑，就是冲突检测。场景是这样的：座位S在2024-06-01这一天已经有一个09:00-10:00的预约记录，现在有一个新用户想约09:30-10:30，系统应该拒绝他，因为时间重叠了。

这里的关键在于条件判断的边界。很多人第一次写会写成start_time > #{startTime} AND end_time < #{endTime}，这只能判断"新预约完全包含在旧预约内部"这一种情况，漏掉了部分重叠的场景。正确写法是：

<select id="countConflict" resultType="int"> SELECT COUNT(*) FROM tb_reservation WHERE seat_id = #{seatId} AND reserve_date = #{date} AND status IN (0, 1) AND start_time &lt; #{endTime} AND end_time &gt; #{startTime} </select>

XML里的小于号<必须转义成<，否则MyBatis会把它当成XML标签的开头，启动直接报错。这个细节我在项目里第一次跑的时候踩过，报错信息还是那种看不懂的解析异常，排查了半天才反应过来。

条件start_time < #{endTime} AND end_time > #{startTime}表示两个区间[旧开始, 旧结束]和[新开始, 新结束]存在交集。做一个简单的验算：旧区间09:00-10:00，新区间10:00-11:00，那么旧开始09:00 < 新结束11:00成立，旧结束10:00 > 新开始10:00不成立，整体条件不满足，说明这两个区间可以无缝衔接，连续预约互不干扰。这个边界处理一定要想清楚，否则用户正好卡着结束时间点约下一场，就会被误判成冲突。

3.3 座位状态的冗余设计

座位表的status字段和预约表的status字段，是一对冗余与同步的关系。座位表的0空闲/1占用，本质上是"当前是否有有效预约"的缓存值。这样做的好处是：用户打开座位图时，只需要查座位表就能拿到一个座位的当前状态，不需要去预约表里做复杂的聚合判断；坏处是：如果只更新预约表而忘记更新座位表，两张表的数据就会不一致。

我在项目里规定了一组严格的同步规则：

• 提交预约成功 → 座位表status置为1（占用）
• 用户主动退座或超时释放 → 座位表status置为0（空闲）
• 管理员把座位设为维护 → 座位表status置为2（维护），同时取消该座位未来时段的待签到预约

规则简单，但每一条都要在同一个事务里执行。这也是为什么预约接口必须要加@Transactional的原因：插入预约记录和更新座位状态是两件事，任何一个失败都要一起回滚，否则就会出现"预约记录存在但座位显示空闲"或者反过来"座位被占但查不到预约"的诡异状态。

4. 核心预约流程的实现链路：从选座提交到超时自动释放

4.1 用户从前端点击到落库的完整调用链

预约是最核心的流程，我从前端到后端完整串一遍。用户打开座位图之后，看到的是由座位表数据渲染出来的格子视图。点击一个空闲座位，弹出时间选择器，选完时段点提交，这时前端Vue会向后端接口发送一个POST请求。

// vue页面里的核心方法 async function submitReservation(seatId, date, startTime, endTime, userId) { const res = await axios.post('/api/reservation', { seatId: seatId, date: date, startTime: startTime, endTime: endTime, userId: userId }, { headers: { Authorization: localStorage.getItem('token') } }) if (res.data.code === 200) { ElMessage.success('预约成功，请按时签到') refreshSeatMap() } else { ElMessage.error(res.data.msg) } }

后端Controller接到请求后，把参数封装成一个DTO对象，交给Service层处理。Service层的核心校验逻辑我直接贴出来：

@Override @Transactional(rollbackFor = Exception.class) public Result createReservation(ReservationDTO dto) { // 1. 校验座位存在且当前为空闲状态 Seat seat = seatMapper.selectById(dto.getSeatId()); if (seat == null || !"0".equals(seat.getStatus())) { return Result.error("座位不存在或已被占用"); } // 2. 校验时间段合法性 if (dto.getStartTime().isAfter(dto.getEndTime())) { return Result.error("开始时间不能晚于结束时间"); } // 3. 并发冲突检测 int count = reservationMapper.countConflict( dto.getSeatId(), dto.getDate(), dto.getStartTime(), dto.getEndTime()); if (count > 0) { return Result.error("该座位在此时间段已被预约"); } // 4. 插入预约记录，状态为待签到 Reservation r = new Reservation(); r.setUserId(dto.getUserId()); r.setSeatId(dto.getSeatId()); r.setReserveDate(dto.getDate()); r.setStartTime(dto.getStartTime()); r.setEndTime(dto.getEndTime()); r.setStatus(0); reservationMapper.insert(r); // 5. 更新座位状态为占用 seatMapper.updateStatus(dto.getSeatId(), 1); return Result.success(r.getId()); }

这套逻辑看起来简单，但每一步都有它的目的。第一步先查座位状态，是为了快速拦截明显不可用的座位，减少后面无谓的数据库计算。第三步查冲突，是为了防止时间重叠。第四步和第五步必须放在同一个事务里，保证数据一致性。

4.2 并发场景下如何防止重复预约

开门见山说结论：如果你的系统只是课设或者小范围内部使用，上面这段逻辑加上事务基本够用。但如果你要面对几十上百人同时抢座位的场景，单纯的事务是不够的，因为两个请求可能同时在第三步查出"没有冲突"，然后同时插入预约记录，导致同一个座位同一时间段被预约了两次。

我做了两重加固。第一重是数据库层面的唯一约束思路——虽然TIME类型没法简单做唯一索引，但可以在应用层维护一个"座位+日期+开始时间+结束时间+状态"的复合约束提示，考虑到状态会变化，这个方案只能作为辅助。第二重是SQL层面的条件更新：更新座位状态时，不是简单地UPDATE tb_seat SET status = 1 WHERE id = ?，而是加上条件AND status = 0：

UPDATE tb_seat SET status = 1 WHERE id = #{seatId} AND status = 0

如果影响行数为0，说明座位已经被别人抢先占用，事务回滚，这个更新语句就天然成了一个乐观锁。同时在Service层把这个条件更新的返回值作为并发控制的依据。这个思路不复杂，但是效果很直接，避免了引入分布式锁这种重型方案。

4.3 签到、超时释放与状态机流转

预约记录的状态不能只有"预约成功"和"预约结束"两个，我在表设计里列了五个状态，它们之间的流转关系是这样的：

状态码	含义	触发时机
0	待签到	用户提交预约成功后
1	已签到	用户到馆确认签到
2	已完成	预约时段自然结束
3	爽约	超过开始时间30分钟仍未签到
4	已取消	用户主动退座或管理员取消

签到功能我做了简化：用户在我的预约列表里点"签到"，后端校验当前时间是否在预约开始时间前后30分钟范围内，在范围内就把状态改为1。这比二维码扫码方案简单，但核心逻辑一样能展示。

超时释放是这套系统最有价值的地方。它靠SpringBoot的定时任务实现，每5分钟扫描一次：

@Component public class ReservationTask { @Scheduled(cron = "0 */5 * * * *") public void autoClearExpired() { // 预约开始时间已过30分钟，状态仍然为待签到，则标记为爽约 List<Reservation> expiredList = reservationMapper .selectExpired(LocalTime.now().minusMinutes(30)); for (Reservation r : expiredList) { reservationMapper.updateStatus(r.getId(), 3); seatMapper.updateStatus(r.getSeatId(), 0); } } }

这里的SQL要查询"开始时间小于当前时间减30分钟"且状态为0的记录。用LocalTime.now().minusMinutes(30)是在应用层算好时间再传入SQL，这样SQL里不需要做复杂的时间函数换算，逻辑更直观。爽约之后座位释放，下一个人马上就能看到这个座位变成空闲，占座不签到的行为自然就被制度约束了。

5. 管理员侧功能设计：角色校验、数据看板与高峰时段分析

5.1 登录拦截与角色权限

管理员功能不能直接裸奔给普通用户，我用一个后端拦截器实现了简单的角色控制。用户在登录成功后，后端签发一个Token，前端把Token存在localStorage里，每次请求都带上。后端拦截器从Header里解析Token，拿到用户信息后判断角色：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); User user = tokenService.parseToken(token); if (user == null) { response.setStatus(401); return false; } // 管理员接口校验角色 String uri = request.getRequestURI(); if (uri.startsWith("/admin/") && !"1".equals(user.getRole())) { response.setStatus(403); return false; } request.setAttribute("currentUser", user); return true; } }

这个方案对课设来说是够用的，也不复杂。如果要做更完善的控制，可以把Token换成JWT，在拦截器里直接验签，不过核心思路还是一样的：先认证、再鉴权、最后才放行业务请求。

5.2 预约记录管理与退座处理

管理员端的预约管理列表，我做了几种实用的筛选条件：按日期、按自习室、按状态。这样管理员在上座率低的时候，可以快速找出哪些座位长期空闲；上座率高的时候，又能定位哪些预约频繁爽约，后续可以针对这些用户做限制。

退座这块要特别说一个设计：用户主动退座时，需要把预约状态改成4（已取消），同时把座位释放回空闲。我在Service层单独写了cancelReservation方法：

@Transactional(rollbackFor = Exception.class) public Result cancelReservation(Long reservationId, Long userId) { // 只能取消自己的预约 Reservation r = reservationMapper.selectById(reservationId); if (r == null || !r.getUserId().equals(userId)) { return Result.error("预约不存在或无权操作"); } // 只有待签到/已签到状态可以退座 if (r.getStatus() != 0 && r.getStatus() != 1) { return Result.error("当前状态不可取消"); } reservationMapper.updateStatus(reservationId, 4); seatMapper.updateStatus(r.getSeatId(), 0); return Result.success(); }

注意这里有个容易被忽略的规则：状态为2（已完成）或3（爽约）的预约不能再取消，否则历史数据的含义就全乱套了。状态机一旦定下来，所有入口都要遵守同一套流转规则。

5.3 用分组统计支撑自习室运营决策

数据看板不是花架子，它是管理员端和用户端功能的价值证明。我做了两张统计图，一是"最近7天每日预约量"的柱状图，二是"各时段预约热度"的饼图。对应的SQL分别是：

-- 最近7天预约量 SELECT reserve_date, COUNT(*) AS cnt FROM tb_reservation WHERE reserve_date BETWEEN #{startDate} AND #{endDate} AND status IN (1, 2) GROUP BY reserve_date ORDER BY reserve_date; -- 各时段预约热度 SELECT HOUR(start_time) AS hour, COUNT(*) AS cnt FROM tb_reservation WHERE reserve_date = #{date} GROUP BY HOUR(start_time) ORDER BY hour;

第二张图的用途很有意思。管理员看到某几个时段预约热度特别高，就可以在对应时段多开几间自习室；看到某些时段几乎没人约，就可以安排保洁和消杀工作。这个统计分析能力让系统从"登记工具"升级成了"管理工具"，答辩的时候讲这个点，比单纯说"我做了一个CRUD系统"有说服力得多。

前端我只是用ECharts的折线图和饼图展示，数据来源就是上面这两个HTTP接口。Vue侧的代码量不大，核心是把接口返回的数组转成ECharts需要的格式。

6. 实测踩坑记录：时间格式、跨域、并发场景下的三个大坑

6.1 LocalDateTime 序列化：前端显示"一串数字"

这是前后端分离项目里最低频也最经典的坑。后端实体类的createTime字段如果用LocalDateTime，SpringBoot默认的Jackson序列化会把日期转成时间戳格式，前端收到数据后发现日期字段是一串秒数，比如1717230000这种，直接没法展示。

我当时在预约列表页调试了半天，最后发现后端返回的JSON里时间字段全是数字。解决办法有两个，任选其一。

第一种，在实体类字段上加注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime createTime;

第二种，配置全局Jackson序列化规则，这样所有时间字段都不用一个个加注解了：

@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder -> builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer( DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); } }

我最后用了第二种方案，因为系统里时间字段不止一个，全局配置省心。另外提醒一句，如果你用了LocalDate（日期类型，不带时间），也要单独配一个LocalDate的序列化器，格式一般是yyyy-MM-dd。

6.2 跨域配置：前后端联调第一道坎

前端开发服务器跑在8080端口，后端跑在8081端口，两者端口不同，浏览器的同源策略就会拦截请求。我第一次联调的时候，打开浏览器控制台满屏的CORS错误，第一反应是接口写错了，后来才意识到是跨域问题。

解决方式有两种。第一种是在后端写一个CORS配置类，允许前端跨域访问：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

第二种是前端在vue.config.js里配置代理，把/api开头的请求转发到后端服务器，这样浏览器看到的还是同一个源，不触发跨域：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

两种方案我都试过，个人建议在开发阶段用前端的代理方案，因为不用动后端代码，也不会暴露接口给外部；部署上线时，如果后端和前端在同一台服务器、同一个域下，其实没有跨域问题。如果你要用CORS配置，记得allowCredentials(true)和allowedOriginPatterns("*")要配套使用，只写一个会出现响应头缺失的怪问题。

6.3 事务失效与并发重复提交

事务失效这个坑，表面上看代码没问题，实际上执行结果不对。我在写退座逻辑的时候，一开始把cancelReservation方法里的两个更新操作分开了，想着只要每个SQL都执行成功就行。后来测试发现，如果座位表更新成功但预约表更新失败，数据就出现了不一致。加上@Transactional之后，我以为万事大吉，结果又踩了另一个坑——同一个类内部调用带事务的方法，事务不生效。

原因在于Spring的事务是基于AOP代理实现的。调用this.cancelReservation()时，调用的是当前对象的原始方法，而不是经过代理包装的方法，事务注解自然不生效。解决办法是把事务方法拆到另一个类里，或者自己注入自己：

@Service public class ReservationService { @Autowired private ReservationService self; public Result cancelReservation(reservationId, userId) { // 省略校验 return self.doCancel(reservationId); } @Transactional(rollbackFor = Exception.class) public Result doCancel(Long reservationId) { reservationMapper.updateStatus(reservationId, 4); seatMapper.updateStatus(r.getSeatId(), 0); return Result.success(); } }

这个问题在写代码的时候很难发现，因为它不报错，只是在特定场景下数据对不上。我的建议是：凡是涉及两张表以上更新的操作，统一放到Service层独立的事务方法里，不要在Controller里写业务更新逻辑，这样从源头上减少事务失效的可能。

至于并发重复提交，我上面已经写了用条件更新UPDATE tb_seat SET status = 1 WHERE id = ? AND status = 0做乐观锁。这个方法虽然简单，但需要配套一个细节：当SQL影响行数为0时，一定要主动抛出异常或者返回错误结果，让事务回滚。如果写代码的时候忽略了这里的返回值判断，这个乐观锁就形同虚设。

做这类系统最大的收获，不是把SpringBoot和Vue的语法跑通，而是把需求拆成规则：时间重叠怎么定义、状态怎么流转、并发冲突怎么兜底、异常数据怎么回滚。这些规则每一条都在数据库表设计和Service层代码里找到对应实现的时候，你才算真正把这个项目吃透了。源码拿去改很容易，但如果你能把第二章节的冲突SQL、第四章节的乐观锁、第六章节的事务失效这三个点讲明白，那这套系统在你手里才算真正发挥了价值。