SpringBoot酒店客房预订系统毕设：从选题到部署答辩的完整指南

本身是做毕设带学生的，每年springboot类题目占一半还多，酒店客房预订系统又是其中被点率最高的一个。这个题目看着简单，但真到答辩时能讲清楚的人不多——大部分人卡在同一个地方：系统能跑，但说不明白"为什么这么设计"。这篇就把我从选题、建表、写接口到部署的完整思路拆开讲，给正在做这个题目的人一个能直接参照的骨架，也顺带讲讲springboot项目里那些课堂上很少展开、但实际一碰就翻车的细节。

整个项目我按"选题价值 → 技术选型 → 数据库设计 → 核心业务 → 集成部署 → 答辩准备"这条线来写。你只要跟着这条线走，做完系统之后心里是有底气的，不管是自己复盘还是应付答辩追问，都能站得住。

1. 这个毕设题目为什么值得做：市场需求与技术覆盖面的双重考量

每年选题季我都被问同一句话："老师，酒店客房预订系统是不是太普通了？"我的回答一直是：普通不等于没价值，关键看你怎么把它做"深"。酒店客房预订系统在毕设题目里热度高，恰恰是因为它覆盖的技术面非常完整，而且业务逻辑足够清晰——既不像纯电商那样有复杂的支付分摊，也不像内容管理系统那样只有单纯的增删改查，它处在"有一定业务复杂度但又完全可控"的黄金区间。

从市场需求角度说，酒店行业的信息化改造一直没停过，前台手工排房、电话预订、纸质登记这些小旅馆还在用的老流程，正是小型管理系统要解决的问题。你做一个面向中小型酒店的预订系统，是有真实业务场景支撑的，不是空中楼阁。体现在论文里，"研究背景和意义"那一章写起来就能言之有物，落不了地。

从技术覆盖面上看，这个题目几乎能把Spring Boot生态的主要知识点串起来：

• Web层：RESTful API设计、参数校验、统一异常处理
• 数据层：MySQL表设计、MyBatis持久化、事务管理
• 业务层：预订状态流转、并发防超卖、日期冲突校验
• 进阶功能：定时任务（超时未支付订单自动取消）、缓存（房型库存缓存）、文件上传（房间照片）
• 前端联调：Vue打包后整合进Spring Boot，或者前后端分离部署

这几个点单独拿出来都不算难，但组合在一个系统里，整体工作量、整体深度就上来了。很多学生做完之后跟我反馈，说真正弄懂了"一个请求从前端进来，到数据库返回，中间经过了哪些环节"——这个认知，比项目本身值钱。

再说点实际的：这类系统查重也比较好过。因为你在表结构设计、状态机设计、并发控制这几个地方是能写出差异化内容的，不是网上那种千篇一律的CRUD。后面几章我会重点讲这几个差异化点怎么落。

2. 技术栈定型：Spring Boot生态下的选型取舍与版本决策

2.1 为什么锁定Spring Boot而不是SSH或SSM

这个答案其实在热度词里已经摆得很明显了：Spring Boot全家桶已经是JavaWeb开发的事实标准。SSH（Struts+Spring+Hibernate）早被市场淘汰了，SSM虽然还能见到，但配置那套东西——XML文件写到手软，各种bean之间绕来绕去的依赖关系——对毕设周期来说是纯纯的负担。

Spring Boot的核心价值是"约定大于配置"，它把原来SSM里要手工做的一大半配置变成了自动装配。你搭一个Web项目，从零到能跑起来，用Spring Boot大概十分钟，用SSM至少折腾一上午。这不是说SSM的技术含量低于Spring Boot，而是说SSM的复杂度来自基建，Spring Boot把基建收敛掉了，让你把精力放在业务上。

我在给学生定方案时，一直是这个原则：毕设的展示重心是业务设计和工程化能力，不是展示你会写配置文件。哪个框架能让你更快地表达业务，就用哪个。

