简介：一套基于SSM框架的自习室座位管理系统完整源码与文档，面向毕业设计、课程设计及期末大作业场景。系统涵盖用户登录验证、座位预约、使用状态跟踪、历史记录查询等模块，针对自习室座位分配不均、利用率低的问题给出完整实现方案。资源包共400个文件，大小8.49MB，包括95个Java后端源码、40个Vue前端页面、162个SVG图标资源，以及SQL脚本、XML配置、启动脚本和项目文档等，结构清晰便于直接部署或二次开发。文档部分包含需求分析、设计思路、功能模块划分、数据库表设计和界面设计说明，SQL脚本覆盖学生、座位、预约信息等核心表，配套README提供环境搭建与运行指南。目前已有42人学习/下载，适合需要快速完成SSM项目实践或了解典型管理系统开发流程的开发者参考。

1. 这不是又一个座位预约Demo：SSM自习室座位管理系统到底交付了什么

SSM（Spring + SpringMVC + MyBatis）是Java后端课设和毕业设计里出现频率最高的一套组合，而自习室座位管理系统又是这个组合下面最典型的业务选题——有明确实体关系、有状态流转、有并发冲突点，正好覆盖了SSM的核心考察面。这份资源不是单薄的“能跑就行”的示例代码，而是把前后端页面、业务逻辑、SQL脚本和设计文档都打包在一起了的完整交付物。你拿到的不是一段孤零零的Controller，而是一整条可以从登录、选座、签到走到黑名单管理的业务闭环。适合两类人：一是做SSM课程设计或期末大作业需要一份能讲清楚设计思路的参考实现的学生；二是想快速上手SSM整合流程、想知道真实课设项目里事务、拦截器、动态SQL到底怎么用的初学者。下面我按自己拆项目的习惯，从环境、表结构、核心链路到踩坑点，把这份源码完整过一遍。

2. 先把项目跑起来：JDK/Maven/Tomcat/MySQL的版本对齐与启动步骤

拿到一份SSM源码，第一件事不是读代码，而是让项目先启动。这一步卡住的人最多，而且绝大多数不是代码问题，是环境版本问题。这个项目是标准的SSM结构，依赖Spring、SpringMVC、MyBatis三个核心库，外加MySQL驱动、Jackson（JSON序列化）、JSTL标签库，打包方式用Maven管理。下面是我整理过的版本组合，照着配基本不会出问题。

2.1 版本清单：为什么是这套组合

建议直接用下面这张表对齐环境，这是我在实际跑这个项目时验证过的组合：

需要特别强调的是JDK版本。我见过不少同学直接用电脑上最新的JDK 17去开SSM项目，一启动就报IllegalAccessError，原因是Spring早期版本对JDK模块系统的兼容性不好。这个项目用的是Spring 5.x，在JDK 8下没有任何问题。如果你电脑上装的是新版JDK，建议单独装一个JDK 8，在IDEA的Project Structure里给这个项目指定8，Maven的编译器级别也同步改成8。

2.2 导入与启动：IDEA里的完整操作路径

假设你已经把压缩包解压了，目录里应该有一个完整的Maven工程结构（带pom.xml的那个目录）。打开IDEA后按下面步骤操作：

# 1. 在IDEA里选择 File -> Open，选中解压后的根目录（包含pom.xml的层级） # 2. 等待Maven自动导入依赖，首次导入会下载大量jar包，建议配阿里云镜像

如果Maven下载依赖非常慢，在settings.xml里加上阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

镜像配置对国内网络环境几乎是必需品，不加的话光下载spring-webmvc、mybatis-spring这一串依赖就能等半小时。配好镜像后，IDEA右侧Maven面板刷新，等依赖下载完成，项目不报红就说明依赖层面没有问题了。

然后启动Tomcat。这个项目用的是传统war包方式，不是SpringBoot内嵌Tomcat，所以需要配置外部Tomcat。在IDEA里点Run -> Edit Configurations，新建一个Tomcat Server -> Local，在Deployment选项卡里把项目以war exploded方式添加进去，Application context建议设为/studyroom。这个上下文路径后面访问页面、调接口都要用到，记好它。

