简介：这套基于Java技术开发的校园图书馆座位预约系统毕业设计程序，主要面向计算机软件、信息管理等专业的毕业设计或课程设计场景，也同样适合正在自学Java Web开发、希望参考完整项目提升动手能力的入门者。资源包大小约12.16MB，内含一份程序源代码和一份数据库文件，并附有环境配置说明，能够帮助使用者在本地快速搭建运行环境，省去从零摸索的步骤。整个项目遵循软件工程流程，涵盖需求分析、总体功能与数据结构设计、数据库访问实现、核心模块编码以及功能测试等阶段，尤其适合用来理解一个典型管理系统的模块划分、数据表设计以及业务逻辑实现方式。目前已有3244人学习下载，通过学习这份代码，读者可以掌握座位预约、用户管理、数据查询等常见功能的编码思路，也可借助数据库中的初始数据快速演示系统效果，为论文写作、答辩演示或二次开发提供实用参考。

1. 从“占座大战”到线上预约：java校园图书馆座位预约系统到底解决了什么

图书馆占座这件事，在每一所高校都是考试周的保留节目。这套基于Java的校园图书馆座位预约系统，就是针对这个真实场景设计的毕业设计程序，核心目标是用线上预约替代物理占座：学生端提前选座锁定时段，到馆扫码签到，超时未到自动释放，配合黑名单机制让“书在人不在”的做法直接失效。系统覆盖学生端、管理员端、预约规则配置、违约处理和记录查询等完整闭环，适合正在做Java Web方向毕业设计、需要一套能跑通且能讲清楚的完整项目的开发者。拿到源码后不用再从头搭框架，直接把精力花在理解业务和准备演示上，这才是这套资源真正的价值。

2. 系统架构与技术选型：从Servlet到Spring Boot的演进路径

要拆这份源码，先得看技术栈。它选的是Spring Boot + MyBatis + MySQL + Thymeleaf这个经典组合，属于Java Web毕业设计里最主流的一条路线。跟早些年用纯Servlet + JSP的做法相比，这套组合最大的优势是省掉了大量手写配置，同时又保留了SQL完全可控的能力。下面把选型理由、工程结构和启动流程拆开讲，这样你拿到源码后能迅速判断“要不要用”以及“怎么用”。

2.1 技术栈选型：毕业设计场景下最不容易翻车的组合

Spring Boot负责应用的自动装配和容器管理，写一个@SpringBootApplication启动类就能把内嵌Tomcat带起来，不需要单独部署WAR包。MyBatis把SQL写在XML或注解里，开发者在写“查询某个座位在某个时间段是否被占用”这类SQL时可以精确控制每个条件，这一点在预约场景里非常关键。Thymeleaf作为模板引擎，直接在HTML里渲染后端数据，页面由后端渲染的好处是：演示的时候不需要额外启动一个前端工程，打开http://localhost:8080就能看到完整界面。数据库用MySQL，学生管理系统里最常见的选择，任何一台装好MySQL 5.7的机器都能直接导入运行。

如果换成Spring Cloud Alibaba或者前后端分离的Vue项目，代码量会成倍增加，调试链路也会变长。这套系统的复杂度刚好卡在“一个核心业务（预约）、两个角色（学生/管理员）、三个关键流程（预约-签到-违约）”这个量级上，用单体应用加服务端渲染是最务实的解法。类似的架构我在几个模拟项目里都见过，最终能顺利验收的，基本都保持了这个技术选型没有盲目加东西。

2.2 工程结构与包组织：源码包怎么分层才能撑起完整业务

这套系统的源码目录结构，从我拆包的情况来看是这样的：

com.library.reservation ├── controller # 接收请求、参数校验、返回视图 ├── service # 业务逻辑：预约、签到、违约处理 ├── mapper # MyBatis接口与XML映射 ├── entity # 数据库表对应的实体类 ├── config # 定时任务、拦截器、Web配置 └── util # 时间工具、状态枚举、结果封装

controller是最薄的一层，每个方法只负责拿到参数、简单校验、调用service并返回ModelAndView。service是核心，比如预约这个方法，要同时做三件事：查座位当前状态、查该时间段是否已被预约、插入预约记录并修改座位状态。这三步必须在一个事务里完成，否则会出现“记录插进去了座位状态没改”这种脏数据。mapper层的方法名和XML里的id一一对应，SQL全部放在XML里而不是注解里，好处是遇到复杂嵌套查询时格式清晰，调试时直接把XML里的SQL复制到Navicat里跑一遍就能定位问题。