2.2 版本决策：逻辑直白的选法，避免被坑

版本这块我要重点提醒。很多人在官网一看到Spring Boot 3.4.x、3.5.x就顺手选了最新版，结果JDK版本不匹配、依赖下载报错、启动直接黑屏，一卡就是两三天。这是热度词"springboot版本太高"的真实写照，几乎每周都有人因为这个来找我排查。

我的建议非常保守：做毕设就选Spring Boot 2.7.x系列，配套JDK 1.8。原因有三点：

1. 这是国内教程资源覆盖率最高的组合，遇到任何报错，百度Google都能秒出答案
2. MyBatis Plus、Redis、EasyExcel这些常用中间件对Spring Boot 2.x的兼容性经过了大批量项目验证，坑最少
3. Spring Boot 3.x开始把javax迁移到jakarta，很多老代码示例直接复制会报包不存在，对刚接触框架的人来说这是完全没有排查头绪的编译错误

如果你非要用3.x，也可以，但要做好心理准备——网上大量示例代码里的javax.servlet要手动改成jakarta.servlet，一些starter的坐标也要换成3.x专用版本。这笔时间成本，对毕设来说不划算。

项目结构上，标准的Maven单模块工程就够了，不需要微服务那套。按我习惯的包结构组织：

com.example.hotel ├── controller # 接口层 ├── service # 业务层 │ └── impl ├── mapper # MyBatis持久层接口 ├── entity # 数据库实体类 ├── dto # 接口入参出参对象 ├── config # 配置类：拦截器、跨域、定时任务等 ├── common # 统一返回结果、异常处理、工具类 └── HotelApplication.java

这个分包是把"表现层、业务层、持久层"的经典分层落到了代码目录上，答辩时面试官一眼就能看出你懂分层思想。

2.3 Maven构建的节奏感：先骨架后依赖

热度词里有个"javamaven项目构建方法"，这确实是一个新手容易卡壳的点。直接用IDEA创建Spring Initializr项目是最省事的路径：File → New → Project → Spring Initializr，填好Group和Artifact，选好Spring Web、MySQL Driver、MyBatis这些依赖，项目骨架就出来了。

这里要注意一个细节：不要一上来就一股脑把所有依赖全勾上。比如MyBatis Plus要单独加坐标，Lombok也要单独加，这些Initializr自带的勾选项里没有。我的习惯是先把Web和MySQL Driver勾上，项目创建成功后，再根据业务需要在pom.xml里逐项添加。这样每一步加依赖，报错都能精准定位到是哪个引起的，而不是做了一堆操作之后突然启动失败，连哪一步出了问题都不知道。

pom.xml里最常用的这份依赖清单，可以直接抄作业：

<dependencies> <!-- Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis Plus --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- Lombok，简化实体类 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- 参数校验 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <!-- 后续做定时任务时引入 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> </dependencies>

Lombok不多说了，实体类的getter/setter/toString全自动生成，代码量少一大截。参数校验那是我特别建议加的——所有接口入参用@Validated注解校验，客人订房时手机号格式、日期格式、入住人数这些交给框架去挡，比自己在service里写if else判断干净得多，答辩时也算一个亮点。

3. 数据库设计是这类系统的灵魂：从表结构到状态流转的完整梳理

3.1 五张核心表：先回答"业务需要哪些数据"

酒店客房预订系统的数据模型，我把它归纳成"两个主数据、一个核心单据、两个辅助数据"：

• 主数据1：房型（room_type）——豪华大床房、标准双床房、行政套房这类可售卖的产品定义，包含房价、面积、床型、可住人数、房间图片
• 主数据2：客房（room）——实际物理房间，属于某个房型，有房号、楼层、朝向
• 核心单据：订单（order）——客人预订行为的完整记录，关联房型和具体客房，包含入住日期、离店日期、订单金额、状态
• 辅助数据1：用户（user）——系统登录账号，区分顾客和管理员角色
• 辅助数据2：预订明细（order_detail，可选）——如果一次订单预订多间房，用明细表记录每间房的具体信息，方便后续排房

