SSM框架苹果酒店住房管理系统：从CRUD到业务闭环的Java毕设实战指南-平芜编程栈

1. 项目定位与需求梳理：为什么苹果酒店住房管理适合当毕设

每年到毕设季，Java方向的学生问得最多的就是“有没有什么题目既不太难，又能把SSM框架用上，还能写得清楚论文”。苹果酒店住房管理系统这类题目，就是典型的“看着普通、实际上很能打”的选择。它不是那种花里胡哨的商城或社交平台，但酒店住房管理覆盖面非常广——客房信息维护、预订登记、入住退房、账单结算、房态统计，这些都是传统CRUD的最佳训练场，同时也是面试时能拿得出手的业务场景。

先说清楚这个系统的目标：它面向的是中小型酒店的前台和管理人员，核心诉求是把“谁住了哪间房、住多久、收多少钱”这件事管明白。和淘宝那种高并发系统完全不同，酒店住房管理系统的并发量很低，一天几百笔订单就算多的，它真正考验的是业务逻辑的完整性——房态怎么流转、预订和入住怎么衔接、退房时账单怎么算、数据怎么统计。这种“小但全”的特点，恰恰是毕设最需要的。

从选题价值来看，这个题目有四个明显优势：

第一，业务场景贴近现实。酒店是所有人都接触过的行业，需求容易理解，不需要额外花时间去学习领域知识。评审老师一看需求分析就知道你在说什么，这在答辩时能省掉大量解释成本。

第二，功能模块边界清晰。客房管理、客户管理、预订管理、入住管理、结算管理，每个模块都有明确的输入输出，适合拆分给不同角色使用，也适合在论文里按模块逐个写。

第三，技术栈经典不偏门。SSM（Spring + SpringMVC + MyBatis）虽然已经是老技术了，但绝大多数高校的Java课程还是以它为主，很多学校甚至明确要求用SSM框架做毕设。你选这个题目，至少不用在“用什么技术”这件事上和导师反复拉扯。

第四，论文素材天然充足。系统涉及权限控制、状态转换、时间冲突判断、统计报表，这些点每个都能在论文里写出一小节，凑够字数根本不是问题，关键是有实际内容支撑，不会太空洞。

我个人见过太多论文写得干巴巴的情况，问题不在于学生不会写，而在于系统功能太简单，没有什么可以展开的业务逻辑。苹果酒店住房管理系统恰好避开了这个坑，这一点我们在后文会详细拆解。

2. 技术栈选型与架构设计：SSM组合为什么至今仍是毕设主力

2.1 SSM框架的分工逻辑

SSM指的是Spring、SpringMVC、MyBatis三个框架的组合。很多新手一开始搞不清楚这三个东西到底各自干什么，这里用最直白的话解释一遍：

Spring是整个系统的“大管家”，负责管理对象的创建和依赖关系。比如你写了一个UserService，它里面要用UserMapper，如果没有Spring，你得自己在代码里new一个出来，有了Spring，你只需要标注一下，Spring就自动把UserMapper注入进去。此外Spring还管事务——酒店系统的订单操作涉及多张表的修改，万一中间出错不能留下一半成功一半失败的数据，Spring的事务管理就是干这个的。

SpringMVC负责“接客”，它处理浏览器发过来的HTTP请求。前端页面提交一个表单，SpringMVC根据URL映射找到对应的Controller方法，把表单参数封装成Java对象，然后调用Service层处理业务，最后把结果渲染成页面或JSON返回给浏览器。一句话总结：SpringMVC管的是Web层的请求分发和参数传递。

MyBatis负责“跑腿”，它封装了JDBC的重复代码，让你不用再写一堆getConnection、PreparedStatement、ResultSet这样的样板代码。你只需要定义Mapper接口，在XML或注解里写SQL语句，MyBatis就会自动执行SQL并把结果集映射成Java对象。

这三个框架各管一段，正好覆盖了Web应用的完整链路：SpringMVC接收请求，Spring管理业务组件和事务，MyBatis操作数据库。这就是SSM组合的基本逻辑。

2.2 为什么2026年了还选SSM

有同学可能会问：现在Spring Boot都出到3.x了，微服务、云原生这些概念满天飞，为什么毕设还要用SSM？