2.3 数据库配置：先改jdbc.properties再启动

启动前必须先把数据库连接改对。项目里有一个jdbc.properties文件，一般是这个内容：

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

这一段有三个容易踩的点：第一，MySQL 8.0以上要把driver换成com.mysql.cj.jdbc.Driver，同时连接的jar包要用mysql-connector-java的8.x版本；第二，连接串末尾的serverTimezone=Asia/Shanghai是MySQL 8.0必带的，不写会报连接超时或时区错误；第三，study_room这个数据库名要和项目doc目录下的SQL脚本里创建的库名一致，如果脚本里建库时用了别的名字，要么改脚本，要么改这里。

数据库准备好之后，用Navicat或命令行执行项目里的study_room.sql，表结构和初始化数据（管理员账号、测试座位）都会自动建好。然后启动Tomcat，浏览器访问http://localhost:8080/studyroom/login.jsp，能看到登录页就说明环境这关过了。

2.4 启动失败的快速定位顺序

如果启动报错，别慌，按这个顺序排查：先看Tomcat的catalina.out日志尾部，有没有BeanCreationException或ClassNotFound；再看IDEA控制台的红色报错信息里的Caused by，绝大部分SSM启动失败都是数据源没连上或Mapper扫描不到；最后检查applicationContext.xml里这两行配置是不是和你的包名对得上。

<!-- 扫描Service层 --> <context:component-scan base-package="com.studyroom.service"/> <!-- 扫描Mapper接口 --> <mybatis:scan base-package="com.studyroom.mapper"/>

这两行里的com.studyroom要根据源码里的实际包名改，很多僵尸项目报org.springframework.beans.factory.NoSuchBeanDefinitionException，原因就是扫描路径写死了别人的包名。到这里，项目已经能跑起来了，下一步我们从数据层面看看这个系统的骨架。

3. 拆开四张核心表：座位状态、预约记录与黑名单的字段设计

自习室座位管理系统的业务其实不复杂，核心就四件事：用户登录、查座位、预约座位、处理违约。对应的数据库表也就四张：学生表（或者叫用户表）、座位表、预约记录表、黑名单表。把这四张表的字段设计看懂了，整个系统的业务逻辑就懂了一半。

3.1 用户表与座位表：基础数据怎么建

用户表保存学生的基本信息，座位表保存自习室每个座位的实时状态，两者之间没有直接外键，靠预约记录表关联。这个设计是课设项目的标准做法，没有过度设计，也方便答辩时解释。

CREATE TABLE `student` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `student_no` VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', `name` VARCHAR(50) NOT NULL, `password` VARCHAR(64) NOT NULL COMMENT 'MD5或BCrypt加密后的值', `phone` VARCHAR(20), `credit` INT DEFAULT 100 COMMENT '信用分，爽约扣分', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

学号用UNIQUE约束保证唯一，这是登录时的业务主键。credit信用分和黑名单表配合，是后面业务扩展的关键字段，答辩时老师问“系统怎么防止恶意占座”就靠它回答。

座位表要重点看status字段，它直接驱动整个预约流程的状态变化：

CREATE TABLE `seat` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `room_no` VARCHAR(20) NOT NULL COMMENT '自习室编号，如A101', `seat_no` VARCHAR(20) NOT NULL COMMENT '座位编号，如A101-01', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0空闲 1已预约 2使用中 3维护中', `version` INT DEFAULT 0 COMMENT '乐观锁版本号，可选' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

座位状态用了数字枚举而不是字符串，这是Java项目里约定俗成的做法——存储简单、查询效率高、代码里用常量或枚举对应。状态流转方向是：0空闲→1已预约→2使用中，结束使用后再回到0。维护状态是给管理员用的，可以直接跳过预约流程。

3.2 预约记录表：时间段字段怎么设计才合理

预约记录表是本系统最核心的一张表，字段设计直接决定并发控制和统计逻辑能不能写清楚：