为什么把房型和客房拆成两张表？这是这类数据库设计里最值得解释的一个点。你可以这样理解：房型好比菜单上的菜品，客房好比厨房里实际的锅。一个房型对应多间客房，一间客房唯一属于一个房型。如果把它们揉在一张表里，每个房间都要重复维护一份房价、图片、床型信息，改价格要挨个房间改，数据冗余不说，还会出现同一个房型下各客房价格不一致的脏数据。拆开之后，要给"豪华大床房"调价，只改room_type表里的一行记录就行了。

3.2 状态字段设计：订单的一生

订单表里最核心的字段不是金额，是status状态字段。我设计的订单状态流转是毕设答辩时的重点展示内容，也是一套完整的状态机：

待支付(0) → 已支付(1) → 已入住(2) → 已完成(3) │ ├→ 已取消(4) （用户主动取消/超时未支付自动取消） └→ 已退款(5) （支付后取消并退款）

这个状态流转在设计时要回答三个问题：

1. 每种状态由谁触发：待支付到已支付是用户支付动作触发；已支付到已入住是前台办理入住触发；已完成是退房结算触发
2. 哪些状态可以回退：待支付可以取消，已支付可以退款取消，但已入住之后只能走到已完成，不能回退
3. 状态变更要不要记录历史：严谨的做法是加一张订单状态变更日志表，每次状态变化都记录操作人、时间、变更前后值。毕设系统里可以加，工作量不大，但论文里写"通过状态日志实现全链路审计追踪"是很有分量的功能点

3.3 日期冲突与库存判断：用SQL表达业务规则

酒店预订最核心的业务规则是：一间客房在同一时间段内不能被两个订单占用。这个判断不能靠Java代码遍历硬算，要用SQL在数据库层面解决。

订单表里存check_in_date和check_out_date。判断"某个时间段是否与已有订单冲突"的SQL长这样：

SELECT COUNT(*) FROM orders WHERE room_id = #{roomId} AND status IN (1, 2) -- 已支付和已入住才算占用 AND NOT ( #{newCheckOut} <= check_in_date OR #{newCheckIn} >= check_out_date )

这个NOT (新离店 <= 旧入住 OR 新入住 >= 旧离店)的两时间段交叉判断逻辑，看起来简单，但写错的人不在少数。容易错的地方是把OR写成AND，或者判断条件里漏了边界值处理。实际订房场景中，旧订单中午12点退房，新订单下午2点入住，中间是有缓冲时段的，具体要不要允许同一天首尾相接，取决于酒店设定的打扫时间，这种业务规则建议在代码里定成常量，后面调起来方便。

库存判断同理。房型维度看的是"该房型下处于可售状态的客房数量"：

SELECT COUNT(*) FROM room WHERE room_type_id = #{typeId} AND status = 0 -- 0=启用 1=停用 AND id NOT IN ( SELECT room_id FROM orders WHERE status IN (1, 2) AND NOT ( #{newCheckOut} <= check_in_date OR #{newCheckIn} >= check_out_date ) )

这条SQL的结果就是当前可用的房间数。预定页面上显示"还剩几间"，就是用它查出来的。

3.4 表结构落地的实操建议

建表时我习惯用Navicat或者IDEA的Database插件直接可视化建，建完导出SQL脚本放工程里。下面是一个简化的订单表DDL，照着这个思路扩展就行：

CREATE TABLE `orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '下单用户ID', `room_type_id` bigint(20) DEFAULT NULL COMMENT '房型ID，下单时预订房型', `room_id` bigint(20) DEFAULT NULL COMMENT '具体客房ID，办理入住时确定', `check_in_date` date NOT NULL COMMENT '入住日期', `check_out_date` date NOT NULL COMMENT '离店日期', `guest_name` varchar(50) NOT NULL COMMENT '入住人姓名', `guest_phone` varchar(20) NOT NULL COMMENT '入住人手机号', `total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0待支付 1已支付 2已入住 3已完成 4已取消 5已退款', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_room_date` (`room_id`, `check_in_date`, `check_out_date`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;