这里得说句实在话：毕设的根本目的是把你大学四年学的东西综合运用一次，而不是让你追技术热点。SSM是Java Web领域最经典的一套组合，市面上大量中小型项目的核心代码仍然是基于SSM演进的，你把SSM吃透了，再去看Spring Boot就非常轻松——Spring Boot本质上只是把Spring的配置简化了，底层和核心思想完全一致。

更重要的是，用SSM做毕设，你能在代码里体现出的“技术含量”反而更多。Spring Boot一堆自动配置，很多环节你自己根本没写过；SSM则要求你手动配置数据源、手动声明事务、手动处理MyBatis映射，这些手动操作虽然繁琐，但恰好能体现出你对框架的理解程度。答辩时老师问你“SpringMVC的处理流程是怎样的”“MyBatis的一级缓存二级缓存区别是什么”，你如果亲手配置过、调试过，回答起来底气和完全依赖Spring Boot自动配置的学生完全不同。

当然，这不是说用Spring Boot就不行。如果你导师对技术选型没意见，用Spring Boot做同样功能的系统会更顺手，开发速度也更快。但如果学校有指定框架要求，或者你更看重“能讲清楚框架原理”，SSM依然是稳妥之选。

2.3 三层架构与包结构设计

架构设计上，主流的做法是严格分层：Controller层（控制层）、Service层（业务层）、Mapper层（数据访问层），加上实体类包（entity/pojo）、工具类包（util）、公共配置包（config）。

这里有一个实操建议，也是我在指导毕设时反复强调的：包命名一定要严格规范，因为论文里的系统架构图、模块设计图都要和代码包结构对应得上。建议的包结构如下：

com.apple.hotel ├── controller # 控制层，接收请求 │ ├── AdminController.java │ ├── RoomController.java │ ├── ReservationController.java │ ├── CheckInController.java │ └── UserController.java ├── service # 业务层，处理核心逻辑 │ ├── RoomService.java │ ├── ReservationService.java │ ├── CheckInService.java │ └── impl # 实现类 │ ├── RoomServiceImpl.java │ └── ... ├── mapper # 数据访问层，MyBatis接口 │ ├── RoomMapper.java │ └── ... ├── entity # 实体类 │ ├── Room.java │ ├── Reservation.java │ ├── CheckInRecord.java │ └── User.java ├── vo # 视图对象，用于页面展示组合数据 │ ├── RoomStatusVO.java │ └── CheckInDetailVO.java ├── util # 工具类 │ └── DateUtils.java ├── interceptor # 拦截器 │ └── LoginInterceptor.java ├── exception # 自定义异常 │ └── BizException.java └── config # 配置（Spring配置、SpringMVC配置、MyBatis配置）

Controller层只做参数接收和结果返回，不写业务逻辑；Service层处理核心业务并抛出业务异常；Mapper层只做SQL操作。这样分层的好处有三点：一是职责单一，哪一层出了bug能快速定位；二是复用性好，比如导出Excel报表时，不需要走Controller，直接复用Service层的方法；三是论文好写，系统设计章节按层逐一介绍即可，结构天然清晰。

3. 数据库设计与核心业务逻辑：一张表一张表拆给你看

3.1 核心表结构规划

数据库是整个酒店系统的地基，表设计得不好，后面写代码会各种别扭。我见过不少学生一上来就建十几张表，结果发现很多表根本用不上。实际上，苹果酒店住房管理系统的核心表控制在七八张以内最合适。

第一张是管理员/用户表（sys_user），字段包括用户ID、用户名、密码、真实姓名、角色（管理员/前台/经理）、联系电话、创建时间。这里有一个容易被忽略的细节：密码存储不要用明文，建议至少用MD5加盐的方式加密。虽然酒店系统的安全等级要求不高，但论文里如果有人提出“密码明文存储不安全”，这是一个能加分的亮点。用Spring自带的DigestUtils工具类就可以轻松实现MD5加密，代码量也不大。

第二张是客房表（room），字段包括房间ID、房间号、楼层、房型（标准间/大床房/套房等）、床位数、门市价格、房间状态（空闲/已预订/已入住/打扫中）、房间描述。房间号需要加唯一约束，因为同一个酒店不可能有两个房号相同的房间。状态字段索引一定要加上，因为页面里最频繁的查询就是按状态查房间。

第三张是预订表（reservation），字段包括预订ID、客户姓名、客户手机号、房间ID、预计入住日期、预计退房日期、预订状态（待确认/已确认/已取消/已完成）、预订时间、备注。预订表是业务量最大的表，建议定期清理历史数据，或者在查询时强制加入日期范围条件，否则数据量上来之后索引性能会很明显地下降。