我一般会把座位状态定义成枚举而不是魔法数字。比如0表示空闲、1表示已预约、2表示已入座、3表示暂离，这些数字必须集中在枚举类里，否则代码里到处都是if (seat.getStatus() == 1)，后期改状态定义时就是灾难。这套源码里用了一个SeatStatus枚举，同时封装了状态码和描述文字，页面下拉框和业务判断都用同一个枚举，这个习惯建议保留。

2.3 本地启动流程：从建库到页面跑通的全过程

拿到资源包后，第一步不是急着看代码，而是先把数据库建好，让项目能启动起来。我复现时的操作过程是这样的：

# 1. 创建数据库并导入初始化脚本 mysql -u root -p -e "CREATE DATABASE library_seat DEFAULT CHARACTER SET utf8mb4;" mysql -u root -p library_seat < sql/library_seat.sql # 2. 修改数据源配置 # 打开 src/main/resources/application.yml，改成你本地MySQL的信息 # spring.datasource.url: jdbc:mysql://localhost:3306/library_seat?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8 # spring.datasource.username: root # spring.datasource.password: 你自己的密码 # 3. 启动项目 mvn spring-boot:run

三个步骤里有几个点容易踩坑。第一步导入SQL脚本时，如果是用Navicat，建议用“运行SQL文件”而不是直接把SQL内容粘贴到查询窗口，因为脚本里包含存储过程或定时事件时，粘贴方式经常会半路中断。第二步里，serverTimezone=Asia/Shanghai这个参数必须配，否则JDBC驱动会把UTC时间当成服务器本地时间，导致预约记录的创建时间差8小时，这是Java Web项目里最典型的“玄学”问题。第三步启动后，看到日志里出现“Started Application”，再访问http://localhost:8080/login就能进入登录页。

注意：登录后先点开“座位管理”页面，确认能看到预置的座位列表。SQL脚本里一般会初始化几十个座位和几个测试账号，这样你不需要手动一条条插入数据就能直接开始体验预约流程。如果页面能正常加载且数据不是空的，说明数据库连接、MyBatis映射和模板渲染都没问题。

端口这块，application.yml里server.port默认是8080，如果被占用，改成8081或者9090都行，但要注意登录接口和静态资源路径里的端口也要跟着变。静态资源放在src/main/resources/static下，CSS和JS文件已经打包在里面，不需要额外引入CDN，这一点对演示环境很友好，内网或离线环境都能正常出样式。

3. 核心模块拆解：座位状态机、预约冲突检测与定时释放

把核心业务逻辑拆开看，这个系统的重点集中在三块：座位状态机、预约冲突检测、定时释放。这三块决定了一套座位预约系统能不能在实际使用中扛住并发、避免脏数据。下面逐个拆解实现方式，代码可以直接对照源码包里的对应类查看。

3.1 座位状态机：从“空闲”到“入座”的四种状态流转

座位是整个系统的核心资源，它的状态变化必须严格定义。这套源码里把座位状态抽象成四种：空闲(0)、已预约(1)、已入座(2)、暂离(3)。四种状态之间的流转不是随意跳转的：

• 空闲→已预约：学生提交预约并成功锁定座位
• 已预约→已入座：学生到馆签到，扫描座位上的二维码
• 已预约→空闲：预约超时未签到，定时任务自动释放
• 已入座→空闲：学生主动释放座位，或者闭馆时间统一释放

为什么要有“暂离”这个状态？有同学问过“为什么学生离开座位还要单独标记”，这是从真实图书馆管理需求里来的。学生去接水或上厕所，如果直接释放座位，回来就没位置了；如果不释放，又可能存在长时间占座。所以设计上允许学生在一段时间内标记暂离，这段时间座位保留，超过时限则强制释放。状态流转在代码里通过SeatStatus枚举和Service层的状态校验共同实现，核心是下面这个方法：

