刚做完 M238 酒店预约及管理系统这个课题趁记忆还热乎把整套设计与实现过程完整复盘一遍。这个课题在软件工程和计算机专业的课设、毕设里出镜率极高网上的成品模板也一大堆但说实话大部分模板都停留在“增删改查”层面根本没有把酒店业务里最麻烦的部分——订单状态流转、并发锁房、房态联动——做对。这篇文章围绕这类系统的完整设计链路展开需求该怎么拆、技术栈怎么选、数据库六张核心表怎么建、预约到退房的业务逻辑怎么落地、以及交付前怎么自测和准备答辩。适合正在做这个课题、或者想把这套业务逻辑真正吃透的朋友参考。1. 这个课题真正考查的是什么——需求拆解与常见翻车点1.1 业务范围没有想象中那么窄M238这个编号在很多高校的选题库里对应的是“酒店预约及管理系统”。只看题目会以为做个客房信息管理再加个预约功能就完事了实际操作过才知道一套能自圆其说的酒店管理系统至少要覆盖三类角色的完整业务闭环前台/管理员客房信息维护、房态管理空闲/入住/打扫/维修、预约订单审核、办理入住、办理退房、统计营收。客户住客注册登录、浏览房型、预约下单、支付模拟即可、取消预约、查看历史订单。系统层面订单状态机流转、房间日期冲突校验、并发场景下的防重复预定、操作日志留痕。很多人的项目挂掉不是挂在功能太少而是挂在把系统理解成了“两张表加三个页面”。实际上答辩老师最喜欢问的问题就是一个房间在同一天被两个用户同时预约你怎么处理这个问题一旦答不出来前面做得再花哨也白搭。1.2 那些交了代码但答辩挂掉的常见死法我带过几届学弟学妹也看过不少网上下载的成品总结了几个高频翻车场景第一订单状态只有“未支付/已支付”两个状态。真实的酒店订单绝不是这么简单至少要有待支付、已预约、已入住、已退房、已取消这几态每一态都要有对应的操作触发和界面入口。只做两个状态说明根本没有理解业务。第二房间和房型混为一谈。房型是商品大床房、双床房房间是具体库存301、302号大床房。如果表里只有房型没有房间那“301房间被订走了302还能订”这个逻辑就完全无法表达。第三退房之后房态不联动。退房了房间状态还是“已入住”需要管理员手动改回“空闲”这还能忍最怕的是退房后订单状态变了但房间的date记录没清导致同一房间无法再次预约这就是表和表之间缺少联动设计。第四没有任何并发处理。所有查房和锁房操作都裸写SQL没有事务没有行锁没有乐观锁。这种项目一旦演示的时候开两个浏览器窗口同时下单一间房当场翻车。1.3 正确拆解需求的方式拿到题目第一件事不是写代码而是画用例图和状态图。我当时的做法是手写三张纸一张画三个角色和各自能做的事一张画订单从创建到退房的全部状态流转一张画房态在订单不同阶段的变化。这三张纸后来就是数据库设计和答辩PPT的骨架。核心业务流就一条主线客户预约→创建订单→支付→到店办理入住→退房结账→房间转为打扫→打扫完成转为可售。所有功能设计都应该围绕这条主线展开而不是功能堆砌。2. 技术选型与工程初始化为什么锁定 Spring Boot Vue 这套组合2.1 三种主流方案的权衡这个课题的技术栈选择直接决定了开发的舒适度和答辩的接受度。我对比了三套方案方案后端前端优点缺点适合人群ASSMSpringSpringMVCMyBatisJSP学校课程常用理论匹配度高开发效率低前后端耦合重课程强制要求或导师必须要求SSMBSpring Boot MyBatis-PlusVue3 Element Plus开发效率高工程结构清晰就业导向需要会一点Vue基础绝大多数人C若依RuoYi脚手架Vue2开箱即用权限、代码生成都有代码量大答辩时容易被追问细节时间极紧只想应付我自己选的是方案B。原因很实际Spring Boot 让配置工作大幅减少MyBatis-Plus 让单表 CRUD 不写 SQLVue3 Element Plus 做后台管理界面快得惊人。而且这套技术栈和当前企业实际开发匹配度高答辩的时候老师听到你用这套组合一般不会再揪着“为什么不用XXX”这种框架之争的问题。2.2 工程分层与目录结构项目工程结构是答辩时老师一定会看的我推荐按这种方式组织hotel-admin/ ├── src/main/java/com/example/hotel/ │ ├── common/ # 通用返回结果、异常处理、常量 │ ├── config/ # 拦截器、跨域、MyBatis-Plus配置 │ ├── controller/ # 接口层 │ ├── service/ # 业务逻辑层接口实现 │ ├── mapper/ # 数据访问层 │ ├── entity/ # 实体类 │ └── dto/ # 入参出参封装 ├── src/main/resources/ │ ├── mapper/ # XML文件复杂SQL用 │ └── application.yml一个容易被忽略但很重要的小习惯Controller层只做参数接收和结果返回不写任何业务逻辑。比如“办理入住”这个动作Controller里只有一行orderService.checkIn(orderId, userId)具体判断订单是否存在、状态是否为已支付、房间当前是否为空房全部下沉到Service层。答辩时老师随便指一个Controller你能清晰说出它调了哪些Service方法、为什么这样拆这就是加分项。2.3 认证方案JWT 还是 Session管理系统必须要有登录功能而且要有角色区分。两种做法我都试过简单对比一下Session方案实现简单服务端存储状态可控但前后端分离后需要处理跨域携带Cookie的问题且集群环境下要考虑Session共享。JWT方案无状态前端存储Token请求头携带即可适合前后端分离部署。缺点是一旦签发不好主动失效但管理系统场景下这个缺点完全可以接受。我当时用的是 Sa-Token它是国产的一个轻量级权限框架接口比原生JWT操作友好太多登录后拿到token拦截器里校验角色权限两行代码搞定。如果你不想额外引依赖自己封装JWT工具类也完全够用。权限上要注意菜单和接口都要校验角色。不能只在前端隐藏“管理入口”按钮后端接口必须有拦截器验证否则任何人直接调接口就能访问管理功能这是安全设计上的硬伤。3. 数据库设计五张核心表加一张关联表订单状态机提前埋好3.1 核心表结构与字段解析我在设计阶段反复改了三次最终稳定在这个结构用户表 sys_userid、username、passwordBCrypt加密后存储、real_name、phone、role0管理员/1前台/2客户、create_time。房型表 room_typeid、type_name豪华大床房/标准双床房、price门市价、area、bed_num、max_people、description、cover_image。房间表 roomid、room_no301这种楼号房号、room_type_id、floor、status0空闲/1入住/2打扫/3维修。订单表 reservationid、order_no唯一订单号、user_id、room_id、room_type_id、check_in_date、check_out_date、night_count、total_price、pay_status0未支付/1已支付/2已退款、order_status1待支付/2已预约/3已入住/4已退房/5已取消、create_time。入住记录表 check_recordid、reservation_id、user_id、room_id、real_check_in_time、real_check_out_time、deposit押金、remark。这里有一个取舍问题要不要单独的“预约表”和“订单表”我最终选择的方案是两张合一——因为业务场景里预约行为天然伴随订单产生分开两张表在“预约未到店”等场景下会非常绕。如果你做的是带“仅预约保留、到店再支付”场景的高级版本分两张表更合适课程设计级别合一张完全够用。3.2 为什么要自己生成订单号而不是用数据库自增订单号是系统的门面也是答辩时容易出彩的设计点。数据库自增ID在内部可以但对外作为订单号有三个问题暴露日订单量安全、无法跨库扩展、不够好看体验。我用的生成规则是String orderNo H LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)) RandomUtil.randomNumbers(4);效果类似H202506182030158426含义是“H年月日时分秒4位随机数”。每天订单量不超过一万的场景这个方案完全不会重复。答辩时如果被问到并发下会不会撞号补一句“并且数据库对order_no加了唯一索引即使极端情况下撞了也会抛异常自动重试”就够了。3.3 订单状态字段的两个设计流派关于订单状态网上资料里有两种做法用int状态码或者用varchar状态名。我强烈推荐用int状态码加常量类定义public class OrderStatus { public static final Integer UNPAID 1; // 待支付 public static final Integer RESERVED 2; // 已预约 public static final Integer CHECKED_IN 3; // 已入住 public static final Integer CHECKED_OUT 4; // 已退房 public static final Integer CANCELED 5; // 已取消 }原因有两条。第一数据库int字段天然具备大小比较、索引优化上的优势第二后端代码中状态流转的校验逻辑用整数判断清晰直观比如“只有RESERVED和CHECKED_IN状态的订单才能走退房流程”。界面展示时再用前端遍历字典翻译成中文各层职责分明。3.4 日期冲突校验的SQL写法大部分模板都写错了判断一个房间在某段日期区间内是否已被预约是这个系统里最重要的查询之一。我见过大量模板用的是BETWEEN这种写法在“入住当天退房”这种边界场景下会算错。正确的冲突判断逻辑是只有当新订单的入住日期小于已有订单的退房日期、并且新订单的退房日期大于已有订单的入住日期时才算冲突。完整SQL如下SELECT COUNT(*) FROM reservation WHERE room_id #{roomId} AND order_status IN (2, 3) -- 已预约和已入住都算占房 AND check_in_date #{checkOutDate} AND check_out_date #{checkInDate}这个SQL查询结果大于0说明该房间在这个时间段被占用。为什么要和而不是和因为行业惯例是“中午12点退房、下午2点入住”同一个房间同一天允许先退再入。如果你的业务系统强调“当天只允许同一批客人”那再改成和也不迟关键是答辩时你能说清楚这个边界条件的取舍。4. 核心业务逻辑落地从预约锁房到退房清算的完整链路4.1 预约下单一次完整预订要处理哪些步骤一次“用户提交预约”请求后端Service层至少要顺序完成五件事校验用户登录状态、参数合法性入住日期不能早于今天、退房日期必须晚于入住日期。根据前端传入的房型ID查出一间当前满足条件的具体房间。这里有两种策略一是让用户选具体房间号二是只选房型、系统自动分配房间。真实酒店两种模式都有管理系统建议用“用户选房型、系统自动分配具体房间”前端展示更友好。执行上面那条日期冲突SQL确认该房间在目标时间段内可用。计算总价(退房日期 - 入住日期)的天数 × 房型单价生成订单号插入订单记录状态设为待支付。把房间状态从空闲改成已入住——不是这里不要改。第五步是个经典坑。有些同学在“预约成功”时就直接把房间状态改成已入住导致客人还没到店房间已经显示被占而且一旦订单取消状态回退逻辑会非常混乱。正确的做法是创建订单时只写订单表不动房间表真正办理入住时才把房间从空闲改为入住状态。4.2 并发锁房悲观锁和乐观锁怎么选回到前面说的那道必问题两个用户同时预约同一间房怎么保证不超卖这是功能从“写着能用”到“真正严谨”的分水岭。方案一悲观锁。核心是在查询房间时加FOR UPDATE把这一行数据锁住直到事务结束SELECT * FROM room WHERE id #{roomId} AND status 0 FOR UPDATE;该事务没提交前其他事务查询同一行会阻塞等待从而保证“查房-生成订单-扣库存”的原子性。缺点也很明显并发高时锁等待会拖慢性能但课设项目这个量级完全没压力。方案二乐观锁。在room表加一个version字段更新时带上版本号UPDATE room SET status 1, version version 1 WHERE id #{roomId} AND version #{oldVersion};这条UPDATE影响行数为1说明抢占成功影响行数为0说明version已被别人改过本次操作失败回滚事务并提示“该房间刚刚被预订请重新选择”。我个人实现时用的是乐观锁理由很实在实现简单、不用开事务包裹查询而且答辩时可以把“乐观锁与悲观锁的对比”当成一个加分知识点主动讲出来。当然如果只想快速稳妥、不想深入并发悲观锁的正确性上限更高不容易出bug。两种方案都没有问题选一个能讲清楚的就够了。4.3 入住、退房与房态联动办理入住接口接收orderIdService层做三件事校验订单状态必须是已预约把订单状态改为已入住把房间状态从0空闲改为1入住。同时写一条入住记录到check_record表记录操作人。办理退房接口做四件事校验订单状态必须是已入住计算实际消费这里可以做押金扣减逻辑订单状态改为已退房房间状态改为2打扫而不是直接改回空闲。房间里可能还有遗留物品、需要保洁整理直接改空闲会让下一个客人订到一间没打扫的房间。打扫完成由管理员手动改回0空闲这个环节也是业务完整性的体现。真实酒店还有一种“提前退房/延期退房”的场景课设阶段先把主流程跑通如果时间充裕再扩展提前退房要按实际天数重新计算金额并退款延期退房要重新校验房间后续可用性。每多处理一个边界答辩就多一个亮点。4.4 模拟支付与订单取消的时序设计真实项目对接微信/支付宝很复杂课设里做“模拟支付”完全够用。我的实现是用户点击“去支付”后弹出确认框点击确认后端直接把订单的pay_status改为1、order_status从待支付改为已预约。在Service层留一个pay(orderNo, payMethod)的接口参数里带上“微信/支付宝/现金”等支付方式字符串整个支付流程的时序就完整了将来接真实支付只要替换实现细节。订单取消的规则也要提前想清楚待支付状态随时可取消取消后订单变已取消即可房间状态本来就没动过无回调逻辑已预约状态取消如果已经锁定了具体房间则需要把房间状态从占用改回空闲——注意这里虽然房间状态没在预约时改过但日期冲突查询是实时计算的订单取消了后续再查冲突时就放行了所以核心处理还是订单状态流转没有什么额外LLM调用的复杂度。如果系统有“订单锁定不释放”的需求才需要考虑定时任务自动释放超时未支付订单课设阶段不做超时自动取消也没关系提一句“这个还能用定时任务优化”就够了。5. 测试、答辩与避坑那些教科书不会告诉你的交付细节5.1 一页纸自测清单项目完成到可演示的程度我建议按下面这个清单做自测每一项都在开发完自己点一遍编号功能模块测试步骤预期结果T01注册登录新用户注册→登录密码密文存库登录成功返回TokenT02房型展示客户登录查看房型列表图片价格描述正常展示T03预约下单选择房型日期区间订单生成状态为待支付T04日期冲突对同一房间提交重叠日期弹出“该房间此时间段已被预订”T05并发冲突开两个窗口同时提交同一房间同一日期只有一个成功另一个提示重选T06支付对待支付订单点支付状态变为已预约T07取消对待支付/已预约订单点取消状态变为已取消T08入住前台对已预约订单办理入住订单变已入住房间变入住T09退房前台对已入住订单办理退房订单变已退房房间变打扫T10打扫完成管理员改房态房间变空闲可再次预约每一个断言都提前写下来再动手比打开系统乱点实在得多。5.2 复现超卖Bug的压测方法没有条件上JMeter也可以在浏览器里手动复现开两个无痕窗口用两个账号同时登录选中同一间房同一个日期同时点击提交。如果两个订单都创建成功说明并发逻辑有漏洞如果只有一个成功另一个在日期冲突校验阶段就被拦下说明逻辑是通的。如果要更专业一点用JMeter开100个线程同时打订单接口然后去数据库里查同一房间同一日期区间下order_status IN (2,3)的订单数量如果大于1就是超卖直接看得到结果。我在实测中发现一个问题非常有代表性很多人把日期冲突校验放在Service层但在高并发下两个请求同时通过了校验然后在插入订单表时才出现冲突。也就是说光有校验SQL不够还必须配合乐观锁或悲观锁才能彻底封死超卖。这也是为什么一定要有第4.2节那样的并发设计。5.3 答辩高频追问清单与应答要点根据我实际答辩和被学弟学妹请教的经验整理一份高频问题清单“订单号为什么不用自增ID”答自增ID暴露业务量且不方便迁移扩展自定义订单号包含时间信息且加唯一索引兜底。“订单状态设计成数字还是字符串”答数字加常量类性能好、判断清晰用字符串直观但维护性差。“并发下如何防止一房多订”答乐观锁/悲观锁原理各讲一遍然后说自己项目里采取的方案。“预约成功时为什么不变房态”答变房态是“入住”动作触发的预约成功只锁定订单客人没到店前房间不应被标记为入住状态。“如果客人超过退房时间不退房怎么办”答预留“续住”按钮前台手动操作完整方案可以加逾时自动计算加收费用功能。“数据库为什么这样设计有没有冗余”答订单表里冗余了room_type_id和房价快照是因为房型价格调整后历史订单仍要显示下单时的价格这是反范式设计中的合理冗余。答辩前把这几题过一遍很大程度上就能避免被问住。5.4 多花两小时就能加分的细节系统做完后如果时间允许建议补这几个低投入高回报的细节第一全局异常处理。用RestControllerAdvice统一捕获业务异常和未知异常返回统一格式的JSON。很多同学的项目一报错就白屏或堆栈直接暴露在浏览器上有了全局异常处理观感立刻不一样。第二操作日志。用Spring AOP切面记录关键操作比如“管理员对订单XXX执行了退房操作”。答辩现场演示此功能比口头说自己做了多少模块更有说服力。第三登录密码BCrypt加密。用Spring Security里的BCryptPasswordEncoder不要用MD5。答辩时如果老师注意到安全细节这一个点就能顶一段长篇大论。第四给前端页面加上订单状态的颜色标识待支付橙色、已预约蓝色、已入住绿色、已退房灰色、已取消红色。酒店前台对颜色的敏感度远远高于文字这个小优化成本低收益高。说实话M238这个课题做下来最大的体会是管理系统类型项目的分水岭不在CRUD的熟练度而在业务状态机的完整度。把订单状态梳理清楚把并发场景考虑到位把房态联动做闭环就已经超越了绝大多数网上的成品模板也足够撑起一篇拿得出手的课程报告或毕业论文。最后再分享一个小建议开写代码之前先把订单状态机画在纸上并贴到显示器旁边后面写每一段逻辑都对照着它能少走太多弯路。