第四张是入住记录表（check_in_record），也可以叫订单表，字段包括入住记录ID、客户姓名、手机号、房间ID、实际入住时间、预计退房时间、实际退房时间、入住人数、押金、订单状态（在住/已退房/已取消）、订单总金额。入住记录表是赚钱的核心表，结算金额以这张表为准。

第五张是消费/账单表（bill），字段包括账单ID、订单ID、消费项目（房费/押金/其他消费）、金额、消费时间、操作人。这张表主要用来支撑退房时的结算明细展示，让客户看到钱是怎么花的。对于毕设系统来说，虽然不复杂，但放在这里能显著提升业务闭环的完整性。

除了以上五张核心表，还可以增加客房类型表（room_type）来做数据字典式的管理，以及操作日志表（sys_log）来记录关键操作。操作日志表在我的经验里对论文“系统测试”和“系统维护”两章非常有用，可以展示系统在安全性方面的考虑，毕竟酒店管理涉及资金数据，操作留痕是合理的业务需求。

3.2 表关联关系与ER图设计思路

表与表之间的关联关系要清晰，体现在数据库层面就是外键或者逻辑关联字段。我的建议是：物理外键能不加就不加，通过逻辑关联（业务字段）维护关系即可。理由很简单——外键会影响插入和删除性能，而且很多开发者实际开发时都不太喜欢外键约束带来的开发限制。你要在论文中画ER图，用逻辑关联展示的实体关系依然清晰，不会减分。

关系设计如下：

用户表与操作没有直接外键，操作日志里存操作人ID，逻辑关联即可。
客房表与客房类型表是“多对一”关系，一个客房类型对应多间客房，客房表存储类型ID做逻辑关联。
预订表与客房表是“多对一”关系，一条预订记录对应一间客房；与客户信息没有单独建客户表，而是冗余存客户姓名和手机号在预订表上。这是为了减少表数量，酒店行业客户信息本身很轻，没有会员体系时不需要单独建表。
入住记录表与客房表是“多对一”关系，一条入住记录对应一间客房。
账单表与入住记录表是“多对一”关系，一条入住记录可以产生多条账单项。

如果导师要求必须体现“客户”这个实体，你可以把客户信息抽成一张独立的customer表。但我的经验是，对于毕设系统，客户表的价值不大，反而增加复杂度。遇到这种情况，建议把预订表里的“客户姓名/手机号”视为历史快照字段，在论文中解释为“简化设计，因为酒店行业多数顾客属于一次性消费，已有信息足够完成业务”，一般都能通过。

3.3 房态流转与时间冲突：整个系统最核心的业务难点

酒店住房管理系统的业务难点集中在一个地方：房间状态如何随着预订、入住、退房、打扫等操作正确流转，以及预订时如何处理时间冲突。

先说状态流转。房间的主要状态包括：空闲（available）、已预订（reserved）、已入住（occupied）、打扫中（cleaning）、维护中（maintenance，可选）。状态机流转规则如下：

空闲 → 已预订：前台为客人办理预订且支付定金（或不用定金），此时房间被锁定。
空闲 → 已入住：客人没有预订直接到店入住（散客开房）。
已预订 → 已入住：预订客人到店办理入住。
已入住 → 空闲：客人退房后房间直接释放为空闲，也可以先进入打扫中再变为空闲。
已入住 → 打扫中：客人退房，清洁工打扫。
打扫中 → 空闲：打扫完成，房间可以继续售卖。
已预订 → 已取消：预订取消，房间释放。

这个流转规则要在Service层用一个独立的方法封装，例如changeRoomStatus(Integer roomId, Integer targetStatus)，不要在每个Controller里各自改状态，否则很容易出现“一个房间被改到不知名状态”的bug。我在实际帮学生调试时遇到过好几次：代码里有的地方把房间状态改成3，有的地方改成4，但数据库里状态枚举值根本没有对齐，导致页面显示一片混乱。

再说时间冲突，这是最有含金量的业务逻辑。预订或入住时，必须判断“这个房间在客人预订的日期范围内是否已经被预订或入住了”。用SQL可以这么实现：

SELECT COUNT(*) FROM reservation WHERE room_id = #{roomId} AND status IN ('待确认', '已确认') -- 已取消的不用管 AND #{newCheckIn} < expected_checkout -- 新入住日期 < 已有预订的退房日期 AND #{newCheckOut} > expected_checkin -- 新退房日期 > 已有预订的入住日期

