SSM框架下的图书馆预约系统：从数据库设计到并发控制

1. 系统整体拆解：图书馆预约系统的需求与设计思路

1.1 为什么选这个题目，以及它到底解决了什么问题

每年毕业设计选题的时候，"图书馆预约管理系统"总是一个高频选项。很多同学觉得它"常规"，但恰恰是这种看似普通的题目，反而最适合用来完整展示你对软件工程全流程的掌握程度。我见过太多选了"智能推荐购物平台""基于深度学习的某某系统"这类大而全题目的同学，最后由于工作量失控，连基本的功能都没跑通；反倒是踏踏实实做一个图书预约管理系统的人，把需求分析、数据库设计、接口封装、权限控制全流程走了一遍，答辩时讲得清清楚楚，一次性通过。

说回这个系统本身。图书馆预约管理系统的核心痛点很明确：自习座位资源紧张、占座现象严重、管理员难以实时掌握座位使用情况。传统的排队和现场抢座方式效率低，还容易引发矛盾。所以系统要解决的核心问题就是三件事：让读者可以提前查看座位状态并预约，让管理员可以统一管理座位和用户数据，让违约行为有据可查、有规可惩。

这背后其实就是一个标准的管理信息系统（MIS）的缩影，麻雀虽小五脏俱全。涉及用户角色划分、资源状态管理、业务规则约束、数据统计查询。把这个系统的逻辑想透了，以后再做库存管理、会议室预订、实验室排课这类系统，你会发现都是同一套套路，换汤不换药。这也是为什么这种题目在毕设中长盛不衰的真正原因——它足够典型，能考察你完整的基本功。

1.2 角色权限与业务流程全景

先明确系统里有哪几类人，每类人能做什么，这直接决定了后台菜单怎么设计、接口怎么控制权限。这个系统我建议按三个角色来设计。

**管理员（图书馆工作人员）**是权力最大的角色，负责维护整个系统的运行。具体职责包括：对用户账号进行审核和禁用、对阅览室和座位进行增删改查、查看所有预约记录、处理违约申诉、发布公告通知。注意，管理员是"管理"而不是"使用"，他本人不应该参与座位预约，否则会造成管理者和使用者角色混淆。

**注册用户（学生/读者）**是这个系统的主体用户。他们的核心操作链路是：注册登录 → 浏览阅览室与座位 → 选择空闲座位发起预约 → 到馆后扫码或在终端签到 → 使用完毕释放座位。预约会涉及一个关键业务规则：如果超过预约开始时间一定时长（比如30分钟）未签到，系统会自动取消预约并记录一次违约；累计违约达到一定次数（比如3次），该用户在未来一段时间内（比如一周）被限制预约。

**游客（未登录访问者）**能做的事情非常有限，只能查看公告和座位状态总览。想看详细座位图、发起预约，必须登录。这么设计一方面是业务需要，另一方面也天然形成了未登录状态下的权限拦截需求，对应到技术上就是一个拦截器（Interceptor）或者过滤器（Filter）的事。

业务流程上，最核心的是预约链路，我建议画一条主线出来：用户选座 → 提交预约 → 系统校验（座位是否空闲、用户是否有违约限制）→ 生成预约记录 → 用户在预约时段内签到 → 使用完成后手动释放或到点自动释放 → 系统更新座位状态。整条链路的状态流转必须清晰，因为状态字段设计得好不好，直接影响后面写SQL的复杂度和代码的可维护性。

1.3 SSM框架选型的真实理由，以及为什么不选Spring Boot

现在很多同学一上来就习惯用Spring Boot做新项目，觉得配置简单、起步快。但作为毕业设计，我反而推荐你选择SSM（Spring MVC + Spring + MyBatis）这种经典组合。这里面的考虑很多同学可能没细想过。

第一，SSM框架组合是过去十多年Java Web开发的主流方案，大量的企业老项目至今还在用。你把这个组合吃透了，去实习或者入职后接手老项目，不会两眼一抹黑。第二，SSM里大量使用XML配置和手动装配，它能逼着你把Spring的IoC容器、AOP切面、SpringMVC的请求流转、MyBatis的SQL映射这些底层机制搞明白。使用Spring Boot的时候，这些细节多数被自动配置掩盖了，出了问题反而不容易排查。第三，从答辩角度来看，SSM项目的配置文件和代码结构能给评委提供更丰富的提问点，你展示自己对配置逻辑的理解，比展示"脚手架自动生成的代码"更有说服力。

