简介：这是一份完整的酒店管理系统毕业设计项目资源，面向 Java 初学者、高校毕设及课程设计人群，内容整合了 JAVA 源码、SQL 数据库脚本、论文文档和辅导视频，覆盖客房预订、住店管理、餐饮等典型业务模块。压缩包共 12 个文件，包含 3 个 mp4 操作演示、2 个 doc 与 1 个 docx 文档、1 个 PPT、1 个 sql 脚本、1 个 zip 源码工程及 3 张 jpg 截图，整体约 60.73MB，目录按视频、论文、数据库、源码分类，便于查阅。当前已有 230 人学习浏览。视频演示管理员、住店管理和餐饮功能运行方式，论文、中期检查表、任务书和答辩 PPT 覆盖从选题到答辩全过程，SQL 脚本可初始化数据库，zip 源码便于本地调试。这套资料既可作毕业设计参照，也有助于理解 Java Web 开发中 MVC、DAO、事务与安全等关键实现。
1. 酒店管理系统的设计与实现：别把它只当一个增删改查作业
打开任何一个招聘JD，Java后端岗位的要求里大概率都有“独立完成过管理系统”这一条；打开知网和本科毕设库，酒店管理系统更是出现频率最高的题目之一。这个选题看起来老套，但恰恰因为老套，它把Java Web开发里最核心的东西全串起来了：Servlet或Spring Boot怎么处理请求、MyBatis或JDBC怎么操作数据库、表之间怎么设计外键和关联查询、权限怎么用拦截器控制。换句话说，这是一套完整的Java后端入门实战链路的缩影。市面上拿这套题目做毕设的数量多如牛毛，但大部分只是把源码跑通、论文交差，真正能把它讲清楚并能在答辩时接住提问的人却很少——这篇文章就是把一条可靠的技术路线拆开，从表设计、后端实现到答辩演示一次说完，让你手里这套JAVA源码+数据库sql+论文+视频的交付物真正值回精力。
2. 技术选型与项目骨架：搞清楚该用哪一套技术栈再做，不然白折腾
2.1 一套能跑通也能写进论文的技术栈组合
酒店管理系统的技术选型，直接决定你后面写论文时“技术介绍”章节的长度和深度。我见过不少同学上来就选Spring Cloud + 微服务，理由是“看着高级”，结果部署环境折腾了一周，最后答辩时老师一句“为什么一个单体就能解决的需求要拆微服务”就哑火了。毕设项目的核心原则是恰当，而不是堆料。
常见且稳妥的组合是：Spring Boot 2.x + MyBatis-Plus + MySQL 5.7/8.0 + Thymeleaf 或 Vue 前后端分离。Spring Boot负责把项目跑起来，MyBatis-Plus用AR模式或BaseMapper帮你省掉大量重复的CRUD代码，MySQL存数据，前端用Thymeleaf做服务端渲染的话对毕设来说最简单——不需要额外起Node服务，打包成一个jar就能跑，演示时不容易翻车。如果你手里的源码是SSM（Spring + Spring MVC + MyBatis）结构的，也完全可行，只是配置会多几处XML，我一般会建议优先选择Spring Boot版本，因为论文里能多写一节“自动化配置原理”，而且调试时的报错栈更短、更容易排查。
前端选型还有一条隐性规则：如果你的论文需要写“前端框架对比”，就用Vue；如果你的论文重点在Java后端，前端用Thymeleaf就行，把篇幅留给后端逻辑和数据库设计。这个决定要先做，因为后面写论文时，技术选型那一章要给出理由，不能只写“我选择了XX”。
2.2 项目目录结构：按这个分层建包，论文和答辩都顺
一个到达“能写进论文”标准的酒店管理系统，代码结构至少要能看出分层思想。我一般会按controller、service、mapper、entity、config、common六层来组织。controller只接收参数和返回结果，service里面写业务逻辑，mapper只碰SQL或MP的Wrapper，entity对应表结构，config放拦截器和跨域配置，common放统一返回结果和异常处理。
com.example.hotel ├── controller // 接收请求，返回Result │ ├── AdminController.java │ ├── RoomController.java │ └── OrderController.java ├── service // 业务逻辑接口 │ ├── RoomService.java │ └── impl/ ├── mapper // MyBatis-Plus的Mapper接口 │ ├── RoomMapper.java │ └── OrderMapper.java ├── entity // 对应数据库表 │ ├── Room.java │ ├── Order.java │ └── User.java ├── config // 拦截器、WebMvc配置 │ └── LoginInterceptor.java └── common // 统一返回体、异常处理 ├── Result.java └── GlobalExceptionHandler.java这个结构的核心逻辑是“请求单向依赖”：controller调用service，service调用mapper，entity被多层共用，谁都不允许反向调用。比如OrderController想要查询某个房间的订单，它只需要调orderService的一个方法，而不是自己去new一个RoomMapper再自己拼接SQL。这样写的好处是论文里“系统设计”章节可以直接用这张包结构图，答辩时老师问“你为什么要分这么多层”，你的回答是“降低耦合、方便单元测试”，这就比“网上模板这么写的”要专业得多。
2.3 跑通最小示例：从0到能登录，先别碰业务功能
拿到源码包之后，很多人犯的第一个错是急着去看那些复杂的业务代码，结果报错一大堆，心态崩了。正确打开方式是先跑一个最小闭环：启动项目、访问登录页、登录成功进入首页。验证这一步走通，说明环境没问题，后面所有功能调试才有基础。
# 1. 创建数据库，字符集选utf8mb4，排序规则选utf8mb4_general_ci CREATE DATABASE hotel_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 执行源码里的hotel_system.sql脚本 mysql -u root -p hotel_system < hotel_system.sql # 3. 修改application.yml里的数据源配置 spring: datasource: url: jdbc:mysql://localhost:3306/hotel_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 # 4. 打包并运行 mvn clean package -DskipTests java -jar target/hotel-system-0.0.1-SNAPSHOT.jar这里的几个参数值得说清楚。url里的serverTimezone=Asia/Shanghai是必加的，否则MySQL 8.0在连接时会报时区错误；characterEncoding=utf8是保证中文不乱码的关键；登录页能打开但登录失败时，优先检查sql脚本是否完整执行了——很多源码里的sql文件分成了建表语句和插入语句两部分，漏跑插入语句就会导致管理员账号不存在。这算是我自己调试过几十次之后得出的血泪经验：第一步先跑通登录，后面所有功能都是在给这张网添枝加叶，顺序反了就是给自己挖坑。
3. 数据库设计与SQL落地：表结构设计得好，后面所有代码都舒服
3.1 核心表拆分与字段设计：一张图看清房间、订单、用户怎么关联
酒店管理系统的数据库是整个项目的地基，地基没打好，后面写联表查询时就会处处碰壁。我先说我见过的一种典型错误设计：一张user表里既放管理员又放普通顾客，靠一个role字段区分；订单表里把顾客姓名、手机号、房间号全部冗余进去。这种设计不是不能用，而是写论文时“数据库设计”那一章很单薄，而且后续扩展（比如给顾客加积分、给房间加价格策略）会很难受。
更合理的拆分方案是四张核心表：用户表（管理员+顾客）、房间表、订单表、房间类型表。用户表和房间表之间通过订单表建立多对多关系——一个用户可以订多个房间，一个房间可以被多个用户在不同的时间段订过。房间类型表和房间表是一对多，一个类型对应多个房间，比如“大床房”这个类型下可能有301、302两个房间。
表设计上还有几个字段值得注意。订单表里我一般会要include一个status字段，用int存储，0表示待支付、1表示已入住、2表示已完成、3表示已取消。为什么要用int而不是varchar中文？一是查询效率高，二是MyBatis-Plus里可以直接用Wrapper.eq("status", 0)做条件过滤，三是论文里可以画状态转换图。房间表的价格字段要用decimal(10,2)，不能用float——老师问“为什么不用double”，你要能答出“decimal是精确数值，不会出现0.1+0.2不等于0.3的问题”。
3.2 数据表创建脚本：从SQL第一行到最后一行都有讲究
-- 1. 创建房间类型表 CREATE TABLE `room_type` ( `id` int NOT NULL AUTO_INCREMENT, `type_name` varchar(20) NOT NULL COMMENT '类型名称：大床房/双床房/套房', `bed_count` tinyint NOT NULL DEFAULT 1 COMMENT '床位数', `area` decimal(5,2) DEFAULT NULL COMMENT '房间面积（平方米）', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='房间类型表'; -- 2. 创建用户表，管理员和普通用户共用一张表 CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(20) NOT NULL COMMENT '登录账号', `password` varchar(64) NOT NULL COMMENT '密码，建议存MD5或BCrypt加密后的值', `real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名', `phone` varchar(11) DEFAULT NULL COMMENT '手机号', `role` tinyint NOT NULL DEFAULT 1 COMMENT '角色：0-管理员，1-普通用户', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB AUTO_INCREMENT=1000 DEFAULT CHARSET=utf8mb4 COMMENT='用户表（管理员+顾客）'; -- 3. 创建房间表 CREATE TABLE `room` ( `id` int NOT NULL AUTO_INCREMENT, `room_no` varchar(10) NOT NULL COMMENT '房间号，如301', `type_id` int NOT NULL COMMENT '房间类型ID，关联room_type表', `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0-空房，1-已入住，2-维修中', `floor` varchar(5) DEFAULT NULL COMMENT '楼层', `description` varchar(500) DEFAULT NULL COMMENT '房间描述', PRIMARY KEY (`id`), KEY `idx_type_id` (`type_id`), CONSTRAINT `fk_room_type` FOREIGN KEY (`type_id`) REFERENCES `room_type` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房间表';这套建表脚本里的几个细节想展开讲。AUTO_INCREMENT=1000是把用户id的起始值设到1000，这样管理员和测试用户的id看起来规整，演示时也更好区分——实际项目里这个值随意，但毕设演示时观众一眼能看懂编号规律是加分项。字段注释文本中的COMMENT是必须写的，因为论文里需要贴表结构说明，直接从Navicat导出的注释就是这里的内容。外键CONSTRAINT fk_room_type这句在毕设里可以保留，但在企业级项目里我一般会建议去掉外键约束——那是另一个话题，在毕设场景里保留外键反而能体现你理解主外键关系，数据库课程设计的分数不会低。
密码字段varchar(64)是给BCrypt加密预留的，如果你的源码里用的是MD5，那密码长度32就够，但注意MD5已经不安全了，论文里被问到“密码怎么存储的”时要能说出MD5只能防误存不能防破解、安全性不足这种边界感。时间字段统一用datetime而不用timestamp，因为timestamp在2038年会溢出，尽管毕设不可能运行到那一天，但这个细节能体现你对时间类型的边界了解——答辩时属于加分项细节。
3.3 核心业务SQL：什么场景用联表，什么场景必须分开查
酒店管理系统的关键业务场景就那么几个：查询可用房间、创建订单、办理入住、退房结账。其中最容易写错的是“查询可用房间”这个SQL，很多人写出的第一版是在room表上直接where status=0，这没错，但缺了入住时间的条件——比如某房间是空房状态，但明天已经被预定了，那它在前台界面就不该显示为可预订。
-- 查询某时间段内可预订的房间 SELECT r.id, r.room_no, rt.type_name, rt.price FROM room r JOIN room_type rt ON r.type_id = rt.id WHERE r.status = 0 AND r.id NOT IN ( SELECT o.room_id FROM orders o WHERE o.status IN (0, 1) -- 待支付和已入住的订单占用了房间 AND NOT (o.check_out_date <= #{startDate} OR o.check_in_date >= #{endDate}) );这条SQL的NOT IN子查询是核心。它的逻辑是“找出所有在你要住的区间内被占用的房间”，然后排除它们。NOT条件里的check_out_date <= 开始日期表示“之前就已经退房了，不冲突”，check_in_date >= 结束日期表示“之后才入住，也不冲突”。这个区间重叠判断四个边界情况——入住当天退房算不算冲突、同一间房两笔订单时间紧挨着行不行——建议自己在测试数据里跑一遍，纸上推演不算数。MyBatis-Plus的LambdaQueryWrapper也能实现类似逻辑，但SQL直写在XML里对演示和调试更透明，而且论文里贴SQL比贴Java代码更直观，还能顺便写一段“SQL优化思路”。
4. 后端功能模块实现：从登录到退房，按这条链路写下去不会乱
4.1 统一登录与权限控制：拦截器里的一道关卡
酒店管理系统至少有两种角色：管理员和普通顾客，权限不一样。管理员能操作房间信息维护、订单管理、查看所有订单；顾客只能查看自己的订单和预订房间。这里的权限控制不靠前端页面隐藏来实现——前端隐藏按钮只是用户体验，真正拦住非法请求要在后端加一道拦截器。
@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录请求和静态资源 String uri = request.getRequestURI(); if (uri.contains("/login") || uri.contains("/css") || uri.contains("/js") || uri.contains("/images")) { return true; } // 从session中取用户信息 Object user = request.getSession().getAttribute("loginUser"); if (user == null) { // 未登录，重定向到登录页 response.sendRedirect("/login"); return false; } // 管理员接口拦截：如果是 /admin/ 路径，检查角色 if (uri.contains("/admin/") && !"0".equals(((User) user).getRole())) { response.setStatus(403); return false; } return true; } }这段拦截器的逻辑分三层。第一层放行登录接口和前端静态资源，否则用户压根进不了登录页；第二层检查session里有没有loginUser，没有就弹回登录页；第三层是管理员路径校验，普通顾客就算手动在地址栏输入/admin/room/list也会被返回403。角色字段role从session里的user对象取，取出来之后做个字符串比较，这里要注意强转之前先判断user不为null，否则空指针异常就是你自己埋的雷。注册拦截器的配置在WebMvcConfigurer里，重写addInterceptors方法，把上面这个拦截器加到拦截链里，注意别把login接口也拦住，否则就是死循环。这套拦截器逻辑写进论文时，能配一张请求时序图，答辩时老师会问的“如果用户绕过前端直接调接口怎么办”，答案就在这里。
4.2 订单状态机的设计与实现：状态字段决定了你的业务边界
订单状态这个字段是整个系统里最有趣的设计点，因为酒店订单和电商订单不一样，它有“入住”这个线下环节参与。一个完整的订单生命周期是：待支付 → 待入住 → 已入住 → 已完成，中间还可能插入“已取消”和“超时关闭”。毕设里做到前四个状态就足够，超时关闭可以不做，但要注意订单删除不能是物理删除——状态改为“已取消”即可，否则报表统计对不上数据。
@Service public class OrderServiceImpl implements OrderService { @Override @Transactional(rollbackFor = Exception.class) public boolean createOrder(OrderCreateRequest req) { // 1. 校验房间是否可预订 Room room = roomMapper.selectById(req.getRoomId()); if (room == null || room.getStatus() != 0) { throw new BusinessException("该房间不可预订"); } // 2. 检查该时间段是否被占用 int count = orderMapper.checkRoomOccupied(req.getRoomId(), req.getCheckInDate(), req.getCheckOutDate()); if (count > 0) { throw new BusinessException("该房间在所选时段已被占用"); } // 3. 计算金额：房间单价 * 天数 BigDecimal days = DateUtil.betweenDays(req.getCheckInDate(), req.getCheckOutDate()); BigDecimal totalPrice = room.getPrice().multiply(days); // 4. 插入订单，状态设为待支付 Order order = new Order(); order.setUserId(req.getUserId()); order.setRoomId(req.getRoomId()); order.setCheckInDate(req.getCheckInDate()); order.setCheckOutDate(req.getCheckOutDate()); order.setStatus(0); order.setTotalPrice(totalPrice); orderMapper.insert(order); return true; } }这段代码踩的坑主要在第三步金额计算。BigDecimal的两数相乘要用multiply方法，不能直接星号运算，房间单价是decimal类型，取出后如果是BigDecimal就可以直接乘。DateUtil.betweenDays的边界要注意：当天入住当天退房算0天还是1天，这个要在代码注释里写明，并且和前端页面的日期选择逻辑保持一致——我习惯当天入住当天退房按1天算，因为酒店都按过夜计费。还有第2步的checkRoomOccupied，这其实是把前面写的那个联表SQL封装成了Mapper方法，写在XML里的SQL可视化程度更高。如果并发量大了会有超卖问题，但毕设阶段不讨论这个，答辩时老师如果问，你就说“生产环境会引入Redis分布式锁或数据库悲观锁”，点到为止不用深入。
4.3 前台页面与后台管理：接口设计上的一对多关系
酒店管理系统的页面可以分成两套入口：顾客端和管理员端。顾客端核心页面是首页房间展示、预订页面、个人订单列表；管理员端是房间管理、订单管理、入住办理页面。如果源码是前后端分离的Vue版，那么前端每个页面都对应后端的一组接口；如果是Thymeleaf版，页面放在templates目录下，controller直接返回视图名。
<!-- 房间列表页核心片段：展示房间号和价格，点击预订跳转 --> <tr th:each="room : ${roomList}"> <td th:text="${room.roomNo}">301</td> <td th:text="${room.typeName}">大床房</td> <td th:text="${room.price}">299.00</td> <td th:text="${room.status == 0 ? '空房' : (room.status == 1 ? '已入住' : '维修中')}">空房</td> <td> <a th:href="@{/order/create(roomId=${room.id})}" th:if="${room.status == 0}" class="btn btn-primary">预 订</a> </td> </tr>这段Thymeleaf模板里的关键是th:href生成预订链接时带上roomId参数，后端在OrderController的create接口接收这个参数后就调orderService.createOrder方法。th:if="${room.status == 0}"这个判断是前端层面的可用房间过滤，和后端拦截器配合，前端不给用户入口、后端给用户防护，双保险。还有一个细节是显示状态时用了三元表达式嵌套，页面直接读int状态值不够直观，这样输出中文状态文案就不用后端再返回一个状态名称字段了——省了一次实体类的字段扩展。如果你的源码是Vue版，思路一样，只是把三元表达式放在前端模板里，后端返回的status还是int。
5. 常见问题和避坑指南：从环境配置到SQL执行的各种翻车现场
5.1 数据库连接失败或中文乱码：先查这三处
“SQL脚本能跑但启动报错”或“页面显示中文乱码”，这两个问题在酒店管理系统里命中率极高。现象、原因、解决三步过一遍：
第一个坑：启动Spring Boot时报Access denied for user 'root'@'localhost'。原因百分之九十是application.yml里的密码和本地MySQL实际密码不一致，少数情况是MySQL 8.0的加密规则是caching_sha2_password而驱动用的旧版。解决：先检查密码，再检查驱动依赖，MySQL 8.0要配mysql-connector-java 8.0.x版本。
第二个坑：SQL脚本能导入但Navicat里看到的中文是问号。原因是sql文件本身不是UTF-8编码，导入时又被按GBK解析了。解决：用文本编辑器把sql文件另存为UTF-8编码，然后命令行导入时加--default-character-set=utf8mb4。
第三个坑：页面上所有中文都正常，只有时间显示成英文格式比如Tue Jun 25 10:30:00 CST 2024。原因是Jackson默认序列化Date类型时用的是系统时区格式，而application.yml里没有配置时区。解决：在application.yml里的spring.jackson配置加上date-format和time-zone，这个配置在本文2.3节出现过；或者给实体类的日期字段加@JsonFormat注解。
5.2 联表查询结果和页面显示对不上：检查Room实体的typeName字段
房间列表页能打开但房间类型名称那一列空白，这是这类项目的经典玄学问题。现象是room表里type_id有值，room_type表里也确实存在对应类型，但页面上typeName就是空的。原因基本出在实体类映射上：Room实体类没有typeName这个字段，或者在Mapper的XML中resultMap只映射了room表本身的字段，没有关联查询room_type的type_name列。
解决分两步。第一步在Room实体类加一个typeName字段，标记为@TableField(exist = false)，告诉MyBatis-Plus这个字段在room表里不存在，别生成SELECT。第二步在查询SQL里显式写上SELECT r.*, rt.type_name AS typeName FROM room r LEFT JOIN room_type rt ON r.type_id = rt.id。这里LEFT JOIN比JOIN好，万一某条room记录没有对应type_id，也不会因为内连接直接丢行。如果用的是纯MyBatis-Plus的BaseMapper，则直接用LambdaQueryWrapper加子查询或者在实体里放一个嵌套对象属性，看源码是什么风格就顺着它走，不要强行混用。
5.3 订房时间校验失灵：用户选了今天到昨天也能下单
这个坑属于业务边界问题。前端页面选了入住日期和退房日期，后端如果没有校验日期先后关系，用户可能选到“入住6月1日，退房5月30日”这种非法区间，然后系统还正常创建了订单。这是因为写代码时只检查了房间占用，没检查日期本身的合法性。
解决方式是在Controller层或Service层的入口处加一个日期比较：
if (orderRequest.getCheckInDate().isAfter(orderRequest.getCheckOutDate())) { throw new BusinessException("退房日期不能早于入住日期"); } // 更进一步：入住日期不能早于今天 if (orderRequest.getCheckInDate().isBefore(LocalDate.now())) { throw new BusinessException("入住日期不能早于当前日期"); }这段校验的细节在于LocalDate的isAfter和isBefore方法比较的是日期不比较时间，所以不会出现“今天23点59分下订单被误伤”的情况。前端也做一份同样的校验，双端校验在论文里可以写成“前端提升用户操作体验，后端保证数据安全一致性”，一句话同时体现两个层面的考虑。
5.4 MySQL 5.7和8.0的兼容性：sql文件导进去立刻报错
不同版本MySQL的兼容性问题是另一个高发踩坑现场。现象是用MySQL 8.0的Navicat导出的sql文件，在MySQL 5.7里执行时提示Unknown collation: 'utf8mb4_0900_ai_ci'。原因很明确：utf8mb4_0900_ai_ci是8.0引入的排序规则，5.7不认识。解决：把sql文件里的所有CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci全局替换成CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci，或者直接改用5.7版的sql文件。另一个隐藏点是在MySQL 8.0里创建的备份脚本，包含CREATE USER和GRANT语句，在5.7里会因为语法差异报错——用Navicat只选“转储数据”而不是“转储整个数据库”就能规避。
5.5 视频里录的操作和你写的论文步骤对不上
这个坑不在代码层面，但同样致命。很多毕设包的视频是作者用自己电脑的操作流程录制的，数据库名字、端口号、项目名可能都和你实际环境不一样。答辩老师不会反复看视频对比，但你自己演示时照着视频的路径去启动项目，结果发现项目名不同或者端口被占用，场面就很尴尬。解决：动手之前先看视频里启动项目的命令和页面URL，记录下来，然后在自己环境里跑一遍相同的路径。端口被占用时用lsof -i:8080查进程然后kill掉，或者把项目的server.port改成8081——但注意，如果你论文里的截图是8080，改端口就要把论文截图也改掉，所以能腾端口就腾端口。
6. 从能跑到能答辩：三个加分演示技巧与论文联动方法
一个能跑的酒店管理系统在答辩里只能算及格，能在演示过程中顺手展示几个“设计过的细节”才是拉开差距的地方。我给你三个不复杂但很出效果的演示技巧，每个都能在论文里找到对应章节。
第一个技巧是演示“缓存穿透”的防护逻辑。在房间列表接口上加一个简单的本地缓存，用ConcurrentHashMap保存房间列表数据，设置5分钟过期。演示操作是：第一次访问房间列表接口时，在IDEA控制台打印“从数据库查询房间列表”，第二次刷新页面时打印“从缓存读取”。这个演示不需要Redis，一个HashMap就能实现，但答辩时你可以从“为什么用本地缓存”延展到“分布式环境下应该用Redis”，把话题引向自己熟悉的领域——哪怕只是背过Redis的八股文，也能显得准备充分。
第二个技巧是演示事务回滚。在创建订单的Service方法上已经加了@Transactional(rollbackFor = Exception.class)，演示时人为制造一个异常——比如把房间价格的multiply方法换成一个会抛出ArithmeticException的操作，或者故意传一个不存在的userId，然后观察控制台日志和数据库订单表的变化。观众会看到日志打出了异常栈，但orders表里没有新增记录，这就是事务的原子性。论文的“系统测试”章节对应写一条“异常数据不回滚”的测试用例，前后呼应。
第三个技巧是演示索引优化的效果。在orders表按room_id和check_in_date建一个联合索引，然后用EXPLAIN分别看有索引和没有索引时同一查询的执行计划——没有索引时是type=ALL全表扫描，有索引时是type=ref。演示时直接在Navicat的查询窗口跑EXPLAIN SELECT，截图存到论文的“性能优化”章节里，比任何口头描述都有说服力。
这三个技巧的共同特点是都不需要额外写复杂的代码，只是在已有功能的基础上多做一步“让它可见”——所以你的代码里要有日志打印、有注释、有能手动触发的失败场景。最后还有一件事是看完视频演示前先自己走一遍所有功能，把容易出错的步骤记下来，比如“登录-预订-支付-入住-退房”这条主流程上，哪一步会弹什么校验提示、哪个按钮是灰色的、哪个URL是带参数的。答辩现场一旦操作顺序和预期不符，你不会有时间当场查代码，这些手指肌肉记忆反而是最可靠的缓冲。我自己当年做毕设时，最庆幸的事就是提前把主流程走了三十遍——不是为了写测试报告，而是为了在紧张的时候身体比脑子先反应。希望这套方案能帮你把这个经典项目做得比及格线高出一截，也祝你答辩顺利。
本文还有配套的精品资源，点击获取
