几年前我刚开始学 Java 的时候，最头疼的不是语法，而是学完语法之后不知道能干什么。直到后来做课程设计，被要求写一个“Java 酒店管理系统（完整版）”，我才意识到：原来一个看起来平平无奇的管理系统，能把 Spring Boot、MyBatis、MySQL、事务、权限、状态机这些 Java Web 的核心知识点全部串起来。从那次之后，我就把“酒店管理系统”当成带新人入门 Java 后端的第一推荐项目。
这篇博文没有废话，面向真正想从零动手的读者。我会把整套系统拆成模块，从技术选型、数据库设计讲到下单入住的业务逻辑，再讲新人最常踩的坑和上线部署的细节。全文都是我当时一行行代码试出来的经验，你照着做不会跑偏，收藏这一篇，足够从新手做到能独立交付的水平。
1. 项目定位与技术路线选择
1.1 为什么酒店管理系统适合作为 Java 入门项目
很多新人一上来就去模仿电商系统，结果被商品、SKU、秒杀、库存、支付这些概念砸晕，代码写到一半就放弃。酒店管理系统的业务模型要清晰很多，核心就三件事：订房、入住、结账。
不要小看这三件事。订房涉及时间区间判断、房间状态流转；入住涉及押金、房费、消费记账；结账涉及账务流水、优惠计算。这些业务不复杂，但足够让你练到 Java Web 开发的主干能力：CRUD、事务、关联查询、会话管理、异常处理。关键的一点是，酒店业务自带“状态机”这个天然素材，不同状态之间的转换逻辑一旦理清楚，你会对业务建模产生真正的感觉，而不是停留在“对着数据表写增删改查”的阶段。
另一个好处是数据表关系非常典型。客房、房型、客户、订单、入住信息、账务流水，每张表之间都有清晰的外键关系，多表联查、聚合统计都能用上，而且不会像电商那样复杂到难以调试。
1.2 技术栈选型：传统 JSP 和 Spring Boot 怎么选
我在帮新人规划项目时，经常被问到：做 Java 酒店管理系统，到底用 JSP + Servlet 还是 Spring Boot + MyBatis？我的答案很明确：如果你是为了就业和做完整作品，直接选 Spring Boot + MyBatis + MySQL。但前提是你要刻意去理解 Servlet 的生命周期、请求到 Controller 的映射过程，这些底层思想不能因为框架封装好了就跳过。
两种方案的差异，我整理成了一张对比表：
| 对比项 | JSP + Servlet + MySQL | Spring Boot + MyBatis + MySQL |
|---|---|---|
| 上手节奏 | 配置多，代码繁琐，适合打底层基础 | 约定大于配置，几秒启动开发 |
| 页面开发 | JSP 里容易混入 Java 逻辑，维护成本高 | 搭配 Thymeleaf 或前后端分离，职责清晰 |
| 事务与依赖管理 | 需要手写一堆工具类和配置文件 | Spring 容器统一管理 |
| 就业场景 | 高校教学场景多，企业新项目基本不再使用 | 中小型项目的主流方案 |
| 适合人群 | 有时间慢慢啃原理的初学者 | 希望快速产出完整作品的初学者 |
我的建议是：如果你是刚学完 Java SE，但只有两三周时间做项目，直接选 Spring Boot。如果时间充裕，可以用 Servlet 版本先写一遍登录和客房列表，再把这部分经验迁移到 Spring Boot 上。很多新人担心直接学框架会“根基不稳”，这个担心有道理，但框架本身就是在 Servlet 规范之上封装的，你用框架的同时去理解请求怎么进去、拦截器怎么生效，基础也就补上了。
1.3 项目边界与部署形态
酒店管理系统并不一定需要做成互联网级应用。大多数实际场景是酒店前台局域网内使用，一台电脑当作服务端，其他前台 PC 通过浏览器访问。这意味着你不需要一开始就考虑分布式、Redis、消息队列这些东西。MySQL + Spring Boot 打成一个 jar 包，局域网内跑起来，就是一个完全可用的系统。
我做过一个简化版的案例，放在一家小型连锁酒店试用，一共就三台前台电脑，系统跑在一台普通办公主机上，数据库就在本机，稳定性完全够用。这也提示你：做项目不要先想着堆技术，而是先想清楚“谁在用、什么环境、量有多大”。入门阶段把一个单机应用做到逻辑正确、界面好用，比挂一堆中间件要实际得多。
2. 业务模块拆解与数据库建模
2.1 六个核心模块划分
一个可交付的酒店管理系统，至少包含六个模块：系统管理、客房管理、预订管理、入住管理、收银结账、统计报表。别一开始就想着做会员、积分、房价日历这些增值功能，那些可以后面再扩展，先把主干跑通。
- 系统管理：用户登录、角色权限、基础参数
- 客房管理：房型维护、房间档案、房态维护
- 预订管理：订单创建、订单取消、预订查询
- 入住管理：开房登记、换房、续住、退房
- 收银结账：押金管理、消费录入、账单结算
- 统计报表：入住率、收入汇总、房态统计
每个模块之间不是孤立的。创建预订会改变房间状态，办理入住会基于预订记录生成入住单，退房时会根据入住天数、消费项目生成账单并释放房间。如果这些状态没有理顺，后面写代码很容易出现“房都退了，房间还显示入住中”这种低级问题。
2.2 房态流转：这个系统的核心业务痛点
酒店管理的最大痛点不在增删改查，而在房态准确。一栋楼几百间房，客人什么时候到、什么时候走、房间什么时候打扫完，稍有差错就会导致前台超卖。所以你必须把房间状态建模清楚。
我是这样设计的：房间状态分为可售、已预订、入住中、打扫中、维修中五种。
- 可售：房间空闲，前台可以卖
- 已预订：客人已下订单，房间暂时保留，但客人还没到店
- 入住中：客人已办理入住，房间被占用
- 打扫中：客人退房后，保洁尚未完成确认
- 维修中：房间设施故障，暂时不能出售
状态转换也要锁定死：可售房可以转为已预订或入住中；已预订房间到店后转为入住中；入住中退房后先转为打扫中；打扫完成转回可售；任何状态下发现设施故障，都可以转维修中。这不只是设计文档，它直接对应到你代码里的 update 语句。比如取消预订，你要判断房间原来是不是“已预订”状态，不是就直接拒绝，防止有人乱调接口把房间状态改乱了。
2.3 核心表设计：六张表就能跑通全流程
数据库是酒店管理系统的地基。我建库时用的是 MySQL 8.x，字符集直接选 utf8mb4，避免后面出现中文乱码问题。下面这六张表是核心，一定要把它们的关系搞清楚。
房型表创建语例如下：
CREATE TABLE room_type ( id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(30) NOT NULL COMMENT '房型名', price DECIMAL(10, 2) NOT NULL COMMENT '门市价', bed_type VARCHAR(20) COMMENT '床型', bed_count INT DEFAULT 1 COMMENT '床位数', area INT COMMENT '面积', remark VARCHAR(255) ) COMMENT '房型表';客房表：
CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL UNIQUE COMMENT '房间号', room_type_id INT NOT NULL, floor INT, status VARCHAR(10) NOT NULL DEFAULT '可售', remark VARCHAR(255), FOREIGN KEY(room_type_id) REFERENCES room_type(id) ) COMMENT '客房表';客户与订单表、入住表、账务表也都必不可少。订单表里需要注意开始时间、结束时间、订单状态；入住表要关联订单、房间、客户；账务表用于记录每一笔押金、房费和消费。
我在做测试时发现一个细节：价格字段不要用 DOUBLE。房价和金额一旦涉及计算，浮点精度早晚会给你惹出麻烦。数据库里用 DECIMAL(10,2)，Java 实体里用 BigDecimal，前后端传输用字符串或保留两位小数，这是很早以前吃了亏之后养成的习惯。
3. 从零到一的实操搭建流程
3.1 项目骨架与基础依赖
先说怎么把工程搭起来。如果你是刚接触 Spring Boot，建议直接用 IDEA 的 Spring Initializr，选 Java 8 或 11，打包方式选 Jar。依赖这一块必须勾选：Spring Web、MyBatis Framework、MySQL Driver。为了写页面方便，我会加上 Thymeleaf。如果你的团队更习惯前后端分离，也可以换成 Spring Web + Vue 的组合，但新手我还是建议用服务端渲染，少一层跨域和接口联调的成本。
pom.xml 里的核心依赖大致长这样：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency>里面有个容易让新人翻车的地方：MyBatis 的 starter 版本和 Spring Boot 版本需要匹配，我用的 Spring Boot 2.7.x 对应 MyBatis starter 2.3.x；如果你用的是 Spring Boot 3.x，包名和依赖都有变化，建议直接查官网的版本对应关系，不要盲目拿旧代码硬套。
application.yml 配置如下：
spring: datasource: url: jdbc:mysql://localhost:3306/hotel?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case 这个配置值得单独说一句。数据库字段是 room_type_id，Java 属性是 roomTypeId，如果没有开启驼峰映射，你每次查询都要写别名，非常麻烦。开启之后，MyBatis 会自动完成映射，省掉大量重复劳动。
3.2 登录与权限：拦截器比注解更容易理解
酒店管理系统不需要复杂的权限框架，用简单的 Session 加拦截器就够了。用户登录时把用户信息放进 Session，然后定义一个 HandlerInterceptor，在请求进入 Controller 前检查 Session 是否存在。
这里有个经验：不要让新人直接去用 Spring Security，至少在第一个项目里不要。Spring Security 的过滤器链、密码加密、认证管理器对新人来说一下子铺开，很容易陷入配置海洋，连登录都跑不起来。先用拦截器把登录状态管理起来，理解“请求在进入业务方法前被拦截”的思想，后面再学 Spring Security 会顺利很多。
拦截器核心代码：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.setContentType("text/html;charset=utf-8"); response.getWriter().write("请先登录"); return false; } return true; } }然后注册到 WebMvcConfigurer，同时把登录接口、静态资源路径排除掉，不然样式和脚本都会加载不出来。这又是一个新人经常踩的坑：登录接口被拦截器拦住，页面跳转死循环，或者 CSS 文件全被拦掉。排除路径时记得把/login、/css/**、/js/**加进去。
3.3 “预订房间”核心业务逻辑：并发安全是关键
预订流程是整个系统里最容易出错的地方。我以“用户在前台选定房间并提交订单”为例，完整讲一遍思路。
先看 Service 层的实现，这里必须加事务：
@Transactional(rollbackFor = Exception.class) public Long createOrder(CreateOrderRequest req) { // 1. 锁定房间行记录，防止并发下重复预订 Room room = roomMapper.selectByIdForUpdate(req.getRoomId()); if (room == null) { throw new BusinessException("房间不存在"); } if (!"可售".equals(room.getStatus())) { throw new BusinessException("房间当前状态不可预订"); } // 2. 校验订单时间是否和其他订单重叠 int count = orderMapper.countOverlap( req.getRoomId(), req.getStartDate(), req.getEndDate()); if (count > 0) { throw new BusinessException("该时间段房间已被占用"); } // 3. 创建订单 Order order = new Order(); order.setRoomId(req.getRoomId()); order.setCustomerName(req.getCustomerName()); order.setStartDate(req.getStartDate()); order.setEndDate(req.getEndDate()); order.setStatus("已预订"); order.setCreateTime(new Date()); orderMapper.insert(order); // 4. 将房间状态改为已预订 roomMapper.updateStatus(req.getRoomId(), "已预订"); return order.getId(); }这段代码里有三个关键点。第一是 selectByIdForUpdate，它在查询房间时给这行记录加了行级锁，另一笔相同房间的预订请求必须等待当前事务提交后才能继续，这就避免了两个前台同时卖出同一间房。第二是日期重叠判断，SQL 用的是“开始时间小于对方结束时间，且结束时间大于对方开始时间”这个交集条件，比简单比较日期要严谨得多。第三是 @Transactional 必须加在 Service 层方法上，事务边界要覆盖整个业务流程。
如果把事务加在 Controller 层，也不是绝对不行，但业务代码会变得混乱，而且一旦你后续拆服务或者做单元测试，事务行为的差异会暴露出来。我见过很多新人的代码把业务逻辑写在 Controller 里，一个方法几百行，Service 层形同虚设。这个习惯趁早改掉。
3.4 房态看板页面：前后端如何配合
页面端我用 Thymeleaf 做服务端渲染，再用一小段 jQuery 定时器实现房态自动刷新。前台看到的房态看板，是一个楼层平面图，每一间房显示房间号、房型、价格和当前状态，用不同颜色区分。
房态卡片大致是这样遍历的：
<div th:each="room : ${roomList}" class="room-card" th:classappend="${room.status}"> <div class="room-no" th:text="${room.roomNo}">101</div> <div class="room-type" th:text="${room.typeName}">标准大床房</div> <div class="room-status" th:text="${room.status}">可售</div> </div>状态用颜色区分就能看得很清楚，我会在 CSS 里为“可售”“已预订”“入住中”定义不同背景色。定时器每 30 秒调用一次房态查询接口，返回最新数据后刷新页面。注意，此时后端接口返回的数据最好是最小化字段，只包含房间 id、房间号、状态，否则几百间房每次都把整张大表传回来，前台电脑配置低会卡顿。
定时刷新代码很简单，但我还是建议加上“当前是否有未保存操作”的判断。如果前台正在录入客户信息，此时页面被定时器刷新，输入内容会全部丢失。我做了一个全局标记，正在操作表单时暂停自动刷新，操作完成后再恢复。这个细节虽然小，但非常影响真实使用体验，也是测试时最容易忽略的点。
4. 新人必踩的坑与排查实录
4.1 数据库中文乱码：根源往往不止一处
中文乱码是 Java Web 新手遇到最多的一个问题。我排查过很多次，发现病根往往有三层：数据库建库字符集不是 utf8mb4、JDBC 连接 URL 没有加 characterEncoding=utf8、页面本身没有声明 UTF-8。
解决办法是按顺序排查：
- 建库语句用
CREATE DATABASE hotel DEFAULT CHARACTER SET utf8mb4; - 连接 URL 加上
useUnicode=true&characterEncoding=utf8 - 页面文件头部加上
<meta charset="UTF-8">
如果你用的是 Spring Boot，大多数情况下设置好连接 URL 就能解决。但如果在 MyBatis 的 XML 里写 SQL 时乱码，还要检查 XML 文件本身的编码格式，IDEA 右下角如果显示 GBK，需要手动改成 UTF-8。
4.2 房间重复预订：并发问题不是运气问题
我在一次模拟测试中，用两个浏览器标签页同时提交同一个房间的订单，结果成功创建了两笔订单。当时的代码只判断了“房间状态是否可售”，没有加锁也没有事务，导致两个请求同时读到可售状态，然后同时更新，最后一间房被卖了两次。
修复方案就是前面代码里那张“selectByIdForUpdate”加事务的组合。这里要特别注意：只有行锁生效还不够，还必须有事务把整个业务包起来。没有事务，第一次 update 提交后锁就释放了，另一个请求依然可以进来。单独依赖任何一个环节，都会前功尽弃。
4.3 金额计算误差：double 的精度是硬伤
我最初写账单计算时用了 double，账单金额是 128.9 元，客人消费 39.6 元，结账时显示应收 89.30000000000001 元。这个局面在真实系统里是不能接受的。
正确的做法是三处同时改：数据库价格列用 DECIMAL(10,2)，Java 实体用 BigDecimal，计算时不要再用基本类型 double。BigDecimal 构造函数有个细节：new BigDecimal(0.1)依然会得到不精确的二进制浮点结果，一定要用new BigDecimal("0.1")或BigDecimal.valueOf(0.1)。我已经很多次见到新人把 double 塞进 BigDecimal 构造器然后一脸困惑。
4.4 高频问题速查表
下面这张表里是新人做这个项目时最容易遇到的十来个问题，我按“现象、原因、解法”整理好了：
| 现象 | 原因 | 解决方法 |
|---|---|---|
| 页面中文全部是问号 | 数据库或连接未设置 utf8 | 统一库表、连接串、页面编码为 UTF-8 |
| 同一房间被重复预订 | 读状态与写状态之间无锁 | 使用 select for update + 事务 |
| 金额出现 0.30000000000004 | 使用了 double 计算 | 改用 BigDecimal(string) |
| 接口报 404，但 Controller 存在 | 映射路径或类未被扫描 | 检查 @RestController 包路径和项目结构 |
| 启动报数据库连接失败 | 密码错误或 MySQL 服务未启动 | 先确认 mysql 命令行能否连上库 |
| 登录后页面仍反复跳回登录页 | 拦截器放行路径没写对 | 检查 /login 与静态资源路径是否排除 |
| MyBatis 提示无效 bound statement | mapper 接口和 XML 命名空间不匹配 | 检查 namespace、方法名、id 是否一致 |
| 表单提交后日期变为 null | 前端日期格式与后端解析不匹配 | 使用统一日期格式，并在实体上配置 @DateTimeFormat |
| 退房后房间状态没有变 | 服务层没更新房态 | 结账事务里同时更新房间状态 |
| 数据出现重复记录 | 插入前没有查重 | 加时间重叠校验或唯一索引 |
| 本地正常，部署服务器出现 404 | 静态资源路径大小写不匹配 | 检查路径大小写，Linux 下敏感 |
4.5 一个排查过最久的诡异问题：MyBatis 查询不到数据但不报错
这个问题折磨了我很久：运行环境在 IDEA 里一切正常，打包部署到服务器后，某几个查询接口返回空数据。后来定位到原来是打包时 Maven 默认没有把 src/main/java 目录下的 XML 文件复制进 classpath。因为我把 SQL 写在 XML 里，而这些 XML 放在了和 Mapper 接口包名相同的目录下。
解决办法是在 pom.xml 的 build 节点里加上资源目录配置，把 mapper 目录下的 xml 文件一起打进去。更简单的做法是统一把 XML 放到 src/main/resources/mapper 目录下。这也是为什么姓名首字母一定要按规范来，不要“自创目录结构”，坑太多。
5. 测试验收与上线部署细节
5.1 全流程手工测试清单
项目做完不是能编译就叫完成。我在交付前会跑一遍完整的业务场景，每个环节都手动走一遍，并把结果记录下来。这里分享一张我当时用的测试流程清单：
| 测试场景 | 操作步骤 | 预期结果 |
|---|---|---|
| 登录成功 | 输入正确账号密码 | 跳转到首页 |
| 登录失败 | 输入错误密码 | 提示账号或密码错误 |
| 无权限访问 | 未登录直接访问 /room/list | 被拦截器拦下 |
| 创建预订 | 选择可售房，填写入住日期 | 订单创建，状态变为已预订 |
| 时间冲突预订 | 选择同一房间重叠时间段 | 提示时间段不可用 |
| 办理入住 | 选择已预订房间做入住登记 | 状态变为入住中，生成入住单 |
| 换房 | 从入住中房间换到另一间 | 原房间释放，新房间变为入住中 |
| 退房结账 | 对入住中房间结算 | 生成账单，状态变为打扫中 |
| 打扫确认 | 保洁确认完成 | 状态变回可售 |
| 并发订房 | 两个终端同时提交同一房间 | 只有一单成功 |
| 报表统计 | 查看本月入住率与收入 | 数据与手工计算一致 |
这套清单跑下来，基本能暴露 80% 的常见功能问题。注意并发订房这一个场景，很多初学者不会主动测，但恰恰是最能体现系统质量的地方。
5.2 打包与部署：从 jar 包到局域网可用
部署环节节奏很快。在 IDEA 右侧 Maven 面板执行 package，如果配置正常会生成一个可执行的 jar 包。我当时的部署命令很简单：
java -jar hotel-system.jar --spring.profiles.active=prod生产环境的数据库连接配置建议写在 application-prod.yml 里，并在启动时通过--spring.config.location指向外部配置文件。这样以后改密码不用重新打包，直接改配置文件再重启服务即可。
还有一个容易被忽略的点：MySQL 服务大多数安装在 Windows 服务器上，你要确保 MySQL 服务开机自启，否则服务器重启后系统无法连接数据库。这一步很基础，但对不熟悉运维的开发者来说，第一次部署时往往手忙脚乱。
5.3 上线后的日常运维注意事项
系统上线后，日志是唯一能告诉你发生了什么的东西。Spring Boot 默认的日志只输出到控制台，重启就丢了。我在测试环境吃过亏后，就配置了 Logback 滚动日志，每天生成一个日志文件，只保留 30 天，避免磁盘被撑爆。
配置很简单，在 application.yml 里使用 logging.file.name，或者直接在 classpath 下放一个 logback-spring.xml。日志内容至少要包含请求路径、处理时长和关键异常堆栈。酒店前台一旦反馈“某个房间打不开”，日志能第一时间定位到是数据库问题还是代码问题，省掉来回扯皮的时间。
做这个项目时我印象最深的一段经历，是我第一次做并发测试。两个浏览器窗口同时下单，我盯着数据库里轰然多出的两条重复订单，第一次直观感受到“并发”不是面试题里抽象的名词，而是真实业务里会咬人的怪兽。后来修好了，把这段经历写进博客，评论区好多人说自己也是这样踩坑的。
我个人最大的体会是：Java 酒店管理系统不是一个“高大上”的项目，但它涵盖了从数据库表设计、事务管理、权限控制到并发处理的完整链路。你要是能把这个项目从设计、开发、测试到部署全部走一遍，再去面 Java 初级岗位，至少在项目经验和常见问题上，你已经比大多数只写过“学生管理系统”的候选人扎实很多。如果你正在做类似项目，建议先别急着增加功能，把房态流转、订单并发、金额精度这三条底线守住，系统就已经是个能用的真系统了。
