简介：一套基于Java的校园图书馆座位预约系统毕业设计程序，面向计算机相关专业毕业生与Java初学者，用于完成课程设计或毕业设计，可解决图书馆座位预约、用户管理、后台数据维护等典型业务问题。资源包整体约12.16MB，主要包含项目源代码、数据库脚本及环境配置说明，覆盖需求分析、总体设计、详细设计与功能测试等完整开发环节，便于对照学习分层架构、数据库访问及关键模块的编码实现。已有3244人学习，压缩包内附可运行的工程文件与数据库文件，结构清晰，代码经测试可正常运行，能帮助读者快速掌握用户登录、座位预约、后台管理等模块的交互逻辑；同时提供部署说明与常见运行问题参考，有效降低环境搭建门槛，也适合在现有功能基础上继续扩展预约提醒、统计报表等能力。

1. 一个座位预约系统，为什么值得当成毕业设计做完

每年期末考试周，高校图书馆都会上演同一幕：早上七点门口排长队，进去之后用书包、水杯占座，真正来自习的人反而找不到位置。这个 Java 校园图书馆座位预约系统毕业设计程序，解决的正是这个具体问题——把座位从「先到先得、人肉管理」变成「线上预约、按时签到、超时释放」。

从毕业设计选题的角度看，它属于中间难度偏上、工作量可控、技术点覆盖完整的经典题目：有 J2EE 后端、有关系型数据库设计、有状态流转的业务逻辑、有并发场景下的超卖问题，还天然带一套 Web 管理端。比「图书管理系统」多一个维度的复杂度，又比「电商秒杀系统」容易落地。它能展示的不只是增删改查，而是「你在真实系统中会遇到的业务冲突怎么处理」。

这篇笔记按一个可复现的完整路径来讲：从功能拆分、数据库设计、核心接口实现，到并发与状态一致性，最后是答辩时最加分的验证方法。适合打算拿这个题做毕设、或者刚入行想练手的学生开发者。

2. 功能拆解与技术选型：先定边界，再写代码

2.1 业务模块怎么划分才不会被答辩老师追问

一个座位预约系统最容易犯的错，是上来就写代码，最后发现功能是「能做」，但边界模糊：到底支持提前几天预约？预约后多久不签到算违约？违约几次限制预约？这些规则没定清楚，代码结构就会到处打补丁。

常见的做法是拆成三个核心模块加一个扩展模块。核心模块分别是座位管理、预约管理、用户管理；扩展模块是统计报表。座位管理负责维护图书馆的物理座位信息，包含楼层、区域、座位编号，以及座位的可用状态；预约管理处理预约、取消、签到、释放这四个动作，是系统的业务核心；用户管理对接学生信息和登录认证；统计报表给管理员看每日入座率、违约率，这部分能拿来做答辩的加分展示。

这样拆的边界在哪？座位管理和预约管理严格分离——座位表只描述「物理上有什么」，不关心「谁坐着」；预约表只记录「谁在哪个时间段占了哪个座位」。以后想从「固定座位」改成「自由座」，只需要改预约逻辑，不用动座位表结构。我一般会画一张简单的模块依赖图给答辩老师看，依赖方向是用户模块没有任何依赖，预约模块依赖用户和座位，统计模块依赖预约，单向依赖清晰可见。

2.2 Spring Boot + MyBatis + MySQL：为什么是这套组合

技术选型直接决定后面写代码的顺畅程度。这个题目的常见选型是 Spring Boot 2.x + MyBatis + MySQL + Maven，前端可以不做，用 Swagger 或者简单的 Thymeleaf 页面暴露功能即可。理由也明确：Spring Boot 把配置收敛到 application.yml，MyBatis 让 SQL 完全在手，适合需要展示 SQL 能力的题目。

对比一下为什么不选 Spring Cloud 或者 JPA。Spring Cloud 对这个题目是过度设计，注册中心、网关、熔断这些概念在毕设答辩里很难自圆其说，除非题目明确要求微服务；JPA 的自动建表能力虽然方便，但遇到座位预约里的复杂查询（比如查某时段哪些座位空闲）反而要用 JPQL 或者原生 SQL，不如 MyBatis 的 mapper XML 直观。做毕设的第一原则是可控，你写的每一段 SQL 都能解释清楚，这会让你在答辩时少很多麻烦。