几点说明：订单编号别用自增ID直接暴露给用户，用时间戳+随机数拼一个唯一单号；联合索引idx_room_date是给日期冲突查询加速的；金额用decimal(10,2)，千万别用float——浮点数的精度误差在钱上是不能容忍的，这也是一个可以主动讲的细节。

4. 核心业务接口的落地思路：预订流程与数据一致性的攻防

4.1 预订主流程：七步走完一笔订单

整个预订系统的业务闭环是七个步骤串联起来的。我画一遍完整流程，你照着这个顺序去实现接口就不会乱：

1. 用户注册/登录：JWT签发token，前端请求带上token访问受保护接口
2. 查询房型列表：展示房型、价格、图片、剩余可订数量
3. 查询房型详情：传入房型和日期，返回该时间段内的可用房间列表
4. 提交预订：前端提交房型、入住日期、离店日期、入住人信息，后端做日期校验、库存校验，生成订单（状态=待支付）
5. 模拟支付：因为不做真实支付对接，用"点击支付按钮直接回调"或接入沙箱支付来模拟，订单状态改为已支付
6. 办理入住：管理员把订单状态改为已入住，同时绑定具体客房号
7. 退房结算：把订单改为已完成，释放房间

如果你愿意增加一点复杂度，还可以在支付前加一个"预占库存"步骤——用户下单后锁住房型数量15分钟，超时不支付自动释放。这个机制就是热度词里的"springboot定时任务"典型应用场景。

4.2 并发防超卖：同一间房不能被订出去两次

这是整个系统含金量最高的技术点，必须单独拿出来讲。现实场景：剩最后一间豪华大床房，两个客人同时下单，如果代码只做了"先查库存再扣减"两步操作，并发情况下两个请求都查到了库存为1，都认为有房，都能下单成功——超卖了。

解决思路有三个层次：

方案一：乐观锁（最推荐做进毕设的）

给房型表加一个version版本号字段。下单时先SELECT查出version，更新库存时带上这个version：

UPDATE room_type SET stock = stock - 1, version = version + 1 WHERE id = #{typeId} AND version = #{oldVersion}

MyBatis执行后返回受影响行数，如果影响行数为0，说明version已被其他请求修改，当前请求失败，返回"手慢了，房间被抢走啦"。这个方案代码量小，逻辑好讲，答辩时解释乐观锁和悲观锁的区别是加分的。

方案二：悲观锁

SELECT ... FOR UPDATE把行锁住，别人查不到这条记录，等当前事务提交后才释放。实现上要配合@Transactional使用。优点是不会出现更新失败重试，缺点是并发性能差——但对于毕设这种并发量，完全够用。如果要讲SHOW ENGINE INNODB STATUS之类的底层机制，工作量上来。

方案三：Redis分布式锁

热度词里出现了Redis的影子。用setIfAbsent加锁，设置过期时间，业务执行完释放锁，这是小系统实现分布式锁的经典做法。但它引入了一个新组件，系统复杂度上升，如果对Redis不熟，可能出现锁没释放导致死锁这类自己查不出来的问题。我的建议是方案一打底，论文里把方案三作为"优化方向"提一句就够，不要真引进来。

4.3 事务边界：哪些操作必须打包处理

下单操作不是单条SQL，而是"查库存→扣库存→生成订单→可能还要写状态日志"一串操作。如果中间某一步失败了，前面的操作必须全部回滚，否则会出现库存扣了订单没产生的严重问题。

这就要给服务方法加事务注解：

