1. 项目概述与选题拆解1.1 为什么酒店预订系统是毕设的“常青树”每年到了毕业季计算机专业的同学们就开始纠结同一个问题毕设到底做什么题目选题太偏怕做不完选题太简单怕答辩过不了选题太热门又怕跟别人撞车。在Java方向里“酒店预订系统”属于那种永远不会过时的经典题目而把SSM框架作为底层支撑则是一个既稳妥又能体现功底的组合。先说清楚这个系统是什么。用一句话概括它是一个以Spring SpringMVC MyBatis为技术骨架围绕“客人订房—支付—入住—退房—订单管理—后台运营”这条完整链路构建的酒店预订管理平台。它不是一个只做增删改查的demo而是覆盖了前台用户操作和后台管理员运营的双端系统也就是标题里强调的“全流程”。为什么这类题目在毕设里反复出现原因有三第一酒店预订的业务逻辑足够清晰房间类型、房价、订单状态、入住日期这些概念大家都熟悉需求沟通成本低第二业务链条足够长从前台注册登录到后台统计报表能展示的知识点覆盖面广从基础的CRUD到事务处理、并发控制都有发挥空间第三它天然带有“可用产品”的形态做完之后演示效果好答辩时不愁没东西讲。选SSM而不是Spring Boot也是很多同学纠结的问题。我的看法是如果你的学校教材还在讲SSM或者导师明确指定用SSM那就踏踏实实用SSM。SSM的核心思想——控制层、业务层、持久层三层分离对象由Spring容器管理SQL由MyBatis掌控——这些底子打好了后面转Spring Boot只需要几天时间。而且SSM是手动配置一切的反而能让你把框架原理看清楚答辩时老师问到“SpringMVC的DispatcherServlet是怎么工作的”“MyBatis的Mapper代理是怎么回事”你能讲得比用Spring Boot的同学细得多。1.2 “全流程管理系统”到底在说什么很多同学做的“酒店预订系统”本质上是个“房间列表展示器”页面上放几张酒店图片点进去看到房型和价格然后一个“预订”按钮——没了。这种系统放在两年前还能混过去现在评委老师一眼就能看出来你只是套了个模板。标题里最值钱的词是“全流程”三个字。什么是酒店预订的全流程我整理一下客人在前台浏览酒店信息、房型、价格、剩余房间数注册/登录后选定入住日期和离店日期提交预订订单订单生成后支付毕设通常是模拟支付不接真实支付渠道管理员在后端确认订单或系统自动确认客人到店办理入住状态变为“已入住”退房结算状态变为“已完成”客人可以取消订单不同节点取消的退款规则不同后台对订单数据进行统计查看入住率、营收、房态分布这才叫全流程。一个完整的系统必须把这些环节全部串起来任何一个状态断层都会在实际使用中露馅。所以你在设计数据库时订单表的状态字段绝不是简单的0和1而是一套有明确流转规则的状态机。另外还有一层容易被忽略的“全流程”——双端。前台给客人用后台给管理员用。后台至少要覆盖房型管理增删改查、设置房价、设置库存、房间管理具体到每个房间号、订单管理查看、审核、取消、标记入住/退房、用户管理、数据统计。前台和后台共用一个Service层但Controller和页面完全分开这也是体现分层设计的好机会。2. 技术架构与工程结构设计2.1 SSM框架的核心链路与各个成员的职责先帮还没有完整做过SSM项目的同学把框架链路捋一遍已经会的可以直接跳到2.2。一次请求从浏览器发出到达服务器后先被SpringMVC的前端控制器DispatcherServlet拦下来。它做的事情用生活类比来说非常像酒店大堂的礼宾员你走进酒店发送请求礼宾员一看你要办入住就把你带到前台要退房就把你带到收银台。它不做业务只做分发。分发到具体某个Controller后Controller只干一件事——接收参数调用Service把结果封装成ModelAndView或JSON返回。真正的业务逻辑在Service层比如“下单”这个动作里查房型库存够不够、判断入住日期合不合法、计算总价、扣除库存、生成订单记录这些步骤应该全部在Service层的一个方法里完成并且包在同一个事务中。至于和数据库打交道则交给MyBatis——你只需要定义Mapper接口和对应的XML文件MyBatis会在运行时自动生成实现类把SQL执行结果映射成Java对象。Spring在这里扮演的用类比说就是整个酒店的“人力资源部”Controller、Service、Mapper这些对象由Spring的IoC容器负责创建和管理不需要你new。Service依赖MapperController依赖Service这种依赖关系由Spring的依赖注入完成你在类上标注Autowired或构造器注入即可。AOP则负责补偿这些对象的行为——最典型的就是声明式事务在Service方法上加TransactionalSpring会在这个方法执行前开启事务执行成功后提交抛出异常则回滚。2.2 Maven工程的包结构怎么划分不打架工程结构直接反映你有没有“工程化”思维。很多毕设之所以看着凌乱就是因为所有Java文件堆在一个包里Controller里写了SQLEntity里混着视图对象。我推荐的结构是这样按包名分层Maven目录结构就不赘述了com.hotel.book ├── controller // 控制层接收请求返回视图或JSON │ ├── admin // 后台管理的Controller单独放 │ └── front // 前台用户的Controller单独放 ├── service // 业务接口 ├── service.impl // 业务实现类 ├── mapper // MyBatis Mapper接口 ├── entity // 数据库实体类POPersistent Object ├── vo // 视图对象给前端页面使用的聚合类 ├── dto // 数据传输对象接收前端提交的数据 ├── common // 通用工具常量类、统一返回结果、分页对象、异常处理 └── config // 配置类拦截器、Web配置、事务配置这样划分有几个实战层面的好处。第一entity和vo分开是很多同学容易忽略的细节。Entity里的字段和数据库表字段一一对应但页面上要展示的数据往往需要几个表的数据拼在一起。你如果直接用Entity去凑页面需求会出现“这个字段数据库里根本没有但你愣给它加上了”的丑态。第二controller里分admin和front是为了明确权限边界——后台接口不能让普通用户访问分开以后写拦截器做URL前缀匹配就很简单。Maven的依赖管理也值得说一句。SSM项目常见的依赖有spring-webmvc、spring-jdbc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databindJSON序列化、jstlJSP标签库、servlet-api。注意版本兼容如果你用Spring 5.xJDK至少8如果用MyBatis 3.5.x对应mybatis-spring最好用2.x。很多同学在这一步踩坑直接在网上下个“SSM整合完全版”里面Spring是3.x的用到Java 8的Lambda语法直接编译报错。2.3 数据库设计是整个项目的“地基”现在聊正经的数据库设计。酒店预订系统的数据模型核心表至少七张。我直接列出表名和关键字段并提供设计理由。用户表t_userid、username、passwordmd5加密或加盐后存储、real_name、phone、id_card、create_time。身份证号不是必须的但毕设场景里预留这个字段可以在入住登记时体现“全流程”的严谨性。酒店表t_hotelid、hotel_name、address、star_level、description、cover_image。这是一个面向多酒店的扩展设计哪怕你只做一个酒店的数据也建议把这张表建出来。答辩老师看到你有多酒店的概念至少说明你不是一个酒店一张表地写死。房型表t_room_typeid、hotel_id、type_name、price、area、bed_type、max_people、stock、image。注意区分“房型”和“房间”房型是抽象概念比如“大床房”房间是具体物理节点比如“大床房302室”。很多毕设把这两个概念混在一起直接导致库存逻辑没法做。房间表t_roomid、hotel_id、room_type_id、room_number、status1空闲、2已入住、3维修中。房型和房间是一对多的关系。订单表t_orderid、order_no订单编号全局唯一、user_id、hotel_id、room_type_id、check_in_date、check_out_date、total_price、status订单状态、create_time、pay_time、check_in_time、check_out_time。这张表是整个系统的核心状态设计我们单独展开。订单状态流转表t_order_status_logid、order_id、old_status、new_status、operator_user_id、remark、create_time。这张表记录订单状态变化日志。很多同学不做这张表我觉得有点可惜——答辩时你拿出这张表说“我做了状态审计任何一次状态变更都有迹可循”评委眼里的你的水平就上了一个档次。评价表t_commentid、order_id、user_id、hotel_id、score、content、create_time。评价是业务闭环的最后一环客人退房后可以评价后台可以看到评分汇总。除了这些核心表如果有时间还可以加收藏表、优惠券表、轮播图表、管理员表。我建议按“核心表优先、扩展表加分”的思路排优先级。先把上面七张表的数据关系理顺再谈扩展。3. 核心业务功能实现从需求到落地3.1 订单状态机把“全流程”落成代码所有业务逻辑中最考验设计功底的就是订单状态。很多项目死在这个环节——订单状态字段设计成一两个固定值流程完全走不通。我在这里给出我常用的状态定义状态值含义说明0待支付下单成功但未支付占用库存1已支付待确认已支付等待后台确认也有系统直接自动确认的毕设建议手动确认可以演示后台操作2已确认未入住后台确认成功等待客人到店3已入住客人办理入住4已退房/已完成客人退房订单完结5已取消客人在支付前或支付后取消订单状态之间的合法流转必须写清楚并且用代码强制校验。我见过有些同学在Service里直接order.setStatus(4)完全不检查之前是什么状态结果出现“待支付直接变已入住”的闹剧。正确做法是定义一个状态转换校验工具public class OrderStatusValidator { // key: 当前状态, value: 允许流转的目标状态集合 private static final MapInteger, SetInteger ALLOWED_TRANSITIONS new HashMap(); static { ALLOWED_TRANSITIONS.put(0, new HashSet(Arrays.asList(1, 5))); ALLOWED_TRANSITIONS.put(1, new HashSet(Arrays.asList(2, 5))); ALLOWED_TRANSITIONS.put(2, new HashSet(Arrays.asList(3, 5))); ALLOWED_TRANSITIONS.put(3, new HashSet(Arrays.asList(4))); ALLOWED_TRANSITIONS.put(4, Collections.emptySet()); ALLOWED_TRANSITIONS.put(5, Collections.emptySet()); } public static boolean canTransition(Integer from, Integer to) { return ALLOWED_TRANSITIONS.getOrDefault(from, Collections.emptySet()).contains(to); } }然后在Service的每个状态变更方法里先做校验再执行更新。所有状态变更同时往t_order_status_log里写一条记录。这套逻辑写完之后你会发现整个订单流程的代码异常清晰——每个方法只负责一种状态流转前端的“取消订单”按钮、后台“确认订单”按钮、“办理入住”按钮调用的就是对应的方法。3.2 日期冲突判断与库存预占防止“超卖”的关键酒店预订和普通电商下单有个明显的区别库存不是“总量”而是“在指定日期区间内可预订的量”。你库存里写着有10间大床房不代表任意日期都有10间可订——可能某三天已经订出去8间了。所以要判断“某个房间类型在某段日期内是否还有余房”只看表里的stocks字段是不对的。正确的判断逻辑是统计在该日期区间内已预订且状态未取消、未完成的订单占用了多少库存再用总库存减去占用数得到剩余可订数。这里我必须强调一个很多毕设都会掉进去的坑日期区间的重叠判断。很多人写订单查重用等价判断new_check_in old_check_in AND new_check_out old_check_out结果漏掉了一大堆情况。两段日期可能有交集的情况一共有四种新区间完全包含旧区间新区间完全被旧区间包含新区间只有前半部分和旧区间重叠新区间只有后半部分和旧区间重叠一个不出错的判断就是“区间互不重叠”的反面——即新区间的开始小于旧区间的结束且新区间的结束大于旧区间的开始// 区间有交集的充分必要条件 if (newCheckIn.compareTo(oldCheckOut) 0 newCheckOut.compareTo(oldCheckIn) 0) { // 重叠 }对应到SQL查重可以写成这样SELECT COUNT(*) FROM t_order WHERE room_type_id #{roomTypeId} AND status NOT IN (5) AND #{newCheckIn} check_out_date AND #{newCheckOut} check_in_date这一条SQL能覆盖所有重叠情况。我当时第一次写这个查询的时候也没想明白后来画了个时间轴才豁然开朗。这是酒店预订系统最容易写错的地方写错了用户在页面上看到的“余房充足”就是假象答辩演示时一操作立刻翻车。关于库存扣减还需要说一个并发问题。两个客人同时订同一房型同一日期程序先查库存发现剩1间然后A下单扣减B也下单扣减最后可能两个订单都成功但实际只有1间房。在SSM环境下最简单的方案就是给订单表对应的库存扣减加锁。可以用SELECT ... FOR UPDATE锁住房型记录悲观锁然后在代码里判断库存、扣减。虽然并发量不大时这个方案偏重但对于毕设完全够用而且比乐观锁更好理解答辩时也容易讲清楚。3.3 价格计算别在细节上丢分价格计算看似简单却是很多系统的隐藏扣分项。两个细节很多人会忽略。第一个是跨天价格。客人订的是8月10日入住、8月12日离店一共住几晚答案是2晚。check_out_date - check_in_date以天为单位计算。如果你直接按两个日期相减需要搞清楚是返回2还是1。我建议把入住离店设计成“小时粒度”存储展示时只显示日期这个不容易出错。第二个是节假日调价。做了一个简单的“周末或节假日价上浮”可以极大丰富系统的业务逻辑。在房型表里加上weekend_price字段或者单独建一张price_calendar表按特定日期设置特殊价格。计算总价时遍历入住到离店的每一天判断当天是否特殊日期累加计算public BigDecimal calcTotalPrice(OrderDTO dto, RoomType roomType) { BigDecimal total BigDecimal.ZERO; LocalDate start dto.getCheckInDate(); LocalDate end dto.getCheckOutDate(); for (LocalDate date start; date.isBefore(end); date date.plusDays(1)) { BigDecimal dayPrice priceCalendarService.getPriceForDate(roomType.getId(), date); if (dayPrice null) { dayPrice isWeekend(date) ? roomType.getWeekendPrice() : roomType.getPrice(); } total total.add(dayPrice); } return total; }注意这里用的是BigDecimal而不是double——金额计算用浮点数精度出问题只是迟早的事。这个点也在答辩时可以主动提说明你关注工程实践中的细节问题。3.4 登录鉴权与拦截器保护后台接口全流程系统必然有权限区分。前台用户可以浏览、下单、支付、取消、评论后台管理员可以管理房型、房间、订单、用户。如果你不做权限控制管理员接口直接裸奔在公网谁都能访问——这在答辩时可能被当场问住。基于SSM的拦截器方案如下在spring-mvc.xml里配置拦截器用URL前缀区分权限。比如/admin/开头必须是管理员登录状态/user/开头必须是普通用户登录状态mvc:interceptors mvc:interceptor mvc:mapping path/admin/**/ bean classcom.hotel.book.interceptor.AdminInterceptor/ /mvc:interceptor mvc:interceptor mvc:mapping path/user/**/ bean classcom.hotel.book.interceptor.UserInterceptor/ /mvc:interceptor /mvc:interceptors用户登录后在session里写入用户对象拦截器里检查session是否存在且角色匹配不匹配就重定向到登录页。密码存储至少要用MD5加盐不要明文存储——这是安全底线。4. 常见Bug与排查技巧实录4.1 时间参数传递的连环坑我在做这个项目的过程中遇到的第一个大坑就是时间传递。前端的日期选择器发出的是“2025-06-01”这种字符串后端接收时用Date字段直接绑定结果总是报类型转换错误。解决办法是在spring-mvc.xml里配置全局日期转换器把字符串转成Date。自定义一个ConverterString, Date然后在ConversionServiceFactoryBean里注册即可。这里提醒一句日期格式一定要统一前端传参、后端接收、数据库存储全部统一为yyyy-MM-dd避免时区、格式混乱。另一个容易被忽略的坑是LocalDate和java.util.Date的混用。SSM项目里MyBatis对LocalDate的支持已经很完善了但有些同学的库连接驱动或MyBatis版本较旧映射时可能报错所以要么全部用Date要么全部用LocalDate别一半一半。4.2 事务失效与连接泄漏用SSM最经典的Bug一定是“我加了Transactional为什么事务没生效”。三个排查方向Transactional加在了接口实现类的某个方法上但方法被同类内部方法调用——Spring的代理机制会让这种内部调用直接绕过代理事务完全不生效。事务管理器的Bean没有在Spring容器里正确配置DataSourceTransactionManager没有注入DataSource。异常被吞掉了——方法内部try...catch把异常捕获后没抛出Spring感知不到异常事务不会回滚。正确的做法是在Service实现类的方法上不要捕获异常或捕获后重新抛出为RuntimeException让事务管理器能够感知。连接泄漏是另一个隐蔽问题。很多人用Druid连接池但SQL写错后不断抛异常连接没有归还连接池被打满整个系统假死。排查时看Druid监控页面的活跃连接数就能定位。平时写代码时注意所有Connection相关操作必须放在try-with-resources或finally里关闭MyBatis本身会管理连接释放但如果你手写了JDBC模板代码就要格外小心。4.3 分页查询性能与SQL调优经验后台订单列表、前台房间列表分页是必须的功能。很多同学用LIMIT 大数, 小数翻页越翻越慢。这是因为MySQL需要扫描并丢弃前面的大量行。简单优化方案不要跳页太深或者用“延迟关联”的方式。比如查第10000条开始的20条数据时先用where条件查出起始id再基于id过滤SELECT * FROM t_order WHERE id (上次查到的最后一条id) AND user_id #{userId} ORDER BY id ASC LIMIT 20这种“键集分页”方案对订单这种id有序的数据非常友好。还有order_no既然是唯一的记得加唯一索引不然每次全局校验都走全表扫描。在MyBatis的配置上resultMap比resultType更灵活尤其涉及多表关联查询时使用resultMap可以清晰地定义字段映射和关联对象关系。但要注意嵌套查询要避免N1问题主查询查出订单列表后再逐条去查关联的酒店、用户会导致大量SQL查询。解决方案是使用association和collection进行嵌套结果映射一条join SQL拉回来所有数据。4.4 “图片上传”功能怎么做才不冗杂毕设系统里一定会有房型图片、酒店图片。如果非要自己写文件上传找一个简单的方案用Commons FileUpload或者Spring自带的MultipartFile接收文件然后写到服务器本地的一个目录再把路径存到数据库的image字段。需要注意设置文件大小上限否则用户上传超大图片直接拖垮磁盘限制文件格式只允许jpg、png、webp文件名用UUID重新生成不要用用户原始文件名——既有中文乱码问题又容易路径穿越不要为了一个毕设去搭OSS、对象存储之类的全套服务本地存储足以胜任。关键是存储路径要统一管理别在Controller里写死硬编码路径放在配置文件中。5. 答辩亮点与扩展思路5.1 怎么把“普通项目”讲成“有点东西”我作为过来人见过太多学生在答辩时只会演示页面讲不清内部逻辑。这里提供两个提升答辩档次的思路。第一个把数据可视化统计做出来。后台加一个Dashboard页用ECharts展示近7天订单量、近30天营收、房型入住率Top5、每日新增用户量。这个功能本质是写SQL聚合查询GROUP BY DAY(create_time)、SUM(total_price)、COUNT(*)前端用一个图表库画出来。数据不难查但视觉冲击力强评委一眼觉得这个项目“完整”。第二个准备1-2个技术亮点故事。比如你在做并发库存扣减时发现了超卖问题然后用了SELECT ... FOR UPDATE悲观锁解决或者你在做日期查重时发现简单的区间判断漏掉了部分重合的情况于是推导出重叠判断公式。把这些真实经历整理成150字的小故事答辩讲出来比背“我用了什么框架”有说服力得多。5.2 可扩展方向从毕设到项目的距离如果时间富余有些功能可以让项目从“毕设水平”逼近“商用雏形”定时取消超时未支付订单用Quartz定时任务扫描超过15分钟未支付的订单自动取消并释放库存短信/邮件通知下单成功、支付成功、入住提醒接免费短信平台或邮件服务优惠券系统满减券、折扣券订单金额计算时叠加优惠数据看板运营数据大屏按酒店、日期维度下钻我个人的体会是选择一个扩展方向做透大于所有方向均匀撒网。哪怕是加一个“订单自动取消”功能只要把这背后的定时任务、状态流转、库存回补讲透就足以让答辩老师看出你的工程能力。做毕设与其堆十个半成品功能不如把一个核心功能做得没有一丝疏漏。最后说一句在实操中得出的经验这个项目的代码量不大真正花时间的往往是各种边界情况和bug排查。建议每天备份代码每完成一个功能就提交一次Git。遇到问题先用日志定位不要凭感觉乱改。酒店预订这条业务链路并不复杂但每一步都踩实了它就是一个拿得出手的完整系统。