MyBatis 还有一个实际好处：分页用 PageHelper，批量更新用<foreach>，动态 SQL 的<if>标签可以干净地处理「按时间段查可用座位」这类多条件查询。这些点每个都能作为答辩中「框架选型理由」的论据。

2.3 项目目录结构与分层约定

推荐一个简单可靠的分层方式：controller → service → mapper，model 放实体类，common 放统一返回结果和异常处理。不用引入复杂的 DDD 设计，毕业设计用经典三层就够了，关键是每一层的职责要说得清。

com.example.library ├── controller # HTTP 层，只做参数接收和结果返回 ├── service # 业务层，预约状态流转的核心逻辑 ├── mapper # MyBatis 数据访问层 ├── model # 实体类（Seat、Reservation、User） ├── common # 统一响应封装、异常处理、常量定义 └── config # 配置类（跨域、Swagger、定时任务）

分包之后有个容易忽略的约定：controller 里不能出现业务判断，比如「这个座位是否已被预约」不能写在 controller 里；service 层不能出现 SQL 关键字，比如selectSeatByCondition这种命名就不合适。层与层之间靠方法名和参数传递意图，代码评审和后续维护都会省力很多。

3. 数据库设计：座位预约的核心是「唯一约束」与「状态机」

3.1 三张核心表的建表 SQL 与字段含义

数据库是这个系统的根基，字段设计错了后面全是补丁。常见的表结构是seat、reservation、user三张表，seat表描述座位物理属性，reservation表描述预约行为，user表描述用户账号。下面是核心建表 SQL：

-- 座位表：物理座位信息，不关注谁在坐 CREATE TABLE `seat` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `floor` TINYINT NOT NULL COMMENT '楼层', `area` VARCHAR(32) NOT NULL COMMENT '区域标识，如 A 区', `seat_no` VARCHAR(16) NOT NULL COMMENT '座位编号，如 A-101', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1可用 0禁用 2维护中', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_floor_area_seatno` (`floor`, `area`, `seat_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 预约表：一次预约记录 CREATE TABLE `reservation` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `user_id` BIGINT NOT NULL COMMENT '预约人', `seat_id` BIGINT NOT NULL COMMENT '座位ID', `reserve_date` DATE NOT NULL COMMENT '预约日期', `start_time` VARCHAR(8) NOT NULL COMMENT '开始时段，如 09:00', `end_time` VARCHAR(8) NOT NULL COMMENT '结束时段，如 11:00', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待签到 1已签到 2已取消 3已释放 4违约', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `checkin_time` DATETIME DEFAULT NULL COMMENT '实际签到时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_seat_date_time` (`seat_id`, `reserve_date`, `start_time`, `end_time`), KEY `idx_user_date` (`user_id`, `reserve_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 用户表 CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `username` VARCHAR(64) NOT NULL, `password` VARCHAR(64) NOT NULL, `student_no` VARCHAR(32) DEFAULT NULL, `status` TINYINT NOT NULL DEFAULT 1, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段 SQL 里最关键的是uk_seat_date_time这个唯一索引——它在数据库层面保证了「同一座位在同一时间段只能有一条预约记录」。这是整个系统防超卖的第一道防线，比在代码里用 if 判断可靠得多。

另一个容易被忽略的是seat表上的uk_floor_area_seatno唯一索引，它防止管理员重复录入同一个座位；如果没有这条约束，两个座位记录指向物理上同一个座位，预约逻辑会出严重问题。

3.2 为什么用「时段字符串」而不是 DATETIME 存预约时间

预约时间段有两种常见存法：一种是存reserve_date+ 开始/结束的 DATETIME 字段，另一种是上面这种「日期 + 字符串时段」的存法。我推荐后者在毕业设计里更合适，原因是一个典型的学校图书馆预约场景是「按固定时段预约」，比如上午 9:00-11:00、下午 14:00-16:00，而不是用户自定义任意起止时间。