评判两条预订是否时间重叠，核心逻辑是：新预订的开始日期小于已存在预订的结束日期，且新预订的结束日期大于已存在预订的开始日期。这是区间重叠判断的标准公式，建议在论文里把这个公式明确写出来。同理，入住记录也要做同样的检查，可以把这两段判断合并存储在一个公共方法中。

这个逻辑对不少学生来说第一眼看上去反直觉——为什么不直接判断两个日期区间是否互相包含？经过几个案例测试你就会发现，这种反向判断（不大于、不小于）才是覆盖各种重叠情况的通用解法。一个很容易犯的错是直接比较newCheckIn是否在已有区间内，这样会漏掉新预订区间完全包含旧区间的情况。

3.4 订单金额计算与结算逻辑

结算逻辑是另一个需要讲清楚的点。住房账单通常由两部分组成：房费和其他消费（如餐饮、洗衣、迷你吧）。房费的计算公式需要明确写出：

房费 = 房间门市价 × 入住天数

但入住天数计算有讲究。酒店行业通用惯例是“下午两点前退房算一天，超过下午两点到下午六点算半天，超过下午六点算全天”。毕设系统可以简化处理，但至少要区分正常退房和延时退房。我的建议实现是：

同一天入住和退房的，按1天计算，但页面要提示“入住日期和退房日期不能相同或退房日期早于入住日期”。
正常退房：按实际入住夜数计算，即退房日期减去入住日期的天数差。
延时退房：退房时间（时间戳）如果超过下午14:00，额外加收半天房费；超过18:00，加收一天房费。

这个规则在论文里可以写一节“计费规则设计”，非常容易凑内容而且显得考虑周全。在实际代码中，可以封装一个PriceCalculator工具类，里面写计算逻辑并配单元测试。如果答辩时老师现场问“你是怎么测试计费逻辑的”，你直接展示几个测试用例，比如跨月入住3天、当天入住当天退房、延时到16点退房，每种情况金额都对，这比空口讲“我们经过多次测试”有说服力得多。

4. 核心功能模块实操：从登录到报表，逐段拆解实现重点

4.1 登录认证与权限拦截：用拦截器实现角色管控

系统的用户角色分为管理员、前台、经理，不同角色的菜单和操作权限不同。使用SpringMVC的拦截器机制做登录校验和权限控制，是SSM项目的标准做法。

登录成功后将用户信息存入Session：

@RequestMapping("/login") public String login(String username, String password, HttpSession session) { // 密码通常前端做一次MD5，后端再MD5一次，两次加盐更安全 String encryptedPwd = DigestUtils.md5DigestAsHex(password.getBytes()); User user = userService.login(username, encryptedPwd); if (user == null) { return "login"; // 返回登录页并携带错误提示 } session.setAttribute("loginUser", user); return "redirect:/index"; }

然后写一个LoginInterceptor：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } // 角色权限校验: 比如某些经理专属接口需要判断角色 if (request.getRequestURI().contains("/report/") && !"经理".equals(user.getRole())) { response.sendError(403); return false; } return true; } }