当然，这里要说明白：并不是说Spring Boot不好，而是说在毕业设计这个场景下，SSM的学习价值和展示价值更高。如果你的指导老师明确要求可以用Spring Boot，那你当然可以迁移——SSM的核心思想（分层、IoC、ORM）在Spring Boot中照样适用。后面讲代码结构的时候你会发现，Controller、Service、Mapper这种分层方式在两个框架下是完全一致的，知识完全通用。

2. 数据库设计与表结构详解

2.1 五张核心表，以及每张表的设计理由

数据库设计是答辩时评委最容易深挖的部分，也是整个系统数据流的地基。我的建议是不要贪多，把核心业务表做扎实，比堆砌十张没用的表强得多。这个系统的核心表我推荐如下五张，外加一张公告表可选。

用户表（user）：字段包括用户ID（主键）、用户名、密码、真实姓名、学号/工号、手机号、角色（1表示管理员，0表示普通用户）、状态（0禁用，1正常）、注册时间、违约次数。密码字段我建议存储MD5加密后的密文，而不是明文。这里多说一句：真实项目中一般会用加盐加密（比如BCrypt），但毕设中用MD5加密已经能体现你的安全意识到位了，答辩时你能说清楚"为什么不能存明文"就是加分项。

阅览室表（reading_room）：字段包括房间ID、房间名称、位置描述、可容纳座位总数、开放时间（如08:00-22:00）、状态。为什么需要单独一张阅览室表？因为座位一定是归属于某个物理空间的，没有这张表，座位信息就会缺少归属维度，系统后期的统计功能（比如"哪个阅览室使用率最高"）就做不出来。

座位表（seat）：字段包括座位ID、所属房间ID（外键）、座位编号（如A-101）、座位状态（0空闲，1已预约，2已签到使用中，3维修中）。注意座位表里不应该存"预约人是谁"这种业务信息，那应该由预约记录表来挂，否则一个座位多人预约时数据就会乱。座位表只管"物理状态"，这是数据库设计里"单一职责"的体现。

预约记录表（reservation）：这是整个系统业务逻辑最密集的表。字段包括预约ID、用户ID（外键）、座位ID（外键）、预约日期、开始时间段、结束时间段、预约创建时间、状态（0已预约，1已签到，2已释放/完成，3已取消，4已违约）、签到时间、取消时间。设计这张表的时候一定要想清楚：预约的是"日期+时间段"的组合，所以时间字段建议分开存日期、开始时间、结束时间三个字段，这样后续做"查询某天某个时间段的空闲座位"这种SQL时，条件判断会更清爽。

违约记录表（violation）：字段包括违约ID、用户ID（外键）、关联的预约ID、违约类型（如超时未签到）、违约时间、处理状态。这张表的价值在于把"违约行为"从预约记录里剥离出来独立管理。这样管理员可以单独查询"谁违约最多"，用户在个人中心也能看到自己的违约历史，后续做"累计3次禁用一周"这种业务规则时，直接查这张表统计就行，非常方便。

2.2 表关系与字段类型的关键细节

表之间的关系很清晰：用户与预约记录是1对多，座位与预约记录是1对多，阅览室与座位是1对多。一个用户可以有多个预约记录，一个座位在不同时间段也可以被多个预约记录关联（注意，物理上座位只有一张，但预约记录表里可以通过"日期+时间段"字段来实现同一座位不同时段的多次预约）。

这里有一个非常容易踩坑的细节：座位表里如果只保存"当前状态（0空闲/1预约/2使用中）"，那么同一座位在一天的不同时间段是被谁预约的，座位表自己根本不知道，必须联合预约记录表才能回答这个问题。所以实现时，座位表状态可以作为"缓存字段"方便列表展示，但真正的业务判断（比如"9点到10点这个座位是否可约"）一定要去查预约记录表，在代码里做好一致性维护。我在第一次做这个系统的时候，就是因为图省事只查座位表状态，结果出现了同一时间段被两个用户重复预约成功的bug，后来才补上的这个逻辑，希望你别再踩一遍。