用字符串时段的直接好处：唯一索引可以直接放在(seat_id, reserve_date, start_time, end_time)上，查询「某日某时段哪些座位可用」直接等值匹配即可，不需要做时间区间重叠判断。如果用 DATETIME 区间存，防冲突的 SQL 必须写成start_time < ? AND end_time > ?的重叠判断，索引利用率会下降不少。

时间字段如果是DATETIME存区间，JVM 与 MySQL 的时区差异还会导致边界值错位的问题。使用字符串时段则完全没有时区参与，只是代码里做一个「当前时间是否在时段内」的简单字符串比较。这种方式对校方来说也更符合直觉：图书馆管理员看的是「时段」，不是精确到秒的起止时刻。

3.3 预约状态机：状态流转表比代码更早定义

预约状态是这个系统的业务灵魂，状态之间怎么流转必须提前定死，否则代码里容易出现「从已签到变回待签到」这种荒谬的跳转。这里是状态定义与允许的流转路径，用表格列出来再写代码，后面会很省事。

这套状态机的本质是：状态只能向前走，不能回退。代码里实现为 service 层的一个changeReservationStatus(reservationId, fromStatus, toStatus)方法，SQL 的UPDATE语句里同时带上WHERE status = fromStatus，这样在并发情况下只有状态仍然匹配的那条记录才会被更新。这个做法是「乐观锁」思想在状态流转上的应用，比version字段更直观，也更容易给答辩老师讲清楚。

4. 核心接口实现：预约、取消、签到的事务与并发处理

4.1 预约接口：从参数校验到事务提交的完整链路

预约是整个系统最核心的接口，它要做的事按顺序排：校验用户是否可预约、校验座位存在且可用、校验该时段是否已被占、插入预约记录。这四个步骤必须在一个事务里完成。下面是 service 层核心代码：