拦截器要登录验证和权限校验一起做，不要只判断是否登录。另外，放行静态资源（JS、CSS、图片）的操作也很关键。很多学生第一次配拦截器，把所有路径都拦了，结果页面样式加载不出来，排查半天发现是静态资源被拦截了。正确的做法是在SpringMVC配置里单独放行/resources/**等静态路径。

4.2 客房管理：多条件查询与状态可视化

客房管理模块核心功能是房间列表的分页、多条件模糊查询、新增、编辑、删除。多条件查询建议使用MyBatis的动态SQL，这是体现你对MyBatis掌握程度的好地方。

<select id="selectRoomPage" resultType="com.apple.hotel.entity.Room"> SELECT * FROM room <where> <if test="roomNumber != null and roomNumber != ''"> AND room_number LIKE CONCAT('%', #{roomNumber}, '%') </if> <if test="roomTypeId != null"> AND room_type_id = #{roomTypeId} </if> <if test="status != null"> AND status = #{status} </if> <if test="floor != null"> AND floor = #{floor} </if> </where> ORDER BY room_number LIMIT #{offset}, #{pageSize} </select>

页面展示上，客房状态最好用颜色高亮区分：绿色代表空闲、黄色代表已预订、红色代表已入住、灰色代表打扫中。这种可视化设计成本很低，但能让系统看起来完成度非常高。论文里配一两张截图，视觉效果比纯文字强得多。

4.3 预订与入住办理：事务与业务校验的配合

预订操作的核心流程是：校验房间是否存在且在目标日期空闲，插入预订记录，将房间状态改为已预订。如果预订时房间已经被占用，要抛出业务异常并回滚事务。这一步要加事务控制：

@Transactional(rollbackFor = Exception.class) public void createReservation(ReservationForm form) { // 1. 校验日期合法性 if (form.getExpectedCheckout().before(form.getExpectedCheckin())) { throw new BizException("退房日期不能早于入住日期"); } // 2. 校验房间状态和时间冲突 if (!roomService.isRoomAvailable(form.getRoomId(), form.getExpectedCheckin(), form.getExpectedCheckout())) { throw new BizException("该房间在所选日期时间段内已被预订或入住"); } // 3. 插入预订记录 reservationMapper.insert(form); // 4. 更新房间状态为已预订 roomService.updateStatus(form.getRoomId(), RoomStatus.RESERVED); }

注意@Transactional注解的rollbackFor = Exception.class必须写，因为Spring默认只在抛出RuntimeException时才回滚事务，而自定义的BizException如果不继承RuntimeException，事务不会生效。这个点是很多SSM项目的经典坑，论文里专门写一段“事务管理设计”说明这个细节，会很加分。

入住办理流程类似：校验预订是否存在，将预订状态改为已完成，插入入住记录，将房间状态改为已入住。如果客人没有预订直接入住，则跳过预订表的操作，直接插入入住记录。

4.4 退房结算：计算、记账、改状态三步走

退房结算是最容易出现数据不一致的环节。我的建议是严格按照以下顺序操作：

根据订单ID查询入住记录，确认状态为“在住”。
调用PriceCalculator计算应付房费，同时查询该订单关联的额外消费记录。
在bill表插入房费账单和额外消费账单。
更新订单表，写入实际退房时间、订单总金额、状态改为“已退房”。
将房间状态改为“打扫中”。

第5步改成打扫中而非直接空闲，是为了体现业务完整性——房间打扫完毕之后再由保洁人员（或者管理员）确认变更为空闲。如果系统不涉及保洁角色，可以简化为直接变更为空闲。但从论文角度看，保留“打扫中”状态能体现房间状态机的完整性，建议保留。

结算页面需要回显一个账单明细列表，项目名称、单价、数量、金额、小计，看起来像一张小票，这里用JSTL标签遍历展示即可。退房结算完成后自动打印/展示账单页面，这一步对客人和前台都特别友好，也是系统体验感的重要加分项。

4.5 数据统计与图表：用Hutool + ECharts做可视化

酒店管理人员最关心的报表是“今日入住率”“本月预订量趋势”“房型收入占比”。毕设系统不一定做全套BI，但做一个简单的统计分析页面，对论文“系统特色”部分很有价值。

后端统计可以使用Hutool的DateUtil工具类处理日期范围，再用分组查询聚合数据：

SELECT room_type_name, COUNT(*) AS order_count, SUM(total_amount) AS total_amount FROM check_in_record r LEFT JOIN room rm ON r.room_id = rm.room_id LEFT JOIN room_type rt ON rm.room_type_id = rt.id WHERE check_in_time BETWEEN #{startDate} AND #{endDate} GROUP BY room_type_name

前端图表用ECharts。ECharts作为一个纯前端的JS图表库，在SSM项目中接入非常方便，只需在JSP页面引入echarts.min.js，然后通过Ajax请求后端接口获取JSON数据填充图表配置即可。

这里有一个常见坑：ECharts从4.x升级到5.x之后，对Java后端返回的JSON数据格式要求更严格，数字类型的字段必须是数字而不能是字符串。不少学生用MyBatis查询返回BigDecimal，JSON序列化默认是数字类型，一般没问题；但如果你在VO里自己拼接了字符串类型的金额字段，ECharts就会渲染异常，排查起来还挺费劲。

5. 论文写作与代码配套：怎么让论文和代码互相支撑

5.1 论文目录结构与每个章节怎么填内容

很多人到了写论文阶段才开始发愁，实际上如果你系统做完了，论文只是“翻译”一遍自己的设计思路。一份标准的本科毕业论文结构大致如下：

第1章绪论：写研究背景、意义、国内外研究现状、主要工作、论文结构。国内外研究现状不需要真的查很多文献，但至少要有3-5篇参考文献支撑，可以引用关于酒店信息管理系统、Web开发技术应用方面的期刊论文。
第2章相关技术介绍：逐段介绍SSM框架、JSP、MySQL、Maven、Tomcat、前端框架（Layui/Bootstrap）等。每个技术写一页左右，重点写框架的核心思想和工作原理，不要写成使用说明书。
第3章系统分析：可行性分析（技术/经济/操作）、需求分析（功能需求、非功能需求、用例分析）、系统数据流图。用例图建议至少画管理员、前台、经理三个角色的用例。
第4章系统设计：总体架构设计（B/S架构图）、功能模块设计（模块结构图）、数据库设计（ER图、数据字典表）、接口设计。
第5章系统实现：按照功能模块逐个写实现过程和截图，配合关键代码块进行说明。每个模块写2-3个核心代码片段即可，不要求全量贴代码，但必须贴最核心的业务逻辑代码，业界统称核心代码。
第6章系统测试：测试环境、功能测试用例表、测试结果、性能测试（可选）。功能测试用例表要覆盖主要业务操作，至少包含20个测试用例。
第7章总结与展望：写自己完成的主要工作、不足之处、未来改进方向。

5.2 把核心代码写进论文的正确姿势

论文中的代码不是越多越好，而是要“少而精”，选最能体现技术深度的部分。根据我的经验，以下代码片段最值得放：

时间冲突判断的SQL和Service方法实现。这是系统业务逻辑的精华，放进去以后老师一眼就能看出你的系统不是“学生管理系统”那种纯CRUD。
@Transactional事务控制的方法。配合文字说明事务在预订创建中的必要性。
登录拦截器的实现。体现你对安全控制的考虑。
退房结算的金额计算逻辑。体现你对业务规则的精细化处理。

每一段代码后面都要跟一段“设计思路”或“功能描述”的文字，解释这段代码解决了什么问题、核心逻辑是什么。不少学生贴完代码一个字都不解释，论文看起来像代码堆砌，非常吃亏。

5.3 数据库设计与ER图的画法

数据库设计章节一般需要给出ER图和数据字典。ER图画法推荐用PowerDesigner或者draw.io，后者免费而且画出来的图标准又好看。数据字典以表格形式呈现，每个表一张表，包含字段名、字段类型、是否主键、是否为空、描述。记住尽量把所有表的数据字典都放上去，不要只放几张核心表，格式完整度直接影响老师对论文的态度判断。

5.4 答辩时老师最爱问的问题，提前准备

根据我了解到的答辩情况，SSM酒店管理系统的老师提问往往集中在几个方面：

第一，框架原理类。“SpringMVC请求处理流程是什么？”“MyBatis中#{}和${}的区别是什么？”这些是送分题，你只要用过框架就一定能答上来，但还是要提前准备一下说法。

第二，业务逻辑类。“如果两批客人同时预订同一间房，你怎么处理？”“晚到客人预订的房间，到时间了没来入住，房间是不是就一直锁着？”这类问题考察的是你对业务细节的思考。实践中可以设计无确认预订的自动释放机制，也可以在系统里做“保留房间到某个时间点，超时未到自动释放”的逻辑。哪怕你只是把问题想到了但没在系统完全实现，答辩时如实说明设计方案，都能得到不错的评价。

第三，安全问题类。“密码怎么存储的？会不会SQL注入？XSS攻击怎么防？”回答思路是：登录密码使用MD5加盐存储；SQL注入防护通过MyBatis预编译机制天然防住大部分，敏感查询使用#{}而非${}；XSS防护可以在前端做输入校验和过滤，后端再做转义处理。

6. 实操过程中最常见的5个坑：每个都是血泪经验

6.1 数据库字段大小写与下划线命名不一致导致查询报错

MyBatis的自动映射默认开启下划线转驼峰（配置mapUnderscoreToCamelCase=true），但如果某张表的字段命名不规范（比如混用大小写，或者时而下划线时而不下划线），映射就可能会失效。实际操作时，最稳妥的做法是数据库字段全部使用下划线命名，Java实体类属性全部使用驼峰命名，并确保MyBatis配置正确。

6.2 JSP页面用EL表达式取值取不到

EL表达式取不到值的情况，大部分是因为数据放的位置不对。比如重定向（redirect）之后，Model中的数据是取不到的，必须放到Session中或者用RedirectAttributes传递Flash参数。还有就是循环中取当前对象的属性，写错了属性名也会导致空值，排查时先在页面上用${}表达式直接打印一遍，看看数据到底传没传过去，再逐层定位。

6.3 Maven依赖冲突导致Spring版本不一致

SSM项目里最常见的报错是ClassNotFoundException或者NoSuchMethodError，根源往往是Spring的多个jar包版本不一致。比如spring-webmvc是4.3.20，spring-tx却是4.1.0，功能上未必立即报错，但某些动态代理场景就会出问题。解决办法是在pom.xml中统一管理Spring版本号，使用properties标签定义属性并全部引用同一个版本。

6.4 中文乱码问题

中文乱码在SSM项目里至少有三个源头：JSP页面编码、Tomcat请求编码、数据库连接编码。建议统一设置：JSP页面pageEncoding="UTF-8"，Tomcat的server.xml里URIEncoding="UTF-8"，数据库连接URL加上useUnicode=true&characterEncoding=UTF-8，再用SpringMVC的CharacterEncodingFilter做全局过滤器。四层都统一了基本不会乱码。

6.5 时间日期类型在JSON序列化时格式不对

前端Ajax请求返回的JSON中日期字段如果不做格式化，会显示为一大串数字时间戳或者Gavin才看得懂的英文时间字符串。解决办法是在Java实体类的日期字段上加@JsonFormat注解，指定pattern为"yyyy-MM-dd HH:mm:ss"。

7. 运行环境与部署流程：从零到能跑通的完整步骤

环境要求：JDK 8、Maven 3.6+、Tomcat 8.5+、MySQL 5.7+、IDEA（或Eclipse）。注意JDK版本不要盲目用JDK 17，SSM老项目在很多高版本JDK下会有模块化报错，特别是涉及到反射和动态代理的地方。JDK 8是最稳妥的选择，这一点对新手特别重要。

部署步骤简要说明：

在MySQL中创建数据库hotel_db，设置字符集utf8mb4，执行项目中的init.sql脚本初始化数据。
修改db.properties（或jdbc.properties）中的数据库连接信息，包括用户名密码。
使用IDEA导入Maven项目，等待依赖下载完成。如果下载缓慢，在settings.xml中配置阿里云镜像。
配置Tomcat，将项目部署到Tomcat中运行。
启动后访问http://localhost:8080/hotel/，使用管理员初始账号登录系统。

如果遇到项目启动直接报404或者ClassNotFound，优先检查Artifacts配置里WEB-INF/lib是否打了依赖包，这是IDEA部署Web项目最常见的坑。

8. 从毕设到面试：做完这个项目，你能讲出什么亮点

很多学生做完毕设就把它扔到一边，非常可惜。酒店住房管理系统如果你真的吃透了，面试时可以讲出不少加分点。

第一个亮点是业务复杂度的体现。大多数学生的项目都是图书管理、班级管理这类纯增删改查，你可以讲房间状态机流转、预订时间冲突判断、退房计费规则等业务逻辑，这些内容是能展现出需求的深度分析的。

第二个亮点是事务和并发思考。你可以聊“预订房间时如何保证数据一致性”“同一个房间被两个前台同时操作怎么处理”。哪怕你用的是数据库行锁，甚至只是乐观锁方案，能讲清楚就是加分项。因为绝大多数应届生面试项目都没有涉及过这类问题。

第三个亮点是工程化意识。包括日志记录、异常处理、参数校验、分层设计、命名规范。这些在源码里都能找到对应的代码，面试时主动讲这些细节，比只讲功能列表给人的印象好得多。

苹果酒店住房管理系统这个题目，表面看是一套平平无奇的CRUD，但你要真把它当成一个“产品”来做——状态怎么流转、账怎么算清楚、房间怎么避免重复订、角色怎么分工协作——做出来的东西和随便撸的拖拖拽拽管理系统，差距一眼就能看出来。无论是应付毕设答辩，还是作为面试讲的项目，它都够用了。关键在于你愿意投入多少思考进去。

我的建议是：拿到这类题目，不要急着写代码。先把业务边界理顺，把状态流转和计费规则设计清楚，再用SSM按部就班地填充代码。每一步多想想“为什么这样做”，论文和代码都会顺理成章地完整起来。

SSM框架苹果酒店住房管理系统：从CRUD到业务闭环的Java毕设实战指南