字段类型方面，主键统一用自增的INT，简单可控；日期时间字段用DATETIME；状态字段用TINYINT；用户名、姓名这类短文本用VARCHAR(20-50)；备注性字段用VARCHAR(255)就够。唯一索引方面，建议在预约记录表上加一个联合唯一索引（用户ID+预约日期+开始时间段），防止同一个用户在同一时间段重复提交预约。

CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(20) NOT NULL, `password` VARCHAR(64) NOT NULL COMMENT '存储MD5密文', `real_name` VARCHAR(20) DEFAULT NULL, `student_no` VARCHAR(20) DEFAULT NULL, `phone` VARCHAR(11) DEFAULT NULL, `role` TINYINT DEFAULT 0 COMMENT '0-普通用户, 1-管理员', `status` TINYINT DEFAULT 1 COMMENT '0-禁用, 1-正常', `violation_count` INT DEFAULT 0, `register_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `seat` ( `id` INT NOT NULL AUTO_INCREMENT, `room_id` INT NOT NULL, `seat_no` VARCHAR(20) NOT NULL, `status` TINYINT DEFAULT 0 COMMENT '0-空闲, 1-已预约, 2-使用中, 3-维修中', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.3 为什么建议加上"时间段"字段而不是只用具体时间点

这是这个系统设计里我认为最值得展开的一个点。很多同学第一次做预约系统，预约记录里只有一个预约时间（比如"2025-01-06 14:00:00"），签到也只有一个签到时间，看起来好像也能跑通，但你细想就知道问题大了：图书馆一座位的使用是以小时为单位连续进行的，比如"上午8点到10点"和"上午9点到11点"这两段预约，在时间上是重叠冲突的（9点到10点重叠）。如果你的表结构里只有"预约时间"这个创建时间字段，数据库根本无法判断这个冲突。

我的做法是将预约抽象为"日期+时间槽"模型。具体而言，把一天按小时切成多个时间段（也可以让管理员自定义时间段的粒度，比如上午、下午、晚上三个大时段），用户预约时选择某个日期下的某个时间段，预约记录里保存的是日期（DATE类型）和开始、结束的TIME类型字段。判断座位是否可约，就是查预约记录表里有没有"同一天 + 时间段有交集 + 状态为已预约/已签到"的记录。

SELECT COUNT(*) FROM reservation WHERE seat_id = #{seatId} AND res_date = #{date} AND #{beginTime} < end_time AND #{endTime} > begin_time AND status IN (0, 1)

这段SQL里两个条件（#{beginTime} < end_time AND #{endTime} > begin_time）就是标准的区间重叠判断逻辑。你在答辩的时候能把这个写出来，然后解释一句"两条预约在时间线上有交集就说明时间冲突"，评委基本就不会在这个点上再追问什么。至于时间段的粒度是半小时、一小时还是半天，这是一个灵活配置项，可以在系统管理里做一个时间粒度配置，默认按小时切就行。

3. 核心功能实现与关键代码解析

3.1 登录与权限控制：拦截器配置和密码加密

登录功能是每个系统的门户，也是最基础的能力展示点。我使用的方案是典型的Session + 拦截器组合。用户登录成功后，把用户对象放入Session，定义一个字符常量如"LOGIN_USER"作为Session的Key。然后配置一个SpringMVC的拦截器，对所有请求路径进行拦截检查，未登录的用户一律跳到登录页。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object user = session.getAttribute("LOGIN_USER"); if (user == null) { // 未登录：重定向到登录页 response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

然后在SpringMVC的配置文件中注册这个拦截器，并配置拦截路径。这里有一个细节：登录请求本身、注册请求、静态资源（CSS/JS/图片）必须排除在外，否则就会死循环跳转。另外，管理员专属接口和普通用户接口如果分开，可以在拦截器里再判断角色，或者再单独配一个管理员权限的拦截器。我建议用HandlerInterceptor配合路径规则搞定角色控制这种事，少用注解，因为SSM项目里注解方式虽然也有（@AuthRequired之类），但写起来不如路径规则直观，答辩也不好讲。

密码加密方面，我使用JDK自带的MessageDigest对密码做MD5处理后再入库。这里要注意编码问题，MessageDigest.getInstance("MD5")后，对字符串做getBytes("UTF-8")进行摘要运算，再把结果转成十六进制字符串存储。每次登录验证时，把用户输入的密码做同样处理，再和数据库里的密文比较。哪怕答辩时被问到"MD5有碰撞风险怎么办"，你只要能说"真实项目会用加盐方案，我这里出于课程设计演示目的用MD5，已经比明文要安全"，这个回答就圆得过去。

3.2 座位预约核心业务：事务控制与状态校验

预约是系统里业务逻辑最重的功能，也最容易出并发问题。我先说最理想的完整流程，再给出代码。第一步，接收前端传来的座位ID、预约日期、时间段参数；第二步，做后台二次校验（前端校验不可信）：查询座位是否存在、当前时间是否在可预约范围内、该用户是否有未解除的违约限制；第三步，通过SELECT ... FOR UPDATE锁定座位或预约记录，查询这个时间段是否已被预约（悲观锁方案）；第四步，如果空闲，插入预约记录，同时把座位状态改为"已预约"；第五步，提交事务。

这里我用了悲观锁，原因是毕设场景下没必要上Redis分布式锁或者乐观锁版本号这种高并发方案，FOR UPDATE足够简单且应对并发校验很有效。你也许会觉得用乐观锁更"优雅"一些，但你要想清楚：座位预约的核心矛盾是"同一时间段只能被预约一次"，悲观锁直接在数据库层面锁行，SQL逻辑直观，答辩时你能把锁机制讲清楚，这已经是亮点。

@Service public class ReservationServiceImpl implements ReservationService { @Autowired private SeatMapper seatMapper; @Autowired private ReservationMapper reservationMapper; @Autowired private ViolationMapper violationMapper; @Transactional(rollbackFor = Exception.class) @Override public boolean reserveSeat(Integer userId, Integer seatId, Date resDate, String beginTime, String endTime) { // 1. 校验座位存在且状态可用 Seat seat = seatMapper.selectById(seatId); if (seat == null || seat.getStatus() == 3) { throw new BusinessException("座位不存在或处于维修中"); } // 2. 查询冲突预约：锁定相关记录防止并发重复预约 int conflictCount = reservationMapper.selectConflictCount(seatId, resDate, beginTime, endTime); if (conflictCount > 0) { throw new BusinessException("该时间段已被预约，请选择其他时间"); } // 3. 检查用户违约次数 User user = userMapper.selectById(userId); if (user.getViolationCount() >= 3) { throw new BusinessException("违约次数已达上限，暂时无法预约"); } // 4. 插入预约记录 Reservation reservation = new Reservation(); reservation.setUserId(userId); reservation.setSeatId(seatId); reservation.setResDate(resDate); reservation.setBeginTime(beginTime); reservation.setEndTime(endTime); reservation.setStatus(0); // 已预约 reservationMapper.insert(reservation); // 5. 更新座位状态为已预约 seatMapper.updateStatus(seatId, 1); return true; } }

注意@Transactional必须加在Service实现类的public方法上，事务管理要确保预约记录插入和座位状态更新要么一起成功要么一起回滚。这里有个容易忽略的坑：如果MySQL默认事务隔离级别是REPEATABLE_READ，而且在冲突查询与插入之间没有行锁保护，高并发下仍然可能出现幻读（两个事务同时查到0冲突，然后都插入成功）。所以我还是建议在冲突查询SQL里加上FOR UPDATE锁定预约记录表的相关行（或者锁定座位行），形成"先锁后查"的完整保护。

签到和释放的逻辑相对简单。签到时，将预约记录状态从0改为1，同时把座位状态从"已预约"改成"使用中"。释放时，把预约记录状态改为2，座位状态改回0。这两步操作同样放在一个事务里，保持一致。至于预约起始时间自动判定违约，可以用一个定时任务（Spring的@Scheduled）每分钟扫描一次预约记录表，把"开始时间早于当前时间20分钟且状态仍为0"的记录标记为违约。定时任务在少数不熟悉这个功能的毕设系统里是个加分项，你可以自己加上。

3.3 后台管理：统计报表与状态维度管理

后台管理模块的常见误区是"堆表格"。有些同学为了显得功能多，把用户表、座位表、预约表全部原样展示出来，结果看起来就是一个数据库管理界面，没有任何信息提炼。我建议你做这几个有说服力的管理功能：座位的批量增删（支持通过房间号批量生成多个座位号）、预约记录的条件筛选（按日期、用户、状态组合查询）、用户禁用/解禁、违约次数清零、按阅览室统计当日利用率。

统计功能是答辩时很有展示价值的一块。你可以写一个简单的统计查询，比如"查询最近7天每天的预约总数"。

SELECT DATE_FORMAT(res_date, '%Y-%m-%d') AS day, COUNT(*) AS total FROM reservation WHERE res_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND status IN (0, 1, 2) GROUP BY day ORDER BY day

在后台界面，可以用ECharts或Chart.js把这个统计结果画成折线图，非常直观。ECharts在毕设中使用很普遍，引入方式也很简单：在JSP页面里<script src="echarts.min.js"></script>，然后写一个option对象，用AJAX从后端取数据填充。别忘了告诉评委：这不是硬编码的数据，是从预约记录表实时统计出来的，数据库里数据一变图表就跟着变。

// 前端JSP页面中通过AJAX加载统计接口 $.ajax({ url: '/admin/statistics', type: 'GET', dataType: 'json', success: function(result) { var chart = echarts.init(document.getElementById('chart')); chart.setOption({ title: { text: '近7日预约趋势' }, xAxis: { type: 'category', data: result.days }, yAxis: { type: 'value' }, series: [{ type: 'line', data: result.counts }] }); } });

实操时最常用的配置是采用前后端分离思路来做页面，但毕设多数还是JSP + JSTL。JSP的好处是服务端渲染简单，结合c:forEach标签循环表格数据非常方便，而且不用额外搭建前端工程。缺点是页面逻辑耦合较大，但毕设够了。如果你对前端比较熟，也可以把Vue和AJAX引进来，页面更现代；不过需要注意的是，SSM+JSP是"最稳"的方案，不容易出跨域或者打包部署问题。

3.4 公告管理、个人中心与辅助功能

除了核心预约流程，系统还需要几个辅助模块来保证完整性。公告管理是管理员发布通知的入口，用户在首页和登录后能看到最新公告列表。个人中心展示用户的基本信息、预约历史（进行中、已完成、已取消）、违约记录，并提供修改密码和退出登录功能。这些模块都是标准CRUD，实现难度不大，但要注意两点：一是列表分页，二是安全访问（比如个人中心只能查自己ID的数据，不能通过修改URL参数查别人的数据）。我在第一次做的时候安全意识不够，个人中心的数据查询居然没有限制用户ID，被老师点出来"越权访问"的问题，现在回想起来非常惭愧，这个点你在设计和答办时也要主动留意。

这里我想插一句对"源码学习"的看法。每年都有大量同学在这个阶段从网上下载各种"SSM图书馆管理系统源码.zip"，然后导入IDE发现一堆报错。核心问题在于：下载下来的项目版本五花八门，有的用的Spring3，有的是4，有的是Maven项目有的是传统Web项目，导入方式完全不同；很多源码缺少说明文档，数据库脚本和配置步骤都埋在压缩包深处没人告诉你；一些源码是"半成品"，看起来页面齐全，但是底层事务、拦截器、异常处理都是空的。所以如果你准备参考开源源码或者购买的模板项目，我强烈建议你至少花一个晚上的时间，把下面第4节梳理的导入配置流程完整走一遍，并且亲手把核心业务代码（比如预约冲突校验、定时违约处理）重写一遍。抄一遍代码解决的只是"完成"，重写一遍解决的才是"理解和答辩"。

4. 项目部署运行与源码使用指南

4.1 开发环境选型与版本兼容建议

这里是很多同学导入项目后第一个翻车现场。我先给出一套我亲测稳定、兼容性极好的环境组合，你照着准备，能省掉大量折腾时间。

• JDK版本：JDK 1.8（也叫8）。不要用JDK 11、17、21，因为老版本Tomcat和Spring对这些新JDK的支持和兼容存在很多坑，而且很多教学资料默认JDK8。
• MySQL版本：MySQL 5.7。8.0也行，但要注意连接驱动版本和时区设置问题；如果你不太熟悉，优先5.7。
• Tomcat版本：Tomcat 8.5或9.0。这两个版本兼容Servlet 3.1/4.0，SSM项目运行没有任何问题。
• Maven版本：Maven 3.6左右。注意Maven配置阿里云或华为云镜像仓库，否则下载依赖依赖会慢到怀疑人生。
• IDE：IDEA（推荐）或Eclipse。IDEA中导入Maven项目比较顺手，Spring配置文件之间的跳转和XML校验也更智能。

如果你的项目是用Maven管理的（强烈建议用Maven），pom.xml里核心依赖版本大致是这样一套组合，这几个版本搭配经过了大量项目验证，冲突较少。

<properties> <spring.version>5.2.12.RELEASE</spring.version> <mybatis.version>3.5.6</mybatis.version> <mybatis-spring.version>2.0.6</mybatis-spring.version> </properties>

顺带提醒一下：mybatis-spring版本要和mybatis、spring-jdbc的版本匹配，否则启动会报MapperScannerConfigurer相关的诡异错误。这个错误本质上是版本之间接口签名变化导致的，排查起来非常消耗时间，最简单的方式就是锁定上面这组版本。

4.2 导入项目到IDEA的完整步骤

先把数据库脚本执行了。找到SQL脚本文件（一般叫library_db.sql或init.sql），用Navicat或命令行执行，生成数据库和表结构。然后确认脚本里有没有预置测试数据，如果没有，建议手动插入几条测试账号数据（一条管理员，两条普通用户），方便后续测试登录。顺便把密码的MD5值也准备好，比如123456的MD5是e10adc3949ba59abbe56e057f20f883e，你不会想在数据库里直接更新成明文密码再让系统读取，那会导致登录永远失败。

打开IDEA，选择File -> New -> Project from Existing Sources，选中项目的pom.xml文件，按Import Maven Project向导走完。这里有个常见的坑：如果项目不是Maven结构而是传统Web结构（有.classpath但没pom.xml），那就用File -> Open直接打开整个目录，然后在Project Structure里把编译输出目录、Web Facet、Artifacts手动配好。两种方式的差别在于你拿到的源码是哪一种结构。我的建议是：如果你下载的源码是Maven工程，就别自己改成传统结构；反之亦然，别在两种结构之间来回折腾。

导入完成后，修改数据库连接配置文件。这个文件在SSM项目中一般是jdbc.properties，位于resources目录下。重点检查数据库地址、账号、密码以及驱动类。

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的数据库密码

如果你在jdbc.url里少了useSSL=false和serverTimezone=Asia/Shanghai，MySQL 8.0可能直接报时区错误或SSL连接警告，这都是历届学弟学妹踩过很多次的坑了，直接照抄上面配置就行。另外提醒一句：MySQL 8.0无论如何都不用com.mysql.jdbc.Driver而是用com.mysql.cj.jdbc.Driver，这一点和5.7不一样，改错必报ClassNotFoundException。

4.3 启动调试全过程与常见启动错误

配置完数据库后，在IDEA里配置Tomcat。打开Run -> Edit Configurations，点击加号选择Tomcat Server Local，在Deployment选项卡里添加exploded的Artifact（比如library_management_war_exploded），设置Application context为/library或者干脆/，然后Startup/Connection里的端口一般默认8080，如果端口被占用就改成一个不常用的端口比如8081。

启动Tomcat时，控制台是信息最密集的地方。最常见的错误从日志里就能看出端倪。

如果控制台出现org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)，说明MyBatis的Mapper接口和Mapper XML文件没绑定上。原因基本是两种：一是MapperScannerConfigurer扫描的包路径和Mapper接口所在的包路径不一致；二是mybatis-config.xml里<mapper resource="">配置的路径写错了，或者根本就没配置。整理一下思路：这类报错的本质是Spring在容器里注册了Mapper接口的代理Bean，但它找不到对应的SQL语句。你还要注意resources目录下Mapper XML文件的目录层级是否和Java的包目录一一对应，如果你的Mapper接口在com.example.dao包，那么XML文件的路径最好也在resources/com/example/dao下。

如果数据库连接相关报错，比如Cannot create PoolableConnectionFactory，那就是JDBC连接有问题，多半是用户名密码错误、IP端口不通、驱动类不对，按这个顺序排查。

如果出现java.lang.ClassNotFoundException: org.springframework.web.servlet.DispatcherServlet，那就说明SpringMVC的jar包没有打进Artifact的WEB-INF/lib里。解决办法是File -> Project Structure -> Artifacts里，把Available Elements中的Library jars添加进去，或者在Output Layout右键Put into Output Root。这种问题常在从非Maven项目导入的时候出现。

我把启动阶段最典型的错误和定位思路整理成了一张速查表，贴在正文里，方便你对照排查。

4.4 从源码到答辩演示：一份数据准备清单

项目启动成功之后，不要急着开始"截图给老师看"。我真心建议你把演示数据准备好，这决定了答辩时演示环节是否顺畅。管理员账号一个（用户名admin，密码123456），普通用户两个（用户名student1/student2）。

座位数据要足够典型：至少两个阅览室，每个阅览室最好有8到15个座位，座位编号要有规律（比如101-1、101-2），这种命名方式让评委在界面上很容易看懂"哪个房间哪个座位"。预约记录准备几条不同状态的：一条"已预约"（状态0）、一条"已签到使用中"（状态1）、一条"已完成"（状态2）、一条"已取消"（状态3），最好还有一条违约记录。这样你给评委演示的时候，每一种状态都能点开给老师看，不用现场临时操作去等时间流逝让记录变状态。这是经验之谈，很多人演示时发现所有预约记录全是"已预约"，一时改不了状态，场面会有点尴尬。

另外一个很加分的小操作是准备好两个浏览器窗口或者两个不同浏览器：一个用管理员登录，一个用普通用户登录。这样现场演示时，你能表演"学生端预约一个座位 → 管理员端立刻看到这条预约记录"的实时联动效果，比单窗口切换账号节省时间，也更能说明系统是真实两端联动的。

5. 常见问题排查与避坑笔记

5.1 JSP页面取不到数据？三层结构传参细节

运行中非常常见的一个问题：页面能打开，但表格是空的，或者显示${list}没有被解析。这个通常是EL表达式或者JSTL的问题。

SSM + JSP的联调里，Controller返回的视图名对应JSP页面，ModelAndView里塞的数据由JSP用EL表达式取出。要注意几个细节：第一，JSP页面开头必须有<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>，否则c:forEach不可用；第二，isELIgnored属性如果被设置成true，EL表达式直接不解析，输出原样字符串；第三，从Controller塞到Model里的key要和JSP里写的一致，比如Controller里放了model.addAttribute("reservationList", list)，那么JSP里必须用${reservationList}，拼错字母是典型的低级错误。

还有一个排查技巧：先用${reservationList}的fn:length或者直接在页面上输出${reservationList}看有没有显示对象引用，如果对象存在，再检查是循环标签的问题还是字段名的问题。如果字段名和实体类的getter对不上（比如数据库字段是res_date，实体类属性是resDate），MyBatis开启驼峰映射配置之后可以自动转换，如果没有开启或者配置写错，那查出来的数据会有一堆null。

在mybatis-config.xml中开启驼峰映射的配置是这样：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

5.2 并发预约冲突和超时未签到，两个核心难点怎么应付

并发冲突和自动违约这两个点，在我看来是这个系统里最有技术含量、也最适合在答辩时讲深讲透的内容。

先说并发冲突。我先提一个方案：应用层同步锁不可靠。如果你在Controller或Service中简单用synchronized关键字锁住方法，确实可以保证单机环境下的串行化，但在真实的分布式部署中一个服务有多个实例，同步锁毫无作用。不过在答辩场景下，你的系统部署在单台Tomcat，用synchronized其实也能工作，但面试或答辩老师通常更期待听到数据库层的方案。我在3.2节已经给出了用SELECT ... FOR UPDATE做行锁的SQL思路，你还可以被追问时补充一个乐观锁方案：在座位表或预约记录表加一个version字段，更新时校验版本号。这两种方案的取舍可以简单概括：写操作冲突频率高，用悲观锁；冲突频率低，用乐观锁。预约系统午间高峰期冲突不低，所以我用悲观锁。

再说超时未签到自动违约。最草率的实现方式是在用户查询座位或管理员查记录时顺带判断"有没有超时的记录"，然后改状态。这种做法的问题在于状态更新非常被动，如果一直没人查询，过期记录永远在那里。正规做法是使用定时任务。SSM项目里在Spring配置文件开启<task:annotation-driven/>，然后在Service类上写一个带@Scheduled(cron = "0 */5 * * * ?")的方法，每5分钟扫描一次预约记录表并更新超时的记录。

@Component public class ReservationTask { @Autowired private ReservationMapper reservationMapper; @Scheduled(cron = "0 */5 * * * ?") public void autoCancelExpiredReservations() { Date now = new Date(); List<Reservation> expiredList = reservationMapper.selectExpiredReservations(now); for (Reservation r : expiredList) { reservationMapper.updateStatus(r.getId(), 4); // 标记为违约 userMapper.increaseViolationCount(r.getUserId()); seatMapper.updateStatus(r.getSeatId(), 0); // 座位释放 } } }

注意这个定时任务里涉及三个表的更新，应该加上事务控制。在autoCancelExpiredReservations方法上标注@Transactional(rollbackFor = Exception.class)，保证同一个用户的多条记录处理不会出现"预约状态改了但违约次数没加"这种数据错乱。另外，定时任务的执行时间间隔不需要太短，5分钟或10分钟一次足够，每分钟一次对数据库压力偏大，这也算一个可以跟老师讲的工程权衡。

5.3 关于源码的合理使用：怎么把别人的项目变成自己的

最后聊聊一个比较现实的问题。标题里写着"附源码"，很多同学下载了源码，却不知道怎么把别人的东西合理转化成自己能讲清楚的东西。我见过太多学生在答辩时拿着网上下的项目，老师问他某个页面是怎么实现数据展示的，他支支吾吾答不上来，最后分数惨淡。

我的建议分三步走。第一步是改造而非照抄。不要拿源码直接启动然后截图，这只是"运行"了一个项目，完全没有变成你的能力。你要把核心代码自己重新写一遍，改表结构、改类名、改页面样式，至少做到不看源码自己能把预约流程写通。如果有时间，把原来的"管理员审核"模式改成"预约即生效自动签到"模式，功能变了，逻辑就很难说是抄的了。第二步是准备技术问答清单。把代码中每块核心功能自己给自己讲一遍：这段代码用到什么设计模式、为什么这里返回JSON字符串而不是转发页面、这个SQL为什么用LEFT JOIN不用INNER JOIN，想清楚这些，答辩提问环节才有底气。第三步是做项目笔记。把你踩过的每一个坑记录下来，包括报错信息、排查思路、最终解决方案。这些笔记不但能帮助你在答辩前复习，更能成为你博客论文或者项目文档的素材。

就拿"图书馆预约管理系统"这个项目来说，网上的源码质量参差不齐，有些版本甚至带着病毒或后门代码，这也是一些同学导入项目后出现奇怪弹窗或文件被加密勒索的原因。如果你在未知渠道下载了源码，强烈建议先杀毒，再检查pom.xml或lib目录下有没有奇怪的第三方依赖。我遇到过有同学下载的"集成包"里被塞了挖矿程序，CPU占用率一直99%，排查了半天才发现是源码包里面的问题。踏踏实实用官方Maven仓库依赖，不盲目引入不明来源的jar包，这个习惯从毕设阶段就应该养成。

5.4 答辩前的功能演示脚本和时间控制

答辩演示环节比多数同学想象的重要得多，认真准备一套演示脚本，效果比临场随机演示好太多了。我的建议是整体演示控制在8到10分钟，不要贪多。开场先花一分钟展示系统整体界面，介绍角色和核心功能；然后两分钟演示学生端的完整预约流程——查座位、选时段、提交预约、查看预约记录；再用两分钟切换到管理员端，展示用户管理、座位管理和查看预约记录；剩下三分钟展示统计图表和公告发布这两个"亮点功能"，最后留一分钟给老师提问。

演示时的设备和数据准备也有讲究。最好使用本机环境演示（IDEA里直接启动），不要用云服务器或临时部署到远程，因为现场网络不稳定会出各种状况。数据库里把演示数据处理好，不要有敏感或奇怪的测试数据。提前把Tomcat启动好，IDEA保持打开状态，模拟器或浏览器都准备好，减少现场切换时间。另外建议准备一份项目的演示视频备份在U盘里，万一现场系统挂了可以放视频应急。这些都是实际答辩现场最容易忽略的细节，提前花20分钟准备，就能避免当场翻车。

最后我个人的体会是：无论是毕业设计还是以后工作里的项目，遇到的每一个报错都是最好的学习机会。报错信息就是系统在告诉你它哪里不舒服，你按照日志一层层排查下去，技术能力就是这样一点点堆起来的。图书馆预约系统看起来功能不多，但只要你把需求分析、表结构设计、事务控制、定时任务、权限拦截这一整套完整走下来，你对Java Web开发的理解和独立解决问题的能力都会上一个台阶。祝每位同学都能顺利通过答辩。