@Service public class ReservationService { @Resource private SeatMapper seatMapper; @Resource private ReservationMapper reservationMapper; /** * 创建预约 * @param userId 用户ID * @param seatId 座位ID * @param date 预约日期（yyyy-MM-dd） * @param startTime 开始时段（HH:mm） * @param endTime 结束时段（HH:mm） * @return 预约记录ID */ @Transactional(rollbackFor = Exception.class) public Long createReservation(Long userId, Long seatId, String date, String startTime, String endTime) { // 1. 校验座位是否存在且可用 Seat seat = seatMapper.selectById(seatId); if (seat == null || seat.getStatus() != 1) { throw new BusinessException("座位不存在或不可用"); } // 2. 校验用户是否有未完成的预约（防止恶意占座） int unfinished = reservationMapper.countUnfinishedByUser(userId, date); if (unfinished >= 1) { throw new BusinessException("当前日期已有预约记录"); } // 3. 插入预约记录，靠唯一索引兜底防并发超卖 Reservation reservation = new Reservation(); reservation.setUserId(userId); reservation.setSeatId(seatId); reservation.setReserveDate(date); reservation.setStartTime(startTime); reservation.setEndTime(endTime); reservation.setStatus(0); int insert = reservationMapper.insert(reservation); if (insert != 1) { throw new BusinessException("预约失败，请重试"); } // 4. 标记座位为临时占用（可选，用于前端展示） seatMapper.updateStatus(seatId, 2); return reservation.getId(); } }

这里有个细节要说明：第 3 步的insert依赖的就是数据库的唯一索引uk_seat_date_time。在高并发下，如果两个请求同时抢同一个座位同个时段，两个线程都通过了前两步的校验，但只有一条INSERT能成功，另一个会抛DuplicateKeyException。捕获这个异常并转为友好提示「该时段已被预约」，是最可靠的兜底方案。

参数校验方面，startTime和endTime在进入 service 之前就应该做格式校验，比如用@DateTimeFormat(pattern = "HH:mm")接收，并在代码里比较startTime.compareTo(endTime) < 0，防止出现开始晚于结束这种非法数据。事务用@Transactional(rollbackFor = Exception.class)，注意rollbackFor必须显式声明，否则默认只在RuntimeException时回滚，遇到检查型异常会静默提交，这个坑会在后面的避坑章节专门展开。

4.2 取消预约与签到：用条件 UPDATE 防止状态错乱

取消和签到是状态流转的典型场景。用户取消时，只有「待签到」状态才能取消；签到时，只有「待签到」状态才能变更为「已签到」。如果代码写成先 select 再 update，中间状态被其他请求改了，就会出现逻辑混乱。正确的姿势是用条件 UPDATE 一步到位。

@Transactional(rollbackFor = Exception.class) public void cancelReservation(Long userId, Long reservationId) { // 条件更新：状态必须为 0（待签到）才能取消 int rows = reservationMapper.updateStatusIfMatch( reservationId, userId, 0, 2); // from=待签到, to=已取消 if (rows == 0) { throw new BusinessException("当前状态不可取消"); } // 释放座位占用状态 Reservation res = reservationMapper.selectById(reservationId); seatMapper.updateStatus(res.getSeatId(), 1); }

对应的 MyBatis Mapper XML 如下：

<update id="updateStatusIfMatch"> UPDATE reservation SET status = #{toStatus} WHERE id = #{id} AND user_id = #{userId} AND status = #{fromStatus} </update>

这个写法的巧妙之处在于：WHERE条件里带了status = #{fromStatus}，如果当前状态已经不是 0，0 行被更新，代码就知道操作失败，不会误改数据。同时user_id也放进条件，防止 A 用户拿着 B 用户的预约单号去操作。这个模式在签到、释放、违约标记里完全通用，是状态流转类业务的标准解法。

签到接口逻辑类似，只是fromStatus=0, toStatus=1，并且要额外判断当前时间是否在预约时段内（允许提前签到，但不允许在预约日期之外签到）。如果签到时间晚于预约开始时段超过 30 分钟（可在配置里调），直接走违约流程，不进入已签到状态。

4.3 定时任务：超时未签到自动释放

待签到状态不能无限期占用座位，否则就失去了预约系统的意义。常见做法是配置一个定时任务，每分钟扫描一次当前日期下「预约开始时间已过 N 分钟仍未签到」的记录，把状态改成违约（4），并释放座位。用 Spring 的@Scheduled实现：

@Component public class ReservationTimeoutTask { @Resource private ReservationMapper reservationMapper; @Resource private SeatMapper seatMapper; /** * 每 60 秒执行一次，处理超时未签到的预约 * 超时阈值 30 分钟，可通过配置文件调整 */ @Scheduled(fixedDelay = 60000) public void releaseTimeoutReservations() { // 1. 查出当前日期下，开始时间早于当前时间-30分钟， // 且状态仍为待签到的记录 String timeoutTime = LocalTime.now().minusMinutes(30) .format(DateTimeFormatter.ofPattern("HH:mm")); String today = LocalDate.now().toString(); List<Reservation> timeoutList = reservationMapper .selectTimeoutList(today, timeoutTime, 0); for (Reservation r : timeoutList) { // 2. 条件更新：只有还是待签到状态时才置为违约 int rows = reservationMapper.updateStatusIfMatch( r.getId(), r.getUserId(), 0, 4); if (rows == 1) { // 3. 释放座位 seatMapper.updateStatus(r.getSeatId(), 1); } } } }

参数说明：fixedDelay = 60000表示任务结束到下一次开始之间间隔 60 秒，与fixedRate的区别是前者不会出现任务堆叠——如果某次执行耗时 5 秒，下次会等 60 秒再跑，而不是按固定速率触发。定时任务里也要用条件更新逻辑，因为任务执行期间用户可能刚好点击了取消，状态已经变了，此时不能再把记录标记为违约。

这个定时任务在单机环境下够用，本系统是简单的单体应用，不需要引入分布式任务调度框架。如果以后要部署多实例，需要加一个分布式锁或者用@SchedulerLock来保证同一时刻只有一个实例在跑任务，这是答辩时可以提的扩展点。

4.4 查询可用座位的 SQL 与参数设计

查询可用座位本质上是一个「排除已占」的操作：某个日期某时段，哪些座位不在预约表中，或者预约记录状态不是「占用中」。这里用 NOT EXISTS 子查询来过滤被占用的座位：

<select id="selectAvailableSeats" resultType="com.example.library.model.vo.SeatVO"> SELECT s.id, s.floor, s.area, s.seat_no FROM seat s WHERE s.status = 1 AND NOT EXISTS ( SELECT 1 FROM reservation r WHERE r.seat_id = s.id AND r.reserve_date = #{date} AND r.start_time = #{startTime} AND r.end_time = #{endTime} AND r.status IN (0, 1) <!-- 待签到和已签到都算占用 --> ) ORDER BY s.floor, s.area, s.seat_no </select>

这里的NOT EXISTS比LEFT JOIN ... WHERE r.id IS NULL在 MySQL 优化器里通常执行得更高效，而且语义直接：不存在「该时段占用中」的预约记录，就说明座位可用。状态条件IN (0, 1)别忘了——如果只查status = 0（待签到），已签到的座位会被错误地列为可用，这是新手最容易漏掉的过滤条件。

5. 避坑指南：预约系统最常见的 5 个翻车点

5.1 事务没生效，预约一半失败了数据还留着

现象：并发测试时，插入预约成功了，但更新座位状态失败，数据里出现「有预约记录，但座位标记没变」的脏数据。

原因：最常见的是@Transactional加在了private方法上，或者同类内部调用this.createReservation()导致 Spring AOP 代理不生效。另一个是rollbackFor没写，默认只回滚RuntimeException，而业务里抛的检查型异常导致事务提交了。

解决：把@Transactional加到public方法上，且必须从外部 Bean 调用；rollbackFor = Exception.class写成固定套路。自调用问题的检测方法很简单——在方法里故意抛一个异常，看数据库里已执行的 INSERT 是否被回滚，没回滚就是代理没生效。也可以用SpringBootTest写个单元测试来验证，后面最后一章会展开。

5.2 MySQL 唯一索引报错没有转成友好提示

现象：用户抢座时，前端提示「系统异常：Duplicate entry 'xxx' for key 'uk_seat_date_time'」，用户完全看不懂。

原因：DuplicateKeyException没有被捕获，异常直接抛到了全局异常处理器。全局处理器只接了BusinessException和通用Exception，没有专门处理这个异常类型。

解决：在全局异常处理里加一个针对DuplicateKeyException的捕获，返回「该座位该时段已被预约」的提示。更优雅的做法是在 service 层用 try-catch 捕获后转成BusinessException，注意@Transactional不会因为 try-catch 失效——只有抛出 RuntimeException 时事务才回滚，你捕获后转成自定义异常抛出，同样会回滚。

5.3 时区导致「今天」的预约查不到

现象：部署到云服务器后，定时任务在晚上 11 点把第二天凌晨的预约当成了「今天」的预约处理，部分记录被错误释放。

原因：JVM 默认时区与 MySQL 连接时区的time_zone参数不一致，LocalDate.now()取到的是服务器本地时区，而数据库里NOW()或日期字段的解析用另一套时区规则。两者在跨天边界处产生偏差。

解决：在 JDBC 连接串里显式指定serverTimezone=Asia/Shanghai，并在应用启动时设置 JVM 时区。代码里统一用LocalDate.now()和LocalTime.now()，不要混用new Date()与LocalDateTime。所有日期字段在前后端传输统一成String格式，避免被 JSON 序列化器按默认时区转换。

5.4 定时任务重复执行，同一预约被处理两次

现象：日志里出现同一条预约记录被标记了两次违约，第二次更新返回 0 行，但多打了一条 WARN 日志。

原因：单机环境下fixedDelay不会并发执行，但如果你自己手动调用了一次任务方法、同时定时任务又触发了一次，就会出现重复处理。多实例部署时更明显。

解决：处理逻辑里用条件更新作为天然幂等保障——第二次更新时status已经不是 0，updateStatusIfMatch返回 0，跳过释放座位即可。另外，把「根据状态查询待处理列表」和「执行状态更新」之间的窗口尽量缩小，减少竞态可能。在生产环境建议加shedlock或 Redis 分布式锁，但毕业设计阶段讲清楚条件 UPDATE 的幂等原理就够了。

5.5 测试数据污染：可用座位查询结果不对

现象：测试完手动改了数据库里的reservation.status字段，之后查可用座位，明明座位被占了却显示可用。

原因：直接改数据库状态导致业务数据不一致，更隐蔽的是开发时多次执行同一个测试用例，预约记录残留，而座位状态被人为改回 1。

解决：测试用独立的数据库实例，不要和开发库混用；每个测试方法执行完在@AfterEach里清理reservation和seat表。手动调试时不要直接 UPDATE 状态字段，用系统提供的取消/释放接口操作数据，保证状态机逻辑的一致性。这一条看着简单，但答辩演示时最容易因为"上次手动改的脏数据"翻车。

6. 让系统真正可信：并发测试与答辩验证的最后一公里

毕业设计答辩时，老师不会只看功能演示，更关注的是「你怎么证明你的系统是可靠的」。这里推荐三个层面的验证方法，从轻到重排列。

第一层是接口测试。用spring-boot-starter-test写核心业务场景的测试方法，覆盖预约成功、重复预约失败、取消成功、超时释放这四个主流程。核心是验证状态机的流转是否符合预期，比如预约成功后状态从 0 变 1，取消后从 0 变 2。这一步能筛掉大部分业务逻辑 bug。

第二层是并发验证。这个系统最典型的并发场景是热门座位抢座，可以用 JMeter 或者一个简单的多线程测试类模拟 50 个并发请求抢同一个座位。断言结果是：恰好一条成功，其余返回友好提示，数据库里最终只有一条有效预约记录。这是证明唯一索引与事务配合有效的最直接方式。测试代码的大致写法如下：

@Test void testConcurrentReservation() throws InterruptedException { int threadCount = 50; CountDownLatch latch = new CountDownLatch(threadCount); AtomicInteger successCount = new AtomicInteger(0); ExecutorService pool = Executors.newFixedThreadPool(threadCount); for (int i = 0; i < threadCount; i++) { long userId = 10000 + i; pool.execute(() -> { try { reservationService.createReservation( userId, 1L, "2024-06-20", "09:00", "11:00"); successCount.incrementAndGet(); } catch (BusinessException e) { // 预期内的失败，不计入成功数 } finally { latch.countDown(); } }); } latch.await(); assertEquals(1, successCount.get()); }

第三层是状态一致性校验。跑完并发测试后，手动写一条 SQL 检查reservation表里该日期该时段的状态记录是否只有一条有效——这一步是给答辩老师看「数据最终是一致的」的证据。做法是执行SELECT COUNT(*) FROM reservation WHERE seat_id=1 AND reserve_date='2024-06-20' AND start_time='09:00' AND end_time='11:00' AND status IN (0,1)，返回值等于 1。

一个我自己踩过的教训：把重点放在「证明系统在并发下不会坏」，而不是「证明功能都有」。功能谁都能做，但能讲清楚唯一索引为什么能防超卖、条件 UPDATE 为什么能保证状态不跳变的人不多。把这些验证结果截图放进论文或答辩 PPT 里，比贴十页代码更有说服力。

另外留一句给正在赶工期的同学：不要在答辩前一天才跑并发测试，至少提前三天把测试跑完。我在模拟项目X里就吃过亏——并发只有 10 个线程时一切正常，升到 50 个线程才发现事务代理没生效，预约记录插进去了但座位状态没更新，最后定位是@Transactional写在了私有方法上。这种问题早晚会出现，早测试早安心。

整个方案做下来，你会发现这个题目的价值不在技术有多新，而在于它把业务冲突、并发控制、状态管理这些真实生产问题完整地压缩在一个适度的规模里。照着上面的路径走一遍，你的收获会远超过「拿到一个毕业设计分数」。希望帮到你。

本文还有配套的精品资源，点击获取