毕设选了个酒店预约系统，听起来平平无奇，但真正动手做完这套SpringBoot项目之后，我发现这题目比想象中“有货”多了。作为过来人，我准备把这套系统的完整设计思路、核心实现逻辑和踩过的坑一次性讲清楚，给正在为计算机毕业设计发愁的同学一份可以直接“抄作业”的参考。
先把结论放前面：以SpringBoot为后端框架、Vue为前端、MySQL存业务数据、Redis扛并发缓存的酒店预约系统，是当前最稳妥也最容易出彩的毕业设计组合。它不像电商系统那样烂大街，也不像图书管理那样业务单薄，恰好卡在一个“评委觉得有价值、开发量适中、技术点丰富”的位置上。这套选题既涉及核心的预约订单流程，又牵涉房间状态管理、价格策略、权限控制，能展示的技术广度足够撑起一篇像样的毕业论文。
1. 毕设选题：为什么酒店预约系统是性价比最高的选择
每年毕业季，计算机专业的学生都在同一个问题上犯难：做什么题目才能在有限时间内完成、又能在答辩时有话可说？我见过太多人选了“XX管理系统”然后被评委一句话问死的案例，也见过选了超大平台型项目最后只能拼凑代码的惨状。酒店预约系统恰好处于两者之间的甜蜜区。
1.1 业务复杂度适中，技术展示面广
酒店预约的业务链条本身是完整的：用户浏览房型、查看可订日期、提交订单、支付确认、办理入住、退房结算。这个链条既能体现常规增删改查，又能在订单库存、房态控制、并发防超卖等环节展现出高于基础CRUD的技术含量。对毕设而言，这种“在常规中带一点挑战”的项目，恰恰是拿高分的关键。
另一个好处在于角色权限天然清晰：普通用户能注册、登录、浏览、下单、支付、查看订单、提交评价；管理员能维护房型、设置价格、管理房间、处理订单、查看统计报表。双角色就意味着一套完整的RBAC权限模型，这块单独拿出来就能在论文里写一章，答辩时也能讲得清楚。
1.2 对比其他热门选题的优势
- 相比图书管理系统：业务只有借和还，太单薄，连数据表都凑不够八张，答辩时评委想多问两句都找不到切入点。
- 相比通用商城系统：代码能抄的太多，老师看一眼就知道是照搬的，且支付、物流等环节在毕设环境下很难真正落地。
- 相比社交平台或内容社区：涉及实时通信、Feed流、推荐算法，复杂度失控，半年时间大概率做不完。
- 酒店预约系统则处于中间：规模可控、边界清晰、每个模块都有存在价值，而且可以正向扩展出评价系统、统计报表、定时任务等亮点功能。
1.3 这套系统的核心价值点和答辩话题点
能支撑答辩深挖的技术点，我在做的时候就特意做了标记：Redis缓存热点数据对抗高并发查询、数据库层面防止订单重复提交、房间状态字段与订单状态字段的分工协同、基于定时任务实现超时未支付订单自动取消、JWT令牌刷新策略等等。每一条都可以展开成一篇小论文，评委追问的时候你心里不慌。
我自己做完这套系统后最大的体会是：毕设选题的好坏，直接决定你论文有没有足够的“论证材料”。选酒店预约，等于从一开始就给自己攒下了写论文的“弹药”。
2. 技术选型的底层逻辑：为什么是SpringBoot 2.7 + MyBatis Plus + Vue 3
关于技术栈，不夸张地讲，我花了一整天对比权衡。很多同学直接打开IDEA用Spring Initializr一键生成项目，选了什么依赖自己都说不上来，这种状态去做毕设非常危险。下面把我的选型思路完整拆开讲。
2.1 后端框架：SpringBoot 2.7.x版本的权衡细节
SpringBoot的版本选择是第一个坑。我用的稳定组合是SpringBoot 2.7.18搭配JDK 8，不是怕新不敢用，而是这套组合的生态最兼容。做过项目的都知道，SpringBoot 3.x强制要求JDK 17，而很多学校机房和部分老旧教学环境还是JDK 8，如果答辩时需要现场演示部署，版本不兼容会让你现场翻车。
另外，SpringBoot 3.x中很多第三方starter集成方案还不够完善，比如一些老牌权限框架、代码生成器、Excel工具库在3.x下会报各种兼容性错误。2.7.x则拥有多年来沉淀下来的海量排错资料，遇到问题搜索一下就有答案，这对我这种需要兼顾论文和开发的毕设学生太重要了。
2.2 持久层方案：MyBatis Plus取代纯MyBatis的决定性理由
我第一次用纯MyBatis写项目时，光写单表CRUD的XML就写了将近两百行标签。换成MyBatis Plus之后，内置的BaseMapper直接提供了selectById、insert、updateById等基础方法，单表操作完全不用手写SQL，效率提升非常明显。
更重要的是MyBatis Plus的条件构造器LambdaQueryWrapper，在做条件筛选场景（比如按入住日期查可订房间、按订单状态查订单列表）时，代码可读性比拼接SQL高出一个量级。下面是典型的动态条件查询示例：
@Override public Page<RoomTypeVO> queryAvailableRoomTypes(Integer hotelId, LocalDate checkInDate, LocalDate checkOutDate, Integer guestNum) { LambdaQueryWrapper<RoomType> wrapper = Wrappers.lambdaQuery(); wrapper.eq(RoomType::getHotelId, hotelId) .eq(RoomType::getStatus, 1) // 1表示启用 .le(RoomType::getMaxOccupancy, guestNum) // 满足入住人数 .orderByAsc(RoomType::getPrice); // 这里还需要关联房间库存表做可订校验，稍后详述 return roomTypeMapper.selectPage(new Page<>(1, 10), wrapper); }这段代码的逻辑意图很明确：酒店ID匹配、房型上架状态、最大入住人数满足客人数量，再按价格升序排列。相比手写XML映射，这种代码在论文里展示也更好讲解。
2.3 前端方案：Vue 3 + Element Plus而非其他选择的思考
前端我使用的是Vue 3 + Element Plus + Axios + Vite。倒不是说Vue 2不好，而是Vue 3的Composition API在处理复杂表单和状态联动时确实更顺手，而且Element Plus的组件质量和文档完善度高，表格、表单、日期选择器这些后台管理系统高频组件都开箱即用。
前后端分离架构保证了后端只提供RESTful API，前端通过Axios统一请求封装完成数据交互。我在前端封装了一个request.js工具模块，里面统一处理了Token注入、HTTP状态码拦截、错误提示，这个模块虽然代码量不大，但却是前后端联调效率的关键。
2.4 中间件选择：Redis和MySQL怎么分工
Redis和MySQL的职责划分是考官爱问的点之一：MySQL是业务数据的最终持久化存储，保证数据不丢、事务可靠；Redis是热数据的高速缓存层，扛住高并发场景的读请求压力。
具体到我这个项目里：房型基本信息（如图片、介绍、基础价格）用Redis做缓存，设置合理的过期时间；热门房型的库存数量也放在Redis中做预扣减，防止大量用户同时下单时数据库行锁争用。但如下单后的订单记录、支付流水这些强一致性数据，必须落MySQL，靠数据库事务保住底线。这套“缓存+数据库”双层的设计，在论文里是非常好写的架构亮点。
3. 数据库建模实战：从表结构设计看酒店业务的边界
数据库设计是毕设系统的地基。我见过太多人上来就建表，表建完了发现业务逻辑推不动，只能推翻重来。酒店预约系统的表设计要围绕“航拍视角”来建：先想清楚系统里有哪些实体、实体之间是什么关系，再动SQL。核心实体包括：用户、酒店、房型、房间、订单、支付流水、评论、管理员。
3.1 核心数据表的结构与关系
| 表名 | 核心字段 | 说明 |
|---|---|---|
| t_user | id, username, password, real_name, phone, id_card | 普通用户和注册用户的信息 |
| t_hotel | id, hotel_name, address, star_level | 酒店基本信息，支持多酒店扩展 |
| t_room_type | id, hotel_id, type_name, price, area, bed_info, max_occupancy | 房型定义表，价格范围 |
| t_room | id, room_type_id, room_number, floor, status | 具体房间，status标识是否维护中 |
| t_order | id, order_no, user_id, room_type_id, check_in_date, check_out_date, guest_name, guest_phone, total_price, status, create_time | 订单主表 |
| t_payment | id, payment_no, order_id, pay_amount, pay_method, pay_status, pay_time | 支付流水表 |
| t_comment | id, order_id, user_id, rating, content, create_time | 评价表 |
| t_admin | id, username, password, role | 后台管理员账号 |
在设计时需要特别注意的两个细节：一是订单表不直接关联具体房间号，而是关联房型表，具体分配哪一间在入住办理时再确定；二是金额字段统一采用decimal(10,2)，绝不用float或double，否则金额出现0.01的误差，赔上几天时间排查都不冤。
3.2 为什么订单表要关联“房型”而不是“单个房间”
这个设计我专门查了不少资料验证。酒店和一般商品最大的区别在于：预订时用户所定的是某个类型的房间，而不是固定的XX号房。酒店前台会根据当天房态在同类房型中灵活分房。如果订单创建时直接锁定某个具体房间，反而会造成资源浪费——比如五间大床房，今天入住三间，卖出去的三单各锁一间，剩余两间全空，而实际上还有两个大床房订单可以承接。
所以订单表存room_type_id是标准的业务做法。到了办理入住环节，前台操作员再选择具体房间号并更新房间表状态。这个细节理解透了，数据库表之间的关系也就自然理顺了。
3.3 订单状态的枚举设计与流转控制
订单状态我设计如下：0待支付、1已确认、2已入住、3已完成、4已取消、5待评价。这里需要额外解释“待评价”和“已完成”的区别：用户退房后订单变成已完成，系统同时生成一条待评价记录，用户评价后状态变为已评价。如果直接用一个status搞定所有阶段，状态判断会混乱。
为了保证状态流转的严谨性，我在后端Service层写了一个状态变更的校验方法，不允许跳过中间状态进行跳变。比如从待支付直接跳到已完成，这类非法操作在接口层就直接拦截。
private boolean validateStatusTransition(Integer currentStatus, Integer targetStatus) { // 定义允许的状态流转映射 Map<Integer, List<Integer>> transitionMap = Map.of( 0, List.of(1, 4), // 待支付 -> 已确认 / 已取消 1, List.of(2, 4), // 已确认 -> 已入住 / 已取消 2, List.of(3), // 已入住 -> 已完成 3, List.of(5) // 已完成 -> 待评价（用户已评价则为已评价） ); return transitionMap.getOrDefault(currentStatus, List.of()) .contains(targetStatus); }3.4 房态与订单日期的双重约束实现
这是我建表过程中遇到的第一个真问题：用户预订3月15日到3月17日的大床房，那么怎么判断这期间还有没有空房？
最朴素的思路是把所有房间查出来，逐个判断是否有订单与该日期区间重叠。对应的SQL条件长这样：
SELECT COUNT(*) FROM t_order WHERE room_type_id = #{roomTypeId} AND status IN (0, 1, 2) -- 待支付、已确认、已入住均占用房态 AND #{checkInDate} < check_out_date AND #{checkOutDate} > check_in_date这段SQL的核心逻辑是区间重叠判断：新订单的入住日期早于已有订单的离店日期，且新订单的离店日期晚于已有订单的入住日期，则说明时间有交集。这个判断条件看着简单，但很多人第一次写都会漏掉等号边界，导致边间房被重复预订。
在此基础上，可订数量=该房型总房间数-已被订单占用的房间数。如果结果大于0，则可继续下单。这种基于数据库聚合查询的方式，在中小并发量下单量下毫无压力，完全够毕设场景使用。
4. 核心功能实现：预约下单全链路的代码级拆解
做了这么多铺垫，接下来进入整个系统最关键的部分：预约下单的实现逻辑。这一节我会掰开揉碎讲清楚一单预订从用户点击下单到最终确认，中间经了哪些环节，每个环节是怎么落库的。
4.1 用户下单选房的完整接口流程
预约下单的接口调用链如下：用户在前端选择入住日期、离店日期、入住人数、房型，点击提交订单后，前端调用后端/api/order/create接口。后端在Controller层接收请求后，按事务方式执行以下步骤：
- 参数合法性校验：入住日期不能早于今天，离店日期必须晚于入住日期，入住人数不能超过房型最大入住量。
- 价格计算：根据房型单价乘以入住晚数计算出总价。注意这里有个小陷阱：跨周末或节假日的订单可能需要不同价格策略，毕设版本可以简化为统一单价，但在设计上要预留一个PriceCalculator接口，方便扩展。
- 并发安全控制：使用Redis分布式锁（以roomTypeId+日期为key）锁住房型在该日期段的库存，防止两个订单同时抢最后一间房。
- 订单落库：生成唯一订单号、状态置为待支付，并创建订单记录。
- 库存预扣减：Redis中对应房型的可卖余量减1，MySQL中t_room库存表相应更新。
- 返回订单号：前端收到后跳转支付页面。
4.2 防重复下单与超卖问题：分布式锁实战
酒店预约和抢火车票本质上属于同一类高并发写场景，防超卖是核心难点。我先说结论：毕设阶段不建议上消息队列或Sentinel这种重方案，用Redis的原子性操作解决就够了。
public Result createOrder(OrderCreateDTO dto) { String lockKey = "hotel:roomType:" + dto.getRoomTypeId() + ":" + dto.getCheckInDate() + ":" + dto.getCheckOutDate(); // 尝试加锁，等待最多3秒 boolean locked = redisLock.tryLock(lockKey, 3000); if (!locked) { return Result.error("系统繁忙，请稍后重试"); } try { // 查询当前可订数量 Integer remain = stockService.getRemainingStock(...); if (remain <= 0) { return Result.error("该日期段房型已满房"); } // 先检查用户是否已有同日期段的未支付订单 int existed = orderMapper.countUnpaidOrder(userId, dto.getRoomTypeId(), dto.getCheckInDate(), dto.getCheckOutDate()); if (existed > 0) { return Result.error("您已有相同日期的待支付订单，请勿重复下单"); } // 创建订单、扣减库存 return doCreateOrder(dto); } finally { redisLock.unlock(lockKey); } }这套逻辑中两个关键动作：加锁保证同一房型同一日期段只有一个线程能进来创建订单；幂等校验保证同一用户同一日期段只能有一单待支付订单。双保险下，超卖问题基本被堵死。
4.3 订单超时自动取消：定时任务与延迟消息的方案选择
用户下单后15分钟内不支付，订单要自动取消并释放库存。这个场景大家第一时间会想到使用SpringBoot自带的@Scheduled定时任务扫描，每30秒去数据库扫一遍超时订单。这个方案能跑通，但存在较大的性能浪费：每30秒全表扫描一次，数据量大了之后对数据库压力不小。
毕设场景这个方案其实够用，但在论文里我提供了一个进阶方案：使用Redis的Key过期事件或者延迟队列ZSet实现更精准的超时处理。Redis ZSet按订单过期时间戳作为score排序，定时器每分钟扫描score小于当前时间戳的订单，触发取消操作。代码逻辑如下：
// 下单时将订单ID和过期时间写入Redis延迟队列 stringRedisTemplate.opsForZSet().add( "order:timeout", orderId.toString(), expirationTimestamp );4.4 入住与退房办理的房态变更逻辑
预订成功之后，还有最后一个重要的核心流程：办理入住和退房。
办理入住时操作员选定具体房间，此时才将t_room表中对应房间的status从0空闲状态改为1已入住，同时把订单状态从1已确认改为2已入住，并记录实际入住房间号。退房时反向操作：房间状态改回0空闲，订单状态推进到3已完成，同时生成应收账单。
这里有一个经营上的细节值得在论文里强调：退房检查是否需要支持延时退房收费？毕设版本我建议简化为统一退房时间12:00，超时按半天计费需要额外生成加收账单。这个功能虽然不影响核心流程，但体现综合考虑了酒店经营的真实场景，评委印象分会显著提升。
5. 权限与安全设计：论文里能写但很多毕设省略的模块
酒店预约系统涉及个人订单信息、身份证号、支付记录等敏感数据，权限控制和安全设计不是加分项，而是必需项。这块我在系统设计时做了三层防护，从外到内分别是：前端路由拦截、后端接口鉴权、数据级权限控制。
5.1 基于JWT的无状态认证机制
项目采用JWT作为登录凭证。用户在第登录成功后，后端生成包含userId和角色信息的Token返回前端，此后每次请求都在HTTP Header中携带Authorization: Bearer <token>。
JWT的核心优势是服务端无需存储会话状态，天然适配前后端分离架构。具体实现上，我用了一个简单高效的封装类，负责生成与解析Token：
public class JwtUtils { private static final String SECRET_KEY = "your-secret-key-change-me"; private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000L; // 24小时过期 public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(userId.toString()) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } }在SpringBoot的拦截器里统一校验JWT，再配合一个自定义注解@RequireRole控制接口的角色访问权限。管理员专属接口只有传入了角色为admin的Token才能访问。
5.2 BCrypt密码加密：别再用MD5存密码了
很多入门教程喜欢用MD5加盐存密码，那已经是过时得掉渣的做法。MD5本身是摘要算法而非加密算法，计算速度极快，暴力破解成本极低。我和大家分享一个反直觉的知识：密码学中要求“计算足够慢”，加盐慢哈希才是存密码的正确姿势。
我使用的是BCrypt算法，Spring Security框架内置了BCryptPasswordEncoder，每次哈希结果都不同，自带加盐属性。注册时代码如下：
BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); user.setPassword(encoder.encode(user.getPassword()));登录校验时使用encoder.matches(rawPassword, encodedPassword)方法比对。整个过程中数据库里永远不会出现明文密码，即使数据库泄露，攻击者也无法逆推出原密码。这一条在论文安全章节里必须写上，是评委眼中的标准答案。
5.3 我的额外安全加固经验：接口防刷与参数校验
除了认证之外，我在系统里还做了几件提升安全感的加固措施，事虽然小，但效果很好：限制单个IP的登录失败次数，连续失败5次锁定15分钟；所有Controller参数启用@Valid注解和自定义校验器，防止恶意构造请求参数；上线前关闭SpringBoot默认的Swagger访问入口，避免暴露接口文档。
安全这块，我踩过一个很尴尬的坑：第一次上线时忘记改了默认的Actuator端口，导致任何人都能通过/actuator/env读取环境变量中的数据库连接信息。当天晚上就收到异常告警，紧急下线后加了Spring Security白名单规则。安全无小事，虽然没有造成实际损失，但把自己吓出一身冷汗。
6. 开发全流程实录：从空项目到可部署运行的完整路径
前面讲的是架构和核心功能的设计逻辑，这一节我按时间线把从零构建整套系统的步骤完整梳理一遍，尽量把我原来踩过的坑也标注出来，让大家避开。
6.1 环境准备与项目初始化要点
我本地的运行环境是：Windows 11 + JDK 8 + Maven 3.8 + MySQL 5.7 + Redis 6.x + Node.js 16。开发工具用的是IDEA，装好Lombok、MyBatisX插件。
创建项目时建议在start.spring.io网站生成基础骨架，勾选以下依赖：Spring Web、MyBatis Framework、MySQL Driver、Spring Data Redis、Validation、Lombok。Spring Cloud相关的一律不勾，毕设用不上分布式组件，徒增部署负担。
有一个小技巧分享一下：Maven仓库地址建议切换为阿里云镜像。国内网络环境下默认Maven中央仓库拉依赖经常失败或超时，换成阿里云镜像之后，整个项目依赖下载速度从几十分钟缩短到几分钟。
<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>6.2 后端工程结构规范：包名分层决定你代码的“质感”
Java后端工程的结构直接反映了开发者的编码习惯。我第一次写的时候包结构乱七八糟，后来重构过一次。最终采用经典的分层模式：
com.example.hotel ├── controller # 接口层，只做参数接收与结果封装 ├── service # 业务层，核心逻辑 │ └── impl # 业务实现类 ├── mapper # 数据访问层 ├── entity # 数据库实体类 ├── dto # 前端请求参数对象 ├── vo # 后端返回视图对象 ├── config # 配置类 ├── common # 通用类（Result封装、异常处理、常量） └── utils # 工具类这层结构最大的优势是单向依赖：controller依赖service，service依赖mapper，不允许反向依赖。所有前端请求参数用DTO封装，不直接暴露entity给前端，避免把数据库字段结构泄露到页面中。这套分层规范，也正好对应论文里的系统架构设计章节，属于标准的教科书式架构实践。
6.3 统一返回结果与全局异常处理：提升开发体验的隐形功臣
后端接口如果每层都各写各的返回格式，前后端联调时会非常痛苦。我在common包中定义了一个统一的Result类，包含code、message、data三个字段，所有接口一律返回这个类型。前端Axios拦截器解析该结构，code为200时走成功逻辑，否则统一弹出错误提示。
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }配套的全局异常处理器使用@RestControllerAdvice注解，统一捕获参数校验异常、业务异常和系统异常，日志记录异常堆栈。这样既能保证前端看到的错误信息是友好、可读的，又能在后端留存完整的排错日志。
6.4 测试与调试：接口自测的完整方法
毕设系统涉及几十个接口，不建议等前端开发好再联调，应该完成后端隔离自测。我用的工具是Apifox，它同时支持接口调试、自动化测试和API文档生成。每写完一个模块，就创建对应的接口测试集，把正常、异常、边界等场景全部跑一遍。
例如测试下单接口时至少覆盖以下用例：正常参数下单成功、入住日期早于当天被拒、离店日期等于入住日期被拒、房间满房被拒、库存余量为1时两个订单并发发起只有一个成功、未登录时携带无效Token被拦截。
接口自动化测试集既能在开发期帮我快速回归验证，又能作为论文附录中的“系统测试”章节素材，一举两得。
7. 部署与答辩准备：别让最后一公里毁掉整年努力
系统开发完成只是开始，能否让评委顺利看到效果、讲解时能否条理清晰，这最后一步的重要性不亚于编码本身。
7.1 本地部署与打包的经验
后端打包使用Maven的package命令，生成jar包后直接通过java -jar启动。项目中使用到的配置项放在application.yml中，但敏感信息一定要使用环境变量或外部配置文件的方式注入。我在部署时把数据库密码、Redis密码改成通过启动参数传入，配置文件里只留占位符。
java -jar hotel-system.jar --spring.datasource.password=${DB_PASSWORD} --spring.redis.password=${REDIS_PASSWORD}前端在Vite构建后生成dist目录，我用Nginx做了静态资源托管，同时配置了反向代理把/api前缀的请求转发到后端服务的8080端口。这段Nginx配置也是答辩中“部署方案”章节的重要材料。
7.2 演示环境的准备细节：提前演练、预案充足
答辩演示现场总会出意外：项目启动失败、数据库连接超时、前端页面白屏。作为过来人，我的建议是演示环境单独准备一台干净的机器，确保JDK、MySQL、Redis等组件全部预装好，开机就能一键启动。
演示数据也要提前准备充足：至少创建10个房型、每个房型8间以上房间、提前录入几十个成功订单和一个待支付订单。演示时先用待支付订单展示“超时自动取消”功能，再从头走一遍从注册到下单支付评价的完整用户旅程，最后切换到管理员视角展示订单管理和房态管理，整个流程五分钟内讲完，重点突出，节奏紧凑。
7.3 论文写作与答辩问答的高频考点
住宿分类论文的章节安排我按照“绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结”的经典结构来写。重点投入写在系统设计上，包括用例图、ER图、功能模块图、时序图，这些来自我项目的真实材料，绝对不存在抄袭嫌疑，答辩的时候也能迅速引出讲稿。
关于答辩被提问，评委最喜欢问的方向，我做了一个清单，大家可以对照自检：
- 为什么订单表关联房型而不是具体房间？——解答见3.2节。
- 如何防止同一房间被重复预订？——解答见4.2节分布式锁。
- 用户下单但一直不支付，库存什么时候释放？——解答见4.3节延迟取消。
- Redis和MySQL数据不一致怎么办？——可答缓存过期策略加数据库兜底校验。
- 密码为什么使用BCrypt而不是MD5？——解答见5.2节。
把这些问题逐条准备好，答辩通过难度并不高。
7.4 项目扩展思路：让“工作量”超出评委预期
酒店预约系统还有很大的进化空间，这是毕设拿高分的“杀手锏”。我自己在基础功能之外，额外扩展了三个模块：基于ECharts的入住率统计报表（管理员首页可视化大屏）、基于Spring Boot定时任务的价格日历批量更新、基于WebSocket的订单状态实时通知。
这三个扩展虽然都是锦上添花，但让评委明显感觉到这不仅仅是“课程作业”，而是一个有真实落地意识的作品。如果时间和精力允许，从这三项中挑一项做深做透，效果会非常明显。
8. 踩坑实录：那些上网搜不到答案的夜半时刻
代码写多了，多少会积累一些“血泪教训”。下面几条是我做这套系统时真实遇到、且翻阅无数资料才解决的问题。每一个坑都值得你标记收藏。
8.1 LocalDate与JSON序列化的时区陷阱
SpringBoot默认使用Jackson做JSON序列化，而项目用了LocalDate类型接收前端传入的日期参数。如果不做任何配置，前端传2025-06-15这种格式，后端解析会直接报错。坑了我一天之后我配置了统一的日期格式和时区：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8同时在LocalDate字段上使用@JsonFormat(pattern = "yyyy-MM-dd")注解，才算彻底解决日期类型跨端传输的问题。
8.2 MyBatis Plus自动填充的字段策略
创建时间、更新时间这类公共字段，如果每个插入操作都手动set一次，代码冗长不说，还容易漏掉。MyBatis Plus提供了自动填充功能，我实现了MetaObjectHandler接口统一维护这两个字段。
@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }这里是另一个容易踩的坑：自动填充依赖实体字段上的@TableField(fill = FieldFill.INSERT)注解，两者缺一不可。只配了Handler而实体上没加注解，填充就不会生效，而且不报任何错误，极难发现。
8.3 金额计算中的精度问题：为什么不能用double
订单金额=单价x晚数，这是最简单的乘法，但用double计算时，10.1 * 3可能得到30.300000000000004这样的结果。如果后续有折扣、满减叠加，误差会不断累积放大。我在设计之初就强制要求所有涉及金额的字段全部使用BigDecimal，并且数据库表字段类型统一为decimal。
在线课程和很多博客喜欢用double演示，看起来代码短，但实际工程中这种写法是大忌。论文写到这里我加了一段专门的注意事项：凡是涉及钱的系统，宁可多写几行啰嗦的BigDecimal加减乘除，也不要埋下精度隐患。
8.4 数据库连接池爆掉与长连接失效的应对方案
部署运行几天后，有一次后端突然报Communications link failure异常，当时第一反应是数据库服务挂了，但连上MySQL看了下进程，正常运行。排查之后发现是MySQL默认的wait_timeout为8小时，而HikariCP连接池默认最大生存时间远大于这个值，导致池里的连接已被MySQL服务端主动断开。
解决方案是在application.yml中配置Hikari连接池的有效性检测和最大生命周期：
spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 connection-test-query: SELECT 1这样配置后，每次从池中拿连接都会做一次有效性检查，失效连被自动剔除。这个故障排查过程，后来被原封不动写进了我的论文“系统维护与排错”一节，成为很有说服力的真实性素材。
9. 总结与后续建议：一个完整毕设项目的沉淀
整个项目做完，前后大约花了三周晚上和两个完整周末。回头看，最大的感受是：毕业设计选题决定了上限，设计思路决定了你的答辩下限。
从价值角度来说，这套SpringBoot酒店预约系统带给我的绝不仅仅是一份能跑的代码。在做它的过程中，我完整经历了一个真实软件项目的生命周期：需求分析、技术选型、数据库建模、接口设计、前后端联调、测试部署、文档撰写。这些能力，正是毕业后进入实际工作岗位立刻就要用的。网上很多人说毕设没用，但从我的真实体验来说，认认真真把一个还不错的毕设做完做透，收获完全超出一纸文凭本身。
如果现在让我给正在做类似毕业设计的同学几条最实在的建议，我会说：
第一，一定要自己跑通全流程，哪怕代码是参考的，也要逐行读懂再改。答辩时最怕的就是被问到代码细节一句话答不上来。
第二，不要放过数据库设计阶段。我见过太多人数据库建得乱七八糟就开始写Controller，到后面代码越写越难受，被迫推翻重来。
第三，优先保证核心链路跑通再做扩展功能。下单支付流程是主心骨，统计报表、评论功能都是锦上添花，顺序反了很容易导致核心功能粗糙。
做完这套系统后，我其实还想了两个后续扩展方向：一是把微信小程序作为前端入口，做一个用户端的小程序版；二是引入简单的推荐算法，根据用户历史订单偏好推荐房型。如果时间允许，这两个方向都能让项目再上一个台阶。
最后聊一个大家可能关心的实际问题：答辩时的演示翻车概率。我的做法是提前一天在一台全新环境虚拟机里完整跑一遍所有演示流程，确认无任何外部依赖；第二天答辩现场开机即演示，从容不迫。这种对细节的把控感，会让评委从你入场的那一刻就留下好印象。祝各位毕设顺利，答辩一次通过。