@Transactional(rollbackFor = Exception.class) public OrderResult createOrder(CreateOrderRequest request) { // 1. 参数校验：日期合法性、入住人数 // 2. 库存校验：查可用房间数，大于0才继续 // 3. 乐观锁扣减库存 // 4. 生成订单记录 // 5. 返回订单信息（待支付） }

rollbackFor = Exception.class这个必须有——Spring的@Transactional默认只在RuntimeException时回滚，普通的受检异常不会触发回滚。如果漏了这句，业务上抛一个Exception出去，数据库库存已经减了，订单一查没有，这就是经典的"不完整原子性"bug。

4.4 超时未支付自动取消：定时任务的正确用法

用户在待支付状态停了20分钟不付款，房间就白白被他占着，别人订不了。解决方式很直接：用Spring Boot的@Scheduled定时任务，每1分钟扫描一次待支付订单，超过支付时限的自动改为已取消状态，并回补房型库存。

@Component public class OrderTimeoutTask { @Autowired private OrderService orderService; @Scheduled(cron = "0 */1 * * * ?") public void cancelTimeoutOrders() { // 1. 查询所有待支付且创建时间超过15分钟的订单 // 2. 逐单状态改为已取消 // 3. 回补库存 } }

启动类上加@EnableScheduling。这个功能做进去之后，演示效果很直观：提交订单后把系统时间改到超过15分钟，等定时任务跑完，去看订单状态和房型库存，自动完成闭环。不过需要提醒的是，@Scheduled定时任务默认是单线程串行执行的，如果任务执行时间很长，会阻塞下一个任务。毕设阶段数据量小，感受不明显，但最好写成独立线程池或@Async异步方式，这也是一个能体现工程思维的细节。

5. 从IDEA配置到Vue打包再塞进Spring Boot：集成部署的高阶坑

5.1 IDEA中配置启动参数：端口、热部署和编码

热度词里那句"idea 2026 怎么配置springboot服务 编辑配置数据 比如启动端口"，本质问的是Run Configuration的用法。

其实修改端口的第一优先方式不是IDEA的配置面板，而是application.yml：

server: port: 8081 servlet: context-path: /hotel # 可选，让所有接口带前缀

如果要改IDEA里一次性的运行参数，是Run → Edit Configurations → 选你的Application启动类 → Program arguments里填--server.port=8082，这个参数的优先级高于配置文件。说白了，IDEA的配置面板最终也是把参数透传给Spring Boot启动命令，真正起作用的还是Spring Boot的参数解析机制。

热部署建议加上spring-boot-devtools依赖，改代码后自动重启，不用手动点那个小乌龟图标。但注意一个坑：devtools的自动重启依赖构建时机，IDEA里要打开"Build project automatically"，不然改了代码不会触发。另外，如果用了@Scheduled定时任务，devtools重启会导致定时任务重复注册，这个我自己遇到过，调试时偶尔会出现任务跑两次的情况，需要手动把旧进程结束掉再启动。

5.2 一个主流的做法：Vue前端打包进入Spring Boot

热度词中有个非常实际的问题："vue打包放进springboot中"。这个需求源于毕设答辩时往往只有一台电脑一个应用，不方便起两个服务，把Vue的前端dist包放进Spring Boot的静态资源目录是主流做法。

具体操作分四步：

1. 前端项目根目录执行npm run build，生成dist文件夹
2. 把dist文件夹里的内容复制到Spring Boot项目的src/main/resources/static目录下
3. 重新打包后端：mvn clean package -DskipTests
4. 运行jar包，浏览器访问http://localhost:8080/，看到的就是前端页面

这个方案能跑通的关键是：Spring Boot默认把/static（以及/public、/resources、/META-INF/resources）作为静态资源目录。但有个大坑——前端用的是history路由模式时，刷新页面会出现404，因为刷新请求打到了后端，而后端没有对应的接口处理。

最省事的解法：前端路由模式改成hash模式，也就是http://localhost:8080/#/index这种带#号的URL，刷新不会发请求到后端，不会404。如果你想保留history模式，就需要在后端配置一个转发规则：所有非接口路径都转发到index.html，这个配置稍微复杂一点，毕设阶段更推荐hash模式，省心又够演示。

另外一个必踩的坑是接口联调时的跨域问题。前端Vue开发时跑在localhost:5173，后端跑在localhost:8080，端口不同就是跨域。开发期在前端的vite.config.js里配代理：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/xxx会被代理转发到后端，浏览器不直接跨域。如果前后端已经打包到一起了，同域同端口，跨域问题就不存在了，这也是"打包进Spring Boot"方案的另一个舒服之处。

5.3 application.yml里的关键配置

一个能正常连接数据库和跑起前后端整合的application.yml，是经验清单一样的存在：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 10MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

map-underscore-to-camel-case: true必须开，这能让数据库的下划线字段自动映射到Java的驼峰属性，比如check_in_date对应checkInDate，省掉手写ResultMap的重复劳动。

连接MySQL时最容易出的错误是serverTimezone时区配置。中国本地的MySQL没配时区，Java连接时报错The server time zone value...，加上serverTimezone=Asia/Shanghai就好。还有useSSL=false，本地开发关掉SSL握手，减少一个报错源。

MyBatis Plus的逻辑删除配置值得展开一下："订单列表"和"删除订单"是我建议必做的，但是真的从数据库把记录删掉，还是用一个deleted字段逻辑标记？我建议用逻辑删除——数据完整性和可追溯性都更好。配置了上面的logic-delete之后，MyBatis Plus会自动在所有查询SQL里拼上WHERE deleted=0，删除操作自动变成UPDATE ... SET deleted=1，完全不用手写。

5.4 打包构建的最终形态

整个项目完成后，交付物是一个可执行的jar包。构建过程就三个命令：

# 后端 mvn clean package -DskipTests # 前端 npm run build # 然后把前端dist内容拷进后端static目录，重新打包

最终纯jar包化。运行方式：

java -jar hotel-system.jar --spring.profiles.active=prod

如果嫌命令行起jar麻烦，用nohup java -jar hotel-system.jar > log.txt 2>&1 &丢到后台跑，日志输出到文件方便排查。这个交付形态在论文"系统部署"章节里很好写：单体架构、一键部署、跨平台运行。

6. 答辩最容易被追问的技术细节与应对思路

毕设答辩的实质是让评审老师相信"这个系统真的是你做的，而且你真的理解它"。我带队时经常提醒学生：不要怕被追问，关键是提前把"可能会被问到的点"全部摸一遍。下面这几个点，是我总结的springboot酒店客房预订系统答辩命中率最高的追问区域。

6.1 Spring Boot自动装配原理：必问三连

评委会问"你说你用了Spring Boot，那它到底是靠什么机制省去了那些繁琐配置的？"

这个问题答案的核心是"自动装配"（AutoConfiguration）。可以这样通俗回答：Spring Boot在启动时会扫描META-INF/spring.factories或新的AutoConfiguration.imports文件，这些文件里列出了所有需要自动装配的配置类。以数据源为例，DataSourceAutoConfiguration看到classpath里有MySQL驱动和spring.datasource.url配置，就自动帮你创建好HikariDataSource。你想改啥？application.yml里写。这就是"约定大于配置"的实现原理。

平时在网上可以看到的热门话题"springboot自动装配原理详解"，用的就是这个思路。答辩时把这个讲清楚，已经超过80%的学生了。

6.2 为什么选MyBatis Plus而不是JPA

这个追问本质是在考你ORM选型的判断力。我的标准回答：

• MyBatis Plus在SQL层面有完全的控制力，复杂查询——比如"查某时间段可用客房数"这种带NOT EXISTS子查询的SQL——能保证执行出的SQL和你设计的一致，性能可以预见
• 分页插件、逻辑删除、条件构造器这些现成能力，减少大量样板代码
• 国内企业用MyBatis系的比例远高于JPA，毕业之后进公司更无缝衔接

但也要承认JPA在简单CRUD场景效率更高。这样正反都讲，显得你不是只背了结论，而是真的比较过。

6.3 事务、并发、分布式：三层追问的递进关系

如果商店里只剩最后一件衣服，两个顾客同时恰在提交订单时，恰好都通过了库存检查——系统会不会把这件衣服卖给两个人？这问题是个递进式：先问你能不能说出问题（超卖），再问你解决方案的思路（乐观锁/悲观锁），最后问你这两个方案分别在什么场景下更合理。

我的建议是把乐观锁和悲观锁的区别做成一个小表格放在脑子里：

对比项	乐观锁	悲观锁
思想	更新时检查版本	访问时锁住资源
实现	version字段+影响行数判断	SELECT FOR UPDATE
并发性能	高，失败后重试或提示	低，排队等待
适用场景	读多写少，冲突概率低	写多，冲突概率高

酒店预订是典型的读多写少场景，乐观锁就够了。这个逻辑讲出来，老师会觉得你是有工程判断力的。

6.4 日期冲突SQL的边界说明

"为什么你判断订单时间冲突用的是NOT (...)而不是直接判断交叉？"这问题实际上是考SQL逻辑思维。直接写法容易遗漏边界情况，NOT (新离店 <= 旧入住 OR 新入住 >= 旧离店)把"完全不相交"的两个情况先排除，剩下的必然相交，这是数理逻辑里的德摩根律。回答时可以把新旧订单首尾相接的情况单独拎出来讲：如果你不允许同一天首尾相接，直接在两条OR条件里加等号处理即可——这让老师知道你不只是抄了一条SQL，而是真理解这个判断的边界条件。

6.5 一个提升印象分的测试意识

毕设答辩演示环节通常局限于"页面能点、订单能跑通"，但如果你能主动展示测试成果，印象分会明显提升。

• 单元测试：OrderServiceTest里写几个核心用例，比如乐观锁冲突回滚、日期冲突拦截、超时订单自动取消
• 接口测试：用Postman导出一份接口调试集，展示各接口的请求响应
• 性能测试：有条件的用JMeter对"查询房型列表"接口压1000个并发，贴出TPS和响应时间数据，论文的"系统性能测试"章节素材也一并有了

这些测试不需要覆盖全模块，挑核心的关键业务覆盖就行。论文里写"系统核心模块的单元测试覆盖率达到XX%，接口平均响应时间XXms"，整篇论文的工程完整度都会上一个台阶。

6.6 个人项目中踩过的坑，也是最好的谈资

答辩时与其机械背诵流程，不如主动讲讲你遇到的真实问题和解决过程。比如：

• 下单时库存扣了，但订单因为参数校验失败没生成，后来加了@Transactional(rollbackFor = Exception.class)才解决——这是事务原子性的真实案例
• 前端打包放进Spring Boot后刷新404，后来改成hash路由模式解决——这是前后端集成部署的真实案例
• 数据库date字段和Java的LocalDate时区对不上，报时间解析错误，统一为Asia/Shanghai时区后解决——这是环境配置的真实案例

这些实际踩坑经历比任何理论背诵都更有说服力，因为它是你的、是唯一的，老师一听就知道不是你抄的。

我的体会是，这种题目的最佳完成状态不光是"写完了系统"，而是"把我的设计和得失完整地复盘了一遍"。做完之后把上面的状态机、事务边界、并发方案、部署链路这几个问题在脑子里过一遍，你会发现：这个题目真正教会你的，不是那些API怎么调，而是怎么把一个模糊的业务需求，一步步落地成可靠解决它的软件系统。这才是毕设的初心所在。后面如果还要扩展，可以朝着小程序端、在线选房、财务报表图表这些方向做，但那都是拿到合格之后的事了。先把主系统做扎实，比什么包装都值。