public void validateStatusChange(Integer currentStatus, Integer targetStatus) { boolean allowed = (currentStatus == SeatStatus.IDLE && targetStatus == SeatStatus.RESERVED) || (currentStatus == SeatStatus.RESERVED && targetStatus == SeatStatus.OCCUPIED) || (currentStatus == SeatStatus.RESERVED && targetStatus == SeatStatus.IDLE) || (currentStatus == SeatStatus.OCCUPIED && targetStatus == SeatStatus.IDLE) || (currentStatus == SeatStatus.OCCUPIED && targetStatus == SeatStatus.TEMP_AWAY) || (currentStatus == SeatStatus.TEMP_AWAY && targetStatus == SeatStatus.OCCUPIED); if (!allowed) { throw new BusinessException("非法的座位状态流转：" + currentStatus + " -> " + targetStatus); } }

这段代码的核心逻辑是把所有合法的状态变迁显式列出来，不在列表里的流转一律抛出业务异常。有人说用Spring StateMachine状态机框架更规范，但对毕业设计来说，一个方法加一张合法性表就够了，反而更容易讲清楚。参数currentStatus是座位当前状态，targetStatus是目标状态，两个参数来自数据库或前端请求。前端传来的状态码不可信，必须以后端查出的当前状态为准。

3.2 预约冲突检测：时间片重叠判断的SQL实现

预约的核心矛盾在于：一个座位在同一时间段只能给一个人。这个判断不能只做“起止时间相等”这种精确匹配，因为A预约8:00-10:00，B想预约9:00-11:00，两条记录时间并不相等但存在重叠。正确的判断条件是反向找“不冲突”的记录再取反：新预约开始时间小于已预约结束时间，且新预约结束时间大于已预约开始时间。

SELECT COUNT(*) FROM reservation WHERE seat_id = #{seatId} AND status IN (1, 2) -- 已预约或已入座才占用座位 AND start_time < #{endTime} AND end_time > #{startTime}

这条SQL是整套系统的核心查询。逻辑上先固定座位ID，再过滤掉已取消和已完成的记录，最后用时间区间重叠条件算出冲突数量。如果count大于0，说明该时段已被占用，预约请求直接拒绝。参数startTime和endTime是待预约时间段的起止时间，注意这里是用“新预约的开始时间”和“已预约的结束时间”做比较，方向不要写反，写反了就会漏掉边界情况。还要注意status字段的过滤条件必须是IN (1, 2)，因为已入座状态同样占用座位，只查已预约状态会漏判。

3.3 超时未签到自动释放：Spring Schedule定时任务

预约不是“约了就结束”的。为了保证座位周转率，系统约定：预约成功后N分钟内必须到馆签到，否则座位自动释放。这个N由管理员在系统配置里设定，常见值是15到30分钟。实现方式用的是Spring自带的定时任务，启动类上加了@EnableScheduling注解，具体任务写在config包的ScheduledTask类里。