CREATE TABLE `reservation` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `user_id` INT NOT NULL COMMENT '关联student.id', `seat_id` INT NOT NULL COMMENT '关联seat.id', `reserve_date` DATE NOT NULL COMMENT '预约日期', `time_slot` VARCHAR(20) NOT NULL COMMENT '时间段，如08:00-10:00', `status` TINYINT DEFAULT 0 COMMENT '0待使用 1已签到 2已取消 3爽约', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里的时间段我建议按“固定时间段”来做，就是把一天切成几个固定区间（上午、下午、晚上，或者每两小时一段），不要让学生自由输入起止时间。原因是课设系统里自由时间段的冲突判断要做区间重叠校验，SQL写起来复杂还容易有边界漏洞；固定时间段的话，判断座位冲突只需要一条SELECT COUNT(*) WHERE seat_id=? AND reserve_date=? AND time_slot=? AND status IN (0,1)就够了。如果你拿到的源码里没有time_slot字段，而是用start_time和end_time两个DATETIME，那么你需要在Service层写区间重叠判断，这是这个项目里最容易出bug的地方，后面避坑章节会细说。

3.3 黑名单与违约逻辑：信用分怎么和预约联动

黑名单表是这套系统的“规则引擎”，虽然字段简单，但业务逻辑都挂在它上面：

CREATE TABLE `blacklist` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `user_id` INT NOT NULL, `reason` VARCHAR(255) COMMENT '拉黑原因，如连续3次爽约', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

实际逻辑是这样的：预约成功后对应reservation.status=0；到了预约时间没来签到，定时任务或手动操作把状态改成3（爽约），同时student.credit扣10分；当信用分低于60分时，自动往黑名单表插一条记录。用户发起预约时，Service层第一步不是查座位，而是先查黑名单——在黑名单里的人直接拒绝预约。这就是一个完整的业务闭环，代码量不大，但能体现你对业务规则的理解。看源码时重点看ReservationService里bookSeat方法开头是不是先查了黑名单，这个顺序错了整个规则就失效了。

4. 顺着一次选座请求走完SSM链路：Controller、Service与Mapper的协作细节

环境配好了，表结构也清楚了，接下来是真正见功夫的地方：一次前端选座请求，在SSM三个层级里是怎么流转的。很多同学单独看Spring、SpringMVC、MyBatis的入门教程都懂，一放到项目里就不知道怎么配合，就是因为缺少一条完整链路的视角。这一章我们跟着代码走一遍完整的选座过程，把关键注解、参数传递和事务控制讲透。

4.1 入口：Controller层的参数接收与响应封装

选座请求从前端页面发出来，通过jQuery的Ajax POST到后台，第一个落脚点就是Controller。这是这个系统里ReservationController的核心方法：

@Controller @RequestMapping("/reservation") public class ReservationController { @Autowired private ReservationService reservationService; @ResponseBody @RequestMapping(value = "/book", method = RequestMethod.POST) public Result book(@RequestParam("seatId") Integer seatId, @RequestParam("userId") Integer userId) { boolean ok = reservationService.bookSeat(seatId, userId); if (ok) { return Result.success("预约成功"); } return Result.error("预约失败，座位可能已被占用"); } }

逻辑说明：@Controller把这个类标记为MVC控制器，@RequestMapping建立URL到方法的映射，前端访问/reservation/book就进到这里。@RequestParam把请求参数绑定到方法入参，两个参数都是Integer类型，框架会自动做类型转换。@ResponseBody很关键，它让方法的返回值（Result对象）被Jackson直接序列化成JSON写回响应体，这样前端拿到的就是{"success":true,"msg":"预约成功"}这样的结构，而不是一个视图名。

这里的Result是本项目自己封装的一个统一响应类，包含code、msg、data三个字段。课设项目建议都用这种统一返回结构，答辩时讲“前后端数据交互规范”会非常加分。注意@RequestParam默认要求参数必须存在，如果你的前端传的参数名和这里不一致，会直接报400错误，这也是最常见的低级错误。

4.2 核心：Service层的状态校验与事务控制

Controller很薄，真正的业务逻辑在Service层。这段代码是整个系统最值得反复看的部分，因为它同时处理了“业务校验”和“并发安全”两个问题：