@Component public class ScheduledTask { @Autowired private ReservationMapper reservationMapper; @Scheduled(cron = "0 * * * * ?") // 每分钟的0秒触发一次 public void releaseTimeoutReservations() { // 查询所有"已预约"且超过规定签到时间的记录 List<Reservation> timeoutList = reservationMapper.selectTimeoutReservations(30); for (Reservation r : timeoutList) { // 1. 把预约记录状态改为"超时取消" reservationMapper.updateStatus(r.getId(), ReservationStatus.TIMEOUT_CANCEL); // 2. 把座位状态改回"空闲" reservationMapper.releaseSeat(r.getSeatId(), SeatStatus.IDLE); } } }

这段定时任务的逻辑不复杂，但有参数需要留意。selectTimeoutReservations(30)传入的是“允许超时分钟数”，SQL里用当前时间和预约开始时间做差额比较，超过30分钟才算超时。之所以每分钟跑一次而不是整点跑，是因为预约超时是按“精确时刻”计算的，比如8:31预约的，就应该在超时时刻后的一分钟内释放，延迟一分钟以内用户感知不明显。执行顺序上要注意先把预约记录状态改成“超时取消”，再释放座位，否则座位先释放了，异常中断时就会留下“座位空闲但预约记录还是已预约”的脏数据。

这里还有一个需要重点考虑的边界：如果扫描任务执行过程中，同一条记录被用户手动取消了，定时任务再执行updateStatus时是否会把状态覆盖？解决方法是updateStatus的SQL里带上状态条件，这样即使状态变了也更新不到，算是乐观锁的弱化版。这个问题非常典型，具体写法放到避坑章节细讲。

3.4 违约处理与黑名单：信用分扣减逻辑

学生预约了不来，或者入座后长时间不释放，只靠提醒是没用的，得有惩罚机制。这套系统用信用分体系来实现：每个学生初始信用分100分，预约后未签到扣10分，入座后超时未释放扣5分，信用分低于60分进入黑名单，黑名单用户一周内不能预约。扣分操作和预约流程是解耦的：签到接口在发现预约超时时，不只释放座位，还要调一次creditService.deduct，定时任务处理超时预约时，同样也要扣分。

为什么两边都扣？因为超时释放有两个入口：用户主动到系统里取消（不扣分），和定时任务扫描发现超时（扣分）。如果只在定时任务里扣分，用户掐点在超时前一秒手动取消就能规避扣分，规则就形同虚设。实现上，扣分方法用@Transactional标记，保证扣分和状态更新在同一事务里，避免出现信用分扣了但预约状态没改的情况。

4. 避坑指南：并发预约、定时任务重复执行的五个高频问题

4.1 并发预约同一座位导致重复分配

现象：两个学生同时提交针对同一个座位、同一个时间段的预约请求，后端都通过了冲突检测，数据库里出现两条有效预约记录。

原因：MySQL默认的隔离级别是REPEATABLE READ，两个事务并发执行时，在各自事务内执行SELECT COUNT(*)都看不到对方尚未提交的插入，因此都判断“没有冲突”，随后都执行INSERT，最终产生冲突数据。这个问题的本质是“先检查后插入”的竞态条件，业务层的查询再多也防不住并发下的空隙。

解决：在预约表上对(seat_id, start_time, end_time)加唯一约束，并在插入预约记录时捕获DuplicateKeyException。实现成本最低，数据库层的唯一约束兜底，业务层的SELECT检查只负责减少无效插入，真正保证不重复的是数据库约束。

try { reservationMapper.insert(reservation); } catch (DuplicateKeyException e) { throw new BusinessException("该座位已被他人预约，请选择其他时段"); }

这段代码的核心是用数据库唯一约束兜底，捕获异常后转成业务提示，让用户重新选座。需要特别注意的是，唯一约束的字段组合里要带上座位ID和时间段，否则同一天不同时段的预约也会被误伤。唯一约束的组合顺序尽量和常见查询条件一致，这样索引也能被复用。

4.2 定时任务重复执行导致座位被误释放

现象：明明只过了30分钟，预约记录却显示超时取消；进一步排查发现定时释放逻辑被重复执行了多次，导致刚签到的座位也被误释放。

原因：如果部署环境中启动了多个应用实例，Spring Schedule会在每个实例里独立运行，同一个任务就执行多次。单机场景下，如果开发者在同一个任务方法上同时配置了fixedRate和cron，也会出现两个触发器调用同一个方法的情况。定时任务默认没有分布式锁，多实例跑起来就是灾难。

解决：单机部署基本不用太担心，多实例部署时必须加锁。最简单的方式是让updateStatus的SQL带上状态条件，比如UPDATE reservation SET status = 4 WHERE id = ? AND status = 1，这样即使任务被重复执行，第二次也影响不到已经变更的记录。如果项目里已经有Redis，也可以加一个Redis分布式锁，但毕业设计阶段用SQL条件兜底就足够了。

4.3 时区未配置导致预约时间差8小时

现象：页面显示的预约开始时间是12:00，但数据库里存的是04:00，时间查询全部错位，定时释放也提前触发。

原因：JDBC驱动与数据库服务器时区不一致。MySQL服务器默认使用系统时区（通常是Asia/Shanghai），但JDBC连接串里没有显式指定serverTimezone时，驱动会采用JVM默认时区；如果JVM跑在UTC环境，两边的时间差就产生了8小时偏差。

解决：连接串里统一加serverTimezone=Asia/Shanghai，MySQL服务器这边执行SET time_zone = '+08:00'确认时区。两个地方都要配，只配一边还是会出问题。从那以后，我每次建库第一步就检查时区配置，这个习惯避免了很多莫名其妙的时间错乱，尤其是有定时任务的系统，时区错了会导致整个调度全乱套。

4.4 MyBatis属性名与数据库列名映射失败

现象：查询预约记录时返回的对象列表不为空，但日期字段全是null，其他字段正常，页面表格里时间一列全是空的。

原因：实体类里用了createTime这样的驼峰属性名，而数据库列名是create_time，如果MyBatis没有开启驼峰映射，SQL查询结果就无法自动映射到属性上。这是Java Web项目里最常见的“隐性错误”——代码不报错，数据量也正常，但就是字段值为空。

解决：在application.yml里配置mybatis.configuration.map-underscore-to-camel-case: true，或者在XML的resultMap里逐列手动映射。我更推荐开启驼峰映射，因为省事，但要清楚它只处理“下划线转驼峰”这一种情况。如果列名和属性名差异太大，还是得写resultMap，否则页面渲染时字段全是空的，和“查询无结果”很难区分，排查时会白白浪费大量时间。

4.5 浏览器缓存导致页面状态不更新

现象：管理员把某个座位改成“维护中”，学生刷新页面后看到的还是“空闲”，强制刷新后才能看到新状态，直接怀疑是后端没改到。

原因：浏览器对静态资源做了缓存，管理后台的CSS和JS文件路径没有带版本号，浏览器直接读取本地缓存版本。而页面数据本身是从后端获取的，HTML内容有变化，但依赖的JS逻辑还是旧的，导致状态显示不一致。

解决：在资源引用时加上版本参数，比如style.css?v=20240501，或者在配置类里设置开发环境禁用静态资源缓存。另一个常见做法是在登录后跳转的URL上加时间戳参数，让每次进入首页都是新请求。这个问题的隐蔽性在于本地开发时开着控制台调试，缓存策略和普通访问不同，自己很难发现，等到给别人演示时就复现了。

5. 数据库设计与预约高峰的性能调优

数据库设计直接决定预约系统能撑多大的并发量。这一章围绕三张核心表的结构、索引设计和事务边界展开，这些内容也是答辩时评审老师最容易追问的细节。

5.1 核心表结构：座位表、预约表、用户表的字段设计

先看三张核心表的DDL：

CREATE TABLE seat ( id INT PRIMARY KEY AUTO_INCREMENT, seat_no VARCHAR(20) NOT NULL COMMENT '座位编号', floor_no INT NOT NULL COMMENT '所在楼层', room_no VARCHAR(20) COMMENT '阅览室编号', status TINYINT NOT NULL DEFAULT 0 COMMENT '0空闲 1已预约 2已入座 3暂离', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE reservation ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, seat_id INT NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1已预约 2已入座 3已完成 4超时取消 5用户取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, role TINYINT NOT NULL DEFAULT 0 COMMENT '0学生 1管理员', credit_score INT NOT NULL DEFAULT 100 );

三张表的设计有几处值得展开说明。seat表的status是高频更新字段，查询时经常作为WHERE条件，要加索引。reservation表的status字段是业务状态，真正判断一个座位在某个时间段是否被占用时，要同时过滤status IN (1, 2)，因为已入座同样占用座位。user表里的credit_score是黑名单机制的裁决字段，每次扣分后都要重新查询最新值判断是否低于阈值，不要在扣分前就决定是否加入黑名单，否则并发扣分时可能漏判。

5.2 索引设计：时间冲突查询为什么不能少联合索引

回到第三章那条冲突检测SQL：

SELECT COUNT(*) FROM reservation WHERE seat_id = #{seatId} AND status IN (1, 2) AND start_time < #{endTime} AND end_time > #{startTime}

如果只在seat_id上建索引，MySQL会先根据seat_id过滤出该座位的全部预约记录，再在内存里逐个判断时间区间。当一个座位的历史预约记录积累到几千条时，单次查询耗时就会成倍增长。更合理的做法是在(seat_id, status, start_time, end_time)上建一个联合索引：

ALTER TABLE reservation ADD INDEX idx_seat_time (seat_id, status, start_time, end_time);

联合索引的生效原则是最左前缀，把筛选能力最强的seat_id放在最前面，status虽然区分度不高，但放在第二列可以快速跳过已取消的无效记录，start_time和end_time放在最后用于时间范围的过滤。这里容易误判的是：如果查询条件里跳过了status直接用seat_id和end_time过滤，联合索引就只能用到seat_id这一列，索引效率会明显退化。所以索引列的顺序要和实际查询条件的出现顺序保持一致，不能想当然排列。

5.3 预约高峰的并发控制：乐观锁与事务边界

考试周开放预约的瞬间，请求量可能是平时的几十倍。除了依赖数据库唯一约束兜底，应用层的写法也能减少冲突。预约方法应该设计成短事务，尽快提交释放连接，核心代码如下：

@Transactional public void reserve(Integer userId, Integer seatId, LocalDateTime startTime, LocalDateTime endTime) { int conflictCount = reservationMapper.countConflict(seatId, startTime, endTime); if (conflictCount > 0) { throw new BusinessException("该时段已被预约"); } Seat seat = seatMapper.selectByIdForUpdate(seatId); if (seat.getStatus() != SeatStatus.IDLE) { throw new BusinessException("座位当前不可预约"); } seatMapper.updateStatus(seatId, SeatStatus.RESERVED); reservationMapper.insert(userId, seatId, startTime, endTime, ReservationStatus.RESERVED); }

注意selectByIdForUpdate这个方法的SQL最后带了FOR UPDATE，它会把这一行座位记录锁住，直到事务提交。InnoDB引擎在事务内执行SELECT...FOR UPDATE时，其他事务要修改这行记录会阻塞等待，这样“检查状态”和“修改状态”之间就不会被其他请求插队。代价是吞吐量降低，但在座位预约这种低频高竞争的写场景里，保证数据正确比追求并发量更重要。

关于事务边界，有一个容易被忽略的点：@Transactional只对RuntimeException和Error回滚，对受检异常不会自动回滚。所以“扣信用分失败需要回滚整个预约”这种场景，要么让异常继承RuntimeException，要么在方法内手动调用setRollbackOnly()。我一般选择前者，更直观也更好排查。

6. 进阶技巧：把项目改造成能演示的完整系统

6.1 初始数据准备：用SQL脚本预置演示场景

基础数据在SQL脚本里已经有，但空数据演示起来没有说服力。建议额外追加一段“演示数据”脚本，把一个完整故事线预置好：某学生已预约一个座位但未签到、另一个座位处于已入座状态、一条违约记录接近黑名单阈值。

-- 预置一条已预约但未签到的记录（当前时间-10分钟，签到限制30分钟） INSERT INTO reservation(user_id, seat_id, start_time, end_time, status) VALUES (2, 15, DATE_SUB(NOW(), INTERVAL 10 MINUTE), DATE_ADD(NOW(), INTERVAL 50 MINUTE), 1); UPDATE seat SET status = 1 WHERE id = 15;

执行这段脚本后，不需要等待30分钟就能演示“超时释放”的效果：把ScheduledTask里的检测阈值临时改成1分钟，启动后就能在演示现场看到座位被自动释放，同时该用户信用分被扣减。演示数据必须和实际生产数据分开，我习惯用额外的INSERT来预置，避免修改原有脚本导致基础数据被污染。

6.2 演示路线：三分钟走完预约-签到-释放闭环

推荐按这个顺序操作：

1. 登录管理员账号，进入座位管理，展示所有座位状态和楼层分布
2. 登录学生账号，选中一个空闲座位并提交预约
3. 回到座位管理页面，看到座位状态变成“已预约”
4. 点击签到按钮，状态变成“已入座”
5. 再次预约同一座位，弹出“该时段已被预约”的提示，展示冲突检测效果
6. 演示定时释放：把签到时限改成1分钟，等待一个周期，看到座位自动释放

这个路线覆盖了代码中的几个关键方法：预约时的状态机校验、冲突检测SQL、定时任务的释放逻辑。演示完这三个点，核心功能就都讲到了。不要一上来就讲优化和部署细节，评审老师注意力有限，先把主流程走通比什么都重要。

6.3 部署到服务器前的检查清单

最后一步，如果要把项目部署到云服务器，我按经验列一个最小检查清单：MySQL版本、字符集、时区与本地保持一致；application.yml里数据库地址改用服务器IP而不是localhost；使用外部Tomcat部署时，把打包方式改成WAR并继承SpringBootServletInitializer；端口和安全组的访问规则同步配置。这四条里最容易忽略的是后两条，尤其是外部Tomcat部署，改完打包方式后还要把内嵌Tomcat依赖标注为provided，否则部署上去会冲突。

从那以后，我每次拿到类似的毕业设计项目，都会强制走一遍“建库 → 改配置 → 跑通 → 导入演示数据 → 完整流程演示”的流程，既是为了确认资源可用，也避免在演示现场被评审老师问到无法当场验证的问题。这套Java校园图书馆座位预约系统核心逻辑完整、代码组织清晰，按上面的步骤复现基本不会遇到障碍，希望帮到你。

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