@Service public class ReservationServiceImpl implements ReservationService { @Autowired private SeatMapper seatMapper; @Autowired private ReservationMapper reservationMapper; @Autowired private BlacklistMapper blacklistMapper; @Override @Transactional(rollbackFor = Exception.class) public boolean bookSeat(Integer seatId, Integer userId) { // 第一步：校验用户是否在黑名单中 int blackCount = blacklistMapper.countByUserId(userId); if (blackCount > 0) { return false; } // 第二步：更新座位状态，只有当前状态为0（空闲）才允许更新 int rows = seatMapper.updateStatusIfFree(seatId, 1); if (rows == 0) { // 受影响行数为0，说明座位已经不是空闲状态 return false; } // 第三步：插入预约记录 Reservation record = new Reservation(); record.setUserId(userId); record.setSeatId(seatId); record.setReserveDate(new java.sql.Date(System.currentTimeMillis())); record.setTimeSlot("08:00-10:00"); record.setStatus(0); return reservationMapper.insert(record) > 0; } }

这段代码有两个设计点值得细说。第一是@Transactional(rollbackFor = Exception.class)，它让整个方法运行在事务中——第三步插入预约记录如果抛异常，第二步对座位状态的更新会自动回滚，不会出现“座位状态改了但预约记录没生成”的数据不一致。rollbackFor默认只回滚RuntimeException，这里显式指定成Exception.class，把受检异常也纳入回滚，更稳妥。

第二是并发的处理方式。这里没有用synchronized锁方法，而是用了一个巧妙的条件更新SQL（updateStatusIfFree），到Mapper层看具体实现：

<update id="updateStatusIfFree" parameterType="map"> UPDATE seat SET status = #{status} WHERE id = #{seatId} AND status = 0 </update>

逻辑说明：这条SQL的WHERE条件里带了status = 0，意味着只有当前状态确实是空闲时，更新才会成功。MySQL的行锁机制保证了两条并发请求同时执行这条SQL时，只有一条能匹配到status = 0的条件，另一条更新的受影响行数为0。Service层通过判断rows == 0就知道预约失败了。这种方式叫“乐观锁思路的条件更新”，比synchronized锁住整个方法性能好得多，也是真正的企业级写法。在数据库层面解决并发冲突，而不是在Java代码层面加锁，这是我强烈建议你写进答辩稿里的一个亮点。

4.3 出口：MyBatis的Mapper接口与XML映射细节

最后看一下Mapper层怎么把接口方法和XML绑定的。这个项目用的是MyBatis最经典的Mapper接口+XML映射方式：

public interface SeatMapper { // 更新座位状态，只有状态为0时才会更新成功 int updateStatusIfFree(@Param("seatId") Integer seatId, @Param("status") Integer status); }

对应的XML文件放在resources/mapper/SeatMapper.xml里：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.studyroom.mapper.SeatMapper"> <update id="updateStatusIfFree" parameterType="map"> UPDATE seat SET status = #{status} WHERE id = #{seatId} AND status = 0 </update> </mapper>

这里最容易翻车的是namespace必须和Mapper接口的全限定名一致、id必须和接口方法名一致，一个字母对不上，启动时不会报错，但一调用就抛Invalid bound statement (not found)。@Param注解的作用是把Java参数名暴露给MyBatis，让XML里的#{seatId}和#{status}能正确取值；如果接口方法是多参数且没加这个注解，MyBatis会报参数找不到。

另外注意parameterType用的是map，这是MyBatis对多参数方法的默认封装方式。你也可以改用@Param("seatId") Integer seatId, @Param("status") Integer status直接传参，XML里不写parameterType也能跑通。链路走完你会发现，SSM三个层级的职责非常清晰：Controller只做参数接收和响应封装，Service只做业务规则和事务控制，Mapper只做数据持久化。这个分层思想本身，就是这门课最想考察你的东西。

5. 避坑：SSM项目最常见的六个翻车点与排查日志

这一章写的都是我在跑SSM课设项目时真实踩过的坑，有些是这份源码本身容易遇到的问题，有些是所有SSM项目共通的雷区。每条我都按“现象 → 原因 → 解决”的顺序写，方便你对照排查。

5.1 MySQL 8.0驱动类找不到，启动直接报ClassNotFoundException

现象：Tomcat启动时报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver，数据源初始化失败。

原因：MySQL 8.0版本的驱动JAR里已经把驱动类从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，而pom.xml里如果引用的还是5.x版本的mysql-connector-java，类路径里根本不存在新的驱动类。

解决：到pom.xml里把MySQL依赖版本换成8.x，同时把jdbc.properties里的driver改成com.mysql.cj.jdbc.Driver。如果你不想动版本，也可以用老版本驱动连MySQL 8.0，但会有时区警告，不太建议。改完后记得在IDEA里刷新Maven重新下载jar包，否则类的加载还是用的旧依赖。

5.2 MyBatis报Invalid bound statement，接口和XML对不上

现象：项目能正常启动，但一点选座按钮，控制台报org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): com.studyroom.mapper.SeatMapper.updateStatusIfFree。

原因：Mapper接口里声明了方法，但MyBatis在加载Mapper XML时没找到对应的statement。通常是两个原因：XML文件的namespace写错了（没有和接口全限定名一致），或者statement的id和接口方法名不一致。

解决：打开SeatMapper.xml，第一行检查namespace="com.studyroom.mapper.SeatMapper"是否和接口的包路径完全一致；第二行检查<update id="updateStatusIfFree">的id是否和接口方法名完全相同，大小写都要对。还有一个隐藏点：XML文件有没有被Maven编译到target/classes目录里。如果放在src/main/java下面而不是src/main/resources下面，Maven默认不会把它当资源文件复制过去，我习惯把XML统一放resources/mapper/目录下，一劳永逸。

5.3 页面能打开但Ajax请求全部404

现象：登录页正常显示，但点预约按钮后浏览器Network里看到请求状态是404，URL地址http://localhost:8080/studyroom/reservation/book能确认是对的。

原因：DispatcherServlet的URL映射配置不对，或者是Controller类没有被SpringMVC扫描到。这类问题分两层：第一层看web.xml里<servlet-mapping>的<url-pattern>是不是/，如果配成了*.do，那你请求不带.do后缀的路径自然进不了SpringMVC；第二层看spring-mvc.xml里的<context:component-scan>有没有扫到Controller类所在的包。

解决：在spring-mvc.xml里确认扫描路径包含com.studyroom.controller，在web.xml里把<url-pattern>改成/。如果改完还有问题，直接在Controller类的@RequestMapping上加一个@Controller注解确认——漏了@Controller注解，类根本不会被注册成Bean。排查顺序是：先看注解，再看扫描包，最后看web.xml映射。

5.4 两个用户同时抢同一个座位，竟然都提示预约成功

现象：用两个浏览器账号同时点击同一个空闲座位的预约按钮，后端返回两条成功记录，数据库里预约记录表出现两条user_id不同但seat_id相同的记录。

原因：Service层如果用“先查询座位状态，再更新座位状态”的两步走写法，在并发场景下会出问题。两个请求同时执行SELECT * FROM seat WHERE id=? AND status=0，都读到了空闲状态，然后都往下执行更新，结果两个都成功了。我说过的updateStatusIfFree条件更新就是为了解决这个问题，但如果你拿到的源码里用的是先查后改，那必然有这个隐患。

解决：把两步改成一步——直接用带AND status = 0条件的UPDATE语句，用受影响行数判断是否成功。如果不想改SQL，也可以用SELECT ... FOR UPDATE加悲观锁，但这会让事务持有行锁直到提交，并发性能差很多。第二种补救方式是在预约记录表的seat_id加唯一约束配合时间段字段，但灵活性差。最推荐的就是章节4.2里那种条件更新的写法，代码改动最小、效果最可靠。

5.5 JSP页面上EL表达式原样输出，${seat.status}不解析

现象：页面列表里的座位状态显示的是字符串${seat.status}，而不是0或1的数字，刷新也没用。

原因：JSP页面的EL表达式默认开关取决于web.xml的版本。如果你用的是Servlet 2.3及以下版本的web.xml描述符，EL表达式默认是关闭的，需要手动在页面里加<%@ page isELIgnored="false" %>才能打开。老课设项目模板里经常有这种坑。

解决：把web.xml的头部引用改成Servlet 3.1版本，即web-app标签的version="3.1"，xmlns用Java EE的规范地址，这样EL默认开启，所有${}表达式都能正常解析。如果不想动web.xml，也可以在每一个JSP页面顶上加上<%@ page isELIgnored="false" %>，但那样比较丑，答辩时被问到不好解释。

5.6 中文乱码：数据库里存的是问号或乱码

现象：页面上输入的中文姓名保存到数据库后变成???，或者查询出来全是乱码。

原因：三层编码不一致。JSP页面本身是UTF-8，但Tomcat默认的请求编码是ISO-8859-1，POST请求的中文参数到了后端就乱掉；同时数据库连接串里如果没有characterEncoding=utf8，写入数据库时也会乱。

解决：按顺序做三件事。第一，在spring-mvc.xml里配置CharacterEncodingFilter，并且把forceEncoding设为true，这样请求和响应都会被强制成UTF-8，这段配置是SpringMVC项目解决乱码的标准答案：

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

第二，确认jdbc.properties连接串里有characterEncoding=utf8。第三，数据库表结构得是utf8mb4编码，如果建表时用了latin1，后面存进去的数据都会有问题。这三个地方对齐了，中文乱码基本绝迹。

6. 验收不是跑通就完事：功能核对单、并发模拟与答辩演示技巧

项目能跑、流程能通，这只是第一步。课设和毕设答辩的时候，老师不会只看你演示一遍流程，他会追问“你怎么验证系统是可靠的”。所以最后一章给你一套可执行的验收清单和演示方法，保证你上场不慌。

6.1 功能核对单：按模块逐项过一遍

对照这份清单至少完整走三遍，第一遍正常流程，第二遍故意操作错误（选已被预约的座位、黑名单用户预约），第三遍快速连续操作观察状态是否正确。这三遍走完，系统基本没问题了。

6.2 并发模拟：用ab命令现场验证抢座

答辩时如果想展示“这个系统能处理并发抢占”，不需要装JMeter这种重型工具，用Apache自带的ab（ApacheBench）就够了。在你的电脑上对预约接口发起100个并发请求：

ab -n 100 -c 20 -p book.txt -T application/x-www-form-urlencoded http://localhost:8080/studyroom/reservation/book

其中-n 100表示总共发100个请求，-c 20表示同时20个并发，book.txt里写的是请求体内容，格式为seatId=1&userId=2。跑完之后ab会输出统计结果，重点关注“Failed requests”的数量，如果是0或者非常小，说明系统的并发控制是有效的。演示完再看一眼数据库里预约记录表，发现只有一条记录对应这个座位，这就是你讲“条件更新防并发”的最好实证。这个方法我每次演示都爱用，说服力很强，而且老师一看就知道你是真理解了系统逻辑。

6.3 答辩演示顺序：先讲设计，再跑主流程，最后亮数据

在答辩现场，建议按“设计->演示->数据验证”三段走。设计阶段打开项目的ER图和数据库设计文档，2分钟内讲清楚四张表和三条核心SQL，重点强调预约记录表和座位表的状态流转设计。演示阶段只跑一条主流程：学生登录->查空座->选座预约->取消预约，全程控制在3分钟。数据验证阶段就是上面说的ab并发命令，让老师亲眼看到两个请求只能成功一个，最后打开数据库翻出对应的预约记录，证明状态变化是真实落库的。文档里其实还带了测试用例和需求分析文档，答辩前花半天对着文档读一遍，把每个表格对应的页面指出来，老师问“这个功能对应文档里哪一节”时你能秒答，印象分会高很多。

这个项目我拆过之后重新完整跑了一遍，最大的感受是：SSM课设的分数差距，从来不在代码量，而在你是否能把“状态流转”和“并发冲突”这两件事讲明白。从那以后我每次拿到一份新的SSM课设源码，第一件事就是花二十分钟把表结构抽出来画一张状态流转图，再顺着一条业务请求走完三层代码，遇到问题直接看日志里的关键词而不是瞎点，整个节奏完全不一样了。这份资源值得你认真过一遍，希望帮到你。

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