SpringBoot酒店管理系统核心设计与实战解析-代码聚汇网

1. 项目整体设计与技术选型思路

1.1 核心需求解析：酒店管理到底在管什么

先聊点实在的。很多人一听"酒店管理系统"就觉得是老生常谈，无非是登记、退房、收钱。但真正把一个酒店的前台业务捋一遍，你会发现这里面涉及的状态流转和业务规则远比你想象的复杂。四季来酒店管理系统这个项目，本质上是在解决酒店运营中三个核心问题：房间状态的可视化、订单流程的闭环化、经营数据的可追溯化。

我先拆解一下业务场景。一家中等规模的酒店，通常有标准间、大床房、套房、钟点房等多种房型，每一种房型又有不同的价格策略、可订数量、楼层分布。客人到店后，前台要快速判断"现在有哪些房可卖"，这背后涉及客房状态的管理——是空净房、空脏房、维修房还是在住房。客人下订单，要判断预订日期内该房型是否还有余量，入住时要把预定单转为入住单，退房时要计算房费、押金抵扣、额外消费。这些流程如果靠Excel和纸质单据，不仅效率低，还容易出错。所以这个系统的第一设计目标，就是把前台从"翻本子"里解放出来。

另一个容易被忽视的痛点是权限与角色。酒店的员工分为前台、客房部、经理、系统管理员等角色，前台能做的操作和经理能查看的数据完全不是一回事。比如前台可以办理入住，但不能随便改房价；经理能看到营收报表，但不能像管理员一样去配置系统参数。因此，权限管理从需求阶段就应该被当作一等公民来设计，而不是后期补丁式地加上去。这个项目在这一点上做得比较完整，也正因为它贴近真实业务，作为毕业设计选题时才更有说服力。

1.2 技术选型：为什么是SpringBoot而不是别的

技术选型是这个项目最值得展开讲的部分。市面上做Web后端的技术栈很多，SSH（Spring + Struts + Hibernate）已经是老古董，SSM（Spring + SpringMVC + MyBatis）在五年前还是很主流的组合，但放到今天，SpringBoot几乎成了Java后端项目的默认起点。

我自己带过不少毕业设计，也帮人改过老项目，最大的感受是：SSM时代最大的痛点是配置地狱——你要配web.xml、配Spring容器、配SpringMVC扫描器、配MyBatis的SqlSessionFactory、配事务管理器、配数据源，任何一个地方写错一个路径，项目就起不来。而SpringBoot通过自动配置和约定优于配置的原则，把绝大部分默认配置都帮你做好了。你只需要引入一个spring-boot-starter-web依赖，写一个启动类，就能跑起一个Web应用。这个体验对新手来说是非常友好的，它把精力从"折腾配置"转移到了"专注业务"上。

再说说为什么不用更轻量的方案。有的同学可能会想，一个酒店管理系统，用PHP或Node.js写不是更快吗？确实，PHP的Laravel框架在CRUD类业务上效率很高，Node.js的Express也很简洁。但作为计算机专业的毕业设计，Java + SpringBoot这套组合在技术深度和知识覆盖面上面有明显的优势——它涉及到依赖注入、面向切面编程、事务管理、ORM映射、自动配置原理等一系列核心知识点。答辩的时候，你有足够的内容可以讲，也更容易把"为什么这么设计"讲清楚。再加上国内企业级应用对Java的接受度一直很高，这个项目沉淀下来的经验在找工作时也能直接复用。

1.3 系统架构与功能模块边界

这个项目采用的是典型的前后端分离架构。前端用Vue + Element UI，后端是SpringBoot提供RESTful API，数据层用MyBatis-Plus操作MySQL。前后端通过JSON格式的数据交互，用JWT做身份认证。整体分为三个端：用户端（微信小程序或浏览器网页，用于在线订房）、管理端（给酒店前台和经理使用，处理日常运营）、服务端（SpringBoot对外提供的接口层）。

关于功能模块，我按业务优先级把整个系统划分为以下核心块：

客房管理：房型设置、房间信息维护、客房状态实时展示与变更
预订管理：在线预订、订单查询、取消预订、预订冲突校验
前台管理：入住登记、退房结账、押金管理、换房操作
会员管理：会员注册、等级成长、积分累计与抵扣
统计分析：入住率统计、营收报表、房态分布图
系统管理：员工账号管理、角色权限配置、操作日志

这个模块划分不是拍脑袋想出来的，它对应的是酒店前台一天的真实工作流。住客从在线下单到离店，要经过"预订→到店确认→入住→在住服务→退房→结算"这条完整链路。系统的设计目标就是让这条链路上的每一个环节都有对应的功能和数据记录，不留死角。后面我会挑几个核心模块，把表结构和实现逻辑展开讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 核心功能模块与数据库设计实战

2.1 数据库表结构设计：从业务流转到表关系

数据库设计是这类管理系统项目的灵魂。很多毕业设计做得浅，看上去功能都有，但仔细一看只有两三张表，这肯定是不行的。我设计这个系统时一共规划了12张核心表，分成四组：

基础数据组：用户表、角色表、菜单权限表
客房业务组：房型表、房间表、房态变更记录表
订单核心组：订单表、订单明细表、入住登记表
经营分析组：会员表、积分流水表、操作日志表

这里我重点讲讲订单表的设计，因为它最容易踩坑。初学者往往设计一张"万能订单表"，把预订人、入住人、房型、入住日期、离店日期、房价、押金、实付金额全部塞进去。表面上看起来很方便，实际上会导致很多问题——比如一个订单订了两间房怎么办？订单延长住宿怎么记录？订单被修改过价格，原始价格去哪里追溯？

我的思路是拆分成订单主表和订单明细表。订单主表存订单编号、下单用户、订单状态、总金额、创建时间等汇总信息；订单明细表按房间维度和日期维度拆分，每个房间每晚对应一条记录，包含该晚的房价、是否已结算等字段。这种设计的好处是，后续做收益统计、房态冲突判断、价格修改历史追溯都非常方便。SQL查询时稍微做一下联表就能拿到完整视图。

下面是订单表和订单明细表的核心字段，我直接给出建表语句中最重要的部分：

sql复制CREATE TABLE `od_order` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键',
  `order_no` VARCHAR(32) NOT NULL COMMENT '订单编号',
  `user_id` BIGINT NOT NULL COMMENT '下单用户ID',
  `order_status` TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态:0待支付 1已预约 2已入住 3已完成 4已取消',
  `total_amount` DECIMAL(10,2) NOT NULL COMMENT '订单总金额',
  `pay_type` TINYINT DEFAULT NULL COMMENT '支付方式:1微信 2支付宝 3现金 4银行卡',
  `create_time` DATETIME NOT NULL COMMENT '创建时间',
  `update_time` DATETIME NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

CREATE TABLE `od_order_detail` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `order_id` BIGINT NOT NULL COMMENT '所属订单ID',
  `room_id` BIGINT NOT NULL COMMENT '房间ID',
  `room_type_id` BIGINT NOT NULL COMMENT '房型ID',
  `stay_date` DATE NOT NULL COMMENT '入住日期',
  `price` DECIMAL(10,2) NOT NULL COMMENT '当日房价',
  `settle_status` TINYINT NOT NULL DEFAULT 0 COMMENT '结算状态:0未结算 1已结算',
  PRIMARY KEY (`id`),
  KEY `idx_order_id` (`order_id`),
  KEY `idx_room_date` (`room_id`, `stay_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表(按房间按天拆分)';

订单明细按"天"拆分的思路，是我在实际开发中被骂过一次后学到的。最开始我用的是"一个订单明细记录一个房晚段"，即入住日期到离店日期为一个时间段。结果做房态冲突判断的时候，SQL写起来极其痛苦——要判断两段时间是否重叠，边界条件多到怀疑人生。改成按天拆分之后，房间在某一日期是否可用就变成了一条简单的等值查询，逻辑清晰，性能也没问题。

2.2 客房状态管理：从物理状态到系统状态

客房状态是这个项目里业务逻辑最琐碎的部分，也是最值得花篇幅讲的。从物理上看，一间房的状态包括：空净房（Vacant Clean）、空脏房（Vacant Dirty）、在住房（Occupied）、维修房（Out of Service）。这几种状态之间的流转，对应的是酒店日常运营中的不同动作：

客人退房 -> 房间从"在住房"变成"空脏房"
保洁打扫完毕 -> 房间从"空脏房"变成"空净房"
前台办理入住 -> 房间从"空净房"变成"在住房"
房间设施故障 -> 房间从"空净房"变成"维修房"

这个状态机看似简单，但落到系统实现上，需要解决两个问题：状态变更要有记录，状态的查询要高效。

对于第一个问题，我单独建了一张room_status_log表，每次状态变更都写入一条日志，记录变更前、变更后、操作人、变更原因和变更时间。这样做的好处首先是可追溯，万一出现纠纷，能查清楚房间状态的变化链路；其次是为统计报表服务，比如算"客房平均清扫时长"，就要依赖状态日志里的时间差。

对于第二个问题，我的做法是在room表上维护一个current_status字段作为冗余，实时查询时直接走这个字段，速度最快。同时用一张room_date_status表来记录"未来一段时间内房间的占用情况"，用于预订时的可用性判断。这其实是一个很典型的空间换时间方案——实时状态用当前值，未来状态用日历表。

可能有人会问，为什么不直接实时计算?原因是酒店需要处理"未来预订"的场景。比如今天是6月1日，有客人要预订6月10日至6月12日的房间。此时房间当前状态是"空净房"没错，但它6月10日是否可用，取决于有没有其他订单已经锁定了这个房间。如果每次都去订单表里扫描日期区间，数据量大了以后查询会越来越慢。所以维护一张按日期+房间维度的状态表，每天凌晨跑定时任务或用触发器更新，是更稳妥的做法。

2.3 预订与入住流程：并发冲突的预防方案

预订模块的核心难点不是CRUD，而是并发冲突。想象一个场景：只剩下最后一件大床房，A客人和B客人在同一秒提交了预订请求。如果系统不做任何限制，两个人都会收到"预订成功"的提示，到了酒店现场才发现只有一个房间，那就尴尬了。

解决并发冲突的常见方案有三种：

数据库乐观锁：在订单明细表插入前，先检查该房型在目标日期段内的已占用量，如果小于总量则插入，否则报错。这里需要一个唯一约束或版本号机制来兜底。
分布式锁：使用Redis的SET NX EX命令，以"房型+日期段"为key加锁，保证同一时刻只有一个请求在处理同一房型的预订。适合分布式部署场景。
数据库悲观锁（行锁）：操作前先SELECT * FROM room WHERE id = ? FOR UPDATE，锁住房间行，处理完再释放。实现简单，但在高并发下性能一般。

四季来酒店管理系统用的是乐观锁 + 唯一索引的组合方案。在od_order_detail表上对room_id和stay_date两个字段建立唯一索引（上面建表语句里的idx_room_date就埋了这个伏笔）。这样即使两个请求同时插入同一房间同一日期的明细，数据库层面也会拒绝第二个插入操作。配合MyBatis-Plus的insert返回影响行数判断，如果插入0行就说明该房间已经被占用，直接抛出业务异常提示"该房间已被预订"。

这个方法最妙的地方在于，它把并发控制的复杂度交给了数据库，而不是在应用层费尽心思写锁。代码写起来简单，而且数据库的唯一索引是天然可靠的，不存在分布式锁可能出现的锁超时、锁误删等问题。对于单体应用、并发量不大的酒店系统来说，这是性价比最高的方案。

2.4 退房结算与财务模块：金额计算的严谨性

退房结算是整个系统中钱相关最敏感的地方。房费计算规则我给大家总结一下：

房费 = 每晚价格之和（按订单明细表里的price字段求和）
如果超过退房时间（通常是中午12点或下午2点，具体看酒店规则），要加收延时费
如果客人有额外消费（迷你吧、洗衣、餐饮），要累加到账单里
押金在退房时退还，如果有损坏赔偿从押金里扣

这里最容易出错的是金额精度问题。我见过很多新手直接用float或double类型存金额，存完之后发现0.1+0.2不等于0.3，账单对不上。Java的浮点数运算在这方面的精度损失问题，是每个做财务功能的开发者都必须知道的第一课。所以在整个系统里，所有金额字段我全部用DECIMAL(10,2)，Java代码里用BigDecimal进行计算，杜绝了精度问题。

退房的流程设计上，我把它分成三个步骤：

预结算：系统自动计算房费、延时费、额外消费，生成账单明细，前台人员可以核对
确认收款：账单确认无误后，点击结算，系统扣减押金并生成实付金额，更新订单状态为"已完成"
房间释放：将对应房间状态改为"空脏房"，通知保洁人员打扫

这个三步走的好处是每一步都有明确的操作人和时间记录，出了问题能追溯。我在前几家酒店项目的实际运营中发现，前台最怕的就是结错账，有了预结算和确认的环节，出错的概率大大降低。

3. 项目搭建实现与核心代码解析

3.1 SpringBoot项目初始化与环境准备

环境准备这部分，我直接把完整清单列出来，按这个走基本不会踩坑：

JDK版本：1.8（不要用太高版本，兼容性问题会让你怀疑人生，后面会单独讲）
Maven：3.6+，用来管理依赖
IDE：IDEA（社区版够用）
数据库：MySQL 5.7或8.0均可
前端：Vue 2 + Element UI（Vue3也可以，但Element UI的生态更成熟，国内教程也更多）

创建SpringBoot项目的具体方式有两种，我个人推荐用start.spring.io在线初始化，选好依赖后下载压缩包导入IDEA就行。这个项目需要的starter依赖如下：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency>

这里单独说说为什么引入Spring Security。很多同学做管理系统的时候觉得Security太重，用拦截器就够了。但酒店管理系统的权限需求其实不简单——不同的角色（前台、客房部主管、经理、管理员）能访问的接口完全不同，还需要防SQL注入、防XSS、做登录态管理。Spring Security虽然学习曲线陡一点，但它把这些安全能力都内置了，通过配置就能启用，长期看是省事的。而且毕业设计答辩时，"我用了Spring Security做基于RBAC的权限控制"这个表述本身就是一个加分项。

我的实际做法是：Spring Security负责认证和请求拦截，JWT做无状态token的生成与校验，用户登录后拿到token，每次请求在header里带上Authorization: Bearer <token>，后端解析token得到用户ID和角色列表。权限校验用@PreAuthorize("hasAnyRole('ADMIN', 'MANAGER')")这样的注解挂在Controller方法上，清晰又灵活。

3.2 核心代码：房态查询与预订校验的实现

我直接给出一段带注释的预订校验代码，这是整个系统里逻辑最核心的地方。它的目的是：在接收订单请求后，在数据库层面做一次原子性的校验和插入。

java复制/**
 * 预订校验与房间锁定
 * 返回true表示预订成功, false表示该时间段房源不足
 */
@Transactional(rollbackFor = Exception.class)
public boolean createOrder(OrderCreateDTO dto) {
    // 1. 查询目标房型总量
    RoomType roomType = roomTypeMapper.selectById(dto.getRoomTypeId());
    if (roomType == null) {
        throw new BizException("房型不存在");
    }

    // 2. 计算目标日期段内每天已占用的房间数
    LocalDate startDate = dto.getStartDate();
    LocalDate endDate = dto.getEndDate();
    long totalDays = ChronoUnit.DAYS.between(startDate, endDate);

    List<LocalDate> dateList = new ArrayList<>();
    for (int i = 0; i < totalDays; i++) {
        dateList.add(startDate.plusDays(i));
    }

    // 3. 批量查询每天已被占用的房间ID
    // 注意: 这里必须批量查, 不能循环单查, 否则性能会很差
    List<RoomOccupancyDTO> occupiedCount = roomOccupancyMapper
            .countOccupiedRooms(dto.getRoomTypeId(), dateList);

    // 4. 将占用统计装成 map: date -> count
    Map<LocalDate, Long> occupiedMap = occupiedCount.stream()
            .collect(Collectors.toMap(
                RoomOccupancyDTO::getStayDate,
                RoomOccupancyDTO::getCnt
            ));

    // 5. 判断每一天是否有余量
    for (LocalDate date : dateList) {
        long occupied = occupiedMap.getOrDefault(date, 0L);
        if (occupied >= roomType.getRoomCount()) {
            throw new BizException("该房型在 " + date + " 已满房");
        }
    }

    // 6. 生成订单主表记录
    Order order = new Order();
    order.setOrderNo(generateOrderNo());
    order.setUserId(dto.getUserId());
    order.setOrderStatus(1);
    // ... 省略其他字段赋值

    orderMapper.insert(order);

    // 7. 根据剩余房间, 选择一个具体可用的房间, 插入订单明细
    Room availableRoom = roomMapper.selectAvailableRoom(
        dto.getRoomTypeId(), dateList);
    if (availableRoom == null) {
        throw new BizException("无可用房间, 请刷新后重试");
    }

    for (LocalDate date : dateList) {
        OrderDetail detail = new OrderDetail();
        detail.setOrderId(order.getId());
        detail.setRoomId(availableRoom.getId());
        detail.setRoomTypeId(dto.getRoomTypeId());
        detail.setStayDate(date);
        detail.setPrice(roomType.getPrice());
        detail.setSettleStatus(0);
        orderDetailMapper.insert(detail);
    }

    return true;
}

我写这段代码时踩过一个坑：最开始第7步是"随便拿一间可用房间"，但并发情况下可能出现A订单拿到房间101，B订单也拿到房间101的情况。虽然订单明细表的唯一索引能挡住B的插入，但B会报错"数据库唯一约束冲突"，而不是清晰的业务提示。所以后来我改成了selectAvailableRoom里用FOR UPDATE SKIP LOCKED语法锁定房间行，确保同一时间只有一个订单能拿到同一间房。

另外特别注意第2步到第5步的算法设计。因为订单明细是按天拆分的，所以可用性判断必须逐天进行。有的同学会踩这样的坑：只判断了"入住当天"有没有房，结果客人连住三天，第二三天其实已经订完了，到了第二天才发现问题。这个逐天校验的逻辑看起来繁琐，但它是必须的。

3.3 前端页面与接口联调要点

前端部分我用的是Vue 2 + Vue Router + Vuex + Axios，UI框架选Element UI。页面上主要有这几个核心视图：

登录页：用户名密码 + 验证码，登录后存储token到localStorage
房态总览页：用一张可视化的房态图展示所有房间的当前状态，不同颜色代表不同状态，点击房间可以快速办理入住或查看详情
订单管理页：列表展示所有订单，支持按状态筛选、详情查看、取消操作
入住登记页：支持通过身份证号快速查询预订信息，办理入住
报表统计页：用ECharts画入住率趋势图、营收柱状图等

接口联调时有一个非常实用的技巧：用Axios的拦截器统一处理token和异常。我在request.js里定义了一个axios实例，请求拦截器里从localStorage拿token放到header，响应拦截器里统一判断HTTP状态码，如果401就跳转登录页，如果业务异常就弹出this.$message.error(msg)。这样每个页面组件里只需要关心业务逻辑，不用重复写错误处理代码。

前端联调过程中最常遇到的问题就是跨域。解决方式是在后端加一个CORS配置类：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

细心的同学可能会注意到allowedOriginPatterns而不是allowedOrigins，这是SpringBoot 2.4之后版本的一个变化。如果继续用allowedOrigins("*")配合allowCredentials(true)，会出现"无法通过CORS策略访问"的报错，这是很经典的兼容性坑。

3.4 SpringBoot打包部署与测试验证

项目开发完成后，打包部署是毕业设计答辩前的最后一道坎。SpringBoot的打包很简单，用Maven的package命令就能打出可执行的Jar包。但有几个细节要注意：

第一，配置文件分环境。我的做法是维护三个配置文件：application-dev.yml（本地开发）、application-test.yml（测试环境）、application-prod.yml（生产环境）。用spring.profiles.active=prod来切换。这样做的好处是，数据库密码、日志级别这些配置不会因为环境切换而写错。

第二，打包时排除测试。如果项目里有单元测试，直接mvn package会把测试跑一遍，如果测试失败就打包失败。毕业设计赶时间的时候，我在pom.xml里配置了：

xml复制<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin>

这里skip=true跳过的是测试执行，不是测试编译，能省不少时间。

第三，Jar包部署后的资源路径问题。SpringBoot的Jar包内资源路径和开发环境不同，如果静态资源放在static目录下，部署后访问路径可能会变化。最稳妥的方式是不要依赖文件系统的绝对路径，而是用ClassPathResource去加载资源，或者把上传的图片存到服务器独立目录，通过配置映射来访问。

部署完成后，我习惯用curl做一轮冒烟测试，验证核心接口是否正常：

bash复制# 登录获取token
curl -X POST http://localhost:8080/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"123456"}'

# 携带token查询房态
curl -X GET http://localhost:8080/api/room/status \
  -H "Authorization: Bearer <你的token>"

如果这两步都通过，基本说明系统启动成功、数据库连接正常、认证流程没问题。

4. 常见问题排查与开发避坑指南

4.1 SpringBoot版本选择与JDK兼容性

这是我在帮学弟学妹改代码时遇到最多的问题：新建项目时直接选了SpringBoot最新版（比如3.x），然后发现各种依赖怎么都导不进来，或者启动就报Unsupported class file major version。

这里必须强调一下版本矩阵的坑。SpringBoot 2.x是基于JDK 8的，也是绝大多数教程、开源项目默认的版本。SpringBoot 3.x则要求JDK 17以上，而且底层做了一次大换血——javax.*包全部改成了jakarta.*，很多老依赖（比如mybatis-plus-boot-starter的早期版本）在SpringBoot 3下会出现兼容性错误。

所以我给这个项目定的版本是SpringBoot 2.7.18。这个版本是2.x系列的最后一个版本，bug修得最彻底，同时兼容JDK 8，各种第三方组件适配也很成熟。如果是自己练手或做毕设，不要盲目追求新版本，稳定能用才是第一位的。

如果确实想用JDK 17 + SpringBoot 3，那必须确认以下三个依赖的版本：

mybatis-plus-boot-starter至少3.5.3+
mysql-connector-java要改成com.mysql:mysql-connector-j，而且8.0.31以上
代码里所有javax.servlet.*、javax.persistence.*的import要改成jakarta.*

这些坑我全部踩过一遍，每一条都是真金白银的时间换来的教训。

4.2 SpringBoot事务失效的经典场景

事务管理是SpringBoot中一个"看起来简单、用起来全是坑"的知识点。我在这个项目里至少有两次遇到事务没生效的问题，排查了很久才找到原因。

第一个场景是方法内部调用导致事务失效。我在一个Service里写了一个公开方法createOrder()，它内部调用了另一个方法generateOrderNo()，这个生成单号的方法加了@Transactional注解，想着如果生成失败就回滚。但实际上Spring的事务是基于AOP代理实现的，只有通过代理对象调用方法时，事务才会生效。方法内部this.generateOrderNo()是直接调用this对象的方法，根本不经过代理，所以注解完全没用。

正确的做法是：把内部调用改成注入自身的代理对象，或者把generateOrderNo()拆到独立的Service类里，再注入调用。

第二个场景是异常被捕获导致不回滚。Spring默认情况下，只有RuntimeException和Error会触发回滚，而受检异常（Checked Exception）默认不会回滚。如果业务代码里写了try-catch把异常吞掉了，那事务自然也不会回滚。

解决方式是使用@Transactional(rollbackFor = Exception.class)显式指定回滚条件。我在createOrder方法上就是这么写的，代价是性能上有一点点影响，但换来了数据的绝对一致性，这笔账怎么算都划算。

4.3 日期时间处理与跨日问题

酒店业务的日期处理有个特殊性：结算周期与自然日不完全重叠。客人入住的时间可能跨两天，订单的日期计算必须准确到天甚至小时。我用的是Java 8的LocalDate和LocalDateTime，配合MySQL的DATE和DATETIME类型。这里有一个序列化的坑，前端传接收到的日期如果是ISO字符串，后端要用@JsonFormat注解指定格式：

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private LocalDateTime createTime;

时区问题也要特别注意。如果服务器时间用的UTC，而数据库存储的是北京时间，查询出来的时间会差8小时。我是在application.yml里统一设置了：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

跨日场景在延住（续订）时最容易出问题。比如一个订单原计划6月10日退房，客人想延住到6月12日。此时系统要自动生成6月11日夜间的订单明细，并且要保证这段时间房间未被其他预订占用。如果只更新了订单结束日期而没有同步插入订单明细，房态图就显示不出这个房间已经被占了，后续并发预订就会撞车。所以延住的实现逻辑我封装成了独立的方法：先锁房、再补明细、再改主订单状态，三步在一个事务里完成。

4.4 MyBatis-Plus使用心得：从CRUD到复杂查询

MyBatis-Plus是我在这类管理系统中非常推荐使用的ORM框架。它把单表CRUD几乎全部封装好了，BaseMapper里的selectById、selectList、insert、updateById等方法直接能用，连SQL都不用写。

但它也有一个很坑的地方：默认的字段映射策略。MyBatis-Plus默认会把Java类里的驼峰字段映射成数据库的下划线字段，比如createTime对应create_time。这个策略默认开启，所以没问题。但如果你有某个字段不想映射，比如实体里加了一个非数据库字段，必须在字段上标@TableField(exist = false)，否则MyBatis-Plus会把它当成数据库字段去查询，直接报"Unknown column"。

复杂查询方面，我推荐用法是MyBatis-Plus的Wrapper和自定义SQL结合。简单的条件查询用LambdaQueryWrapper就够了，比如：

java复制List<Order> orders = orderMapper.selectList(
    new LambdaQueryWrapper<Order>()
        .eq(Order::getUserId, userId)
        .eq(Order::getOrderStatus, 1)
        .orderByDesc(Order::getCreateTime)
);

但如果是多表关联的复杂统计，比如"查询每个房型近7天的入住率"，这种必须写自定义SQL。我的习惯是把这些统计SQL写在Mapper接口里，用@Select注解直接标注，或者使用XML文件。前者的好处是直观，适合SQL不长的场景；后者更适合复杂的动态SQL。

这里提一个统计时容易犯的错：分组统计前必须考虑空值。比如"统计各房型订单数"，如果某个房型没有任何订单，GROUP BY结果里根本不会出现这个房型的记录，前端展示的时候就少了一行。解决方式是业务层先查出所有房型列表，再遍历去map里取值，取不到就补0。

4.5 前端联调中的常见Bug与排查方法

前后端分离开发时，前端报错是常态，但很多错误其实有固定的排查路径。我总结一下这个项目里遇到最多的几个问题。

跨域问题（CORS）：前端控制台报Access to XMLHttpRequest at ... has been blocked by CORS policy。优先检查后端是否加了CORS配置，以及配置里的allowedOriginPatterns是否匹配前端地址。不要为了省事直接禁用浏览器安全策略，那是饮鸩止渴。

请求404或405：404说明后端没有找到对应路径，检查Controller里的@RequestMapping路径是不是写错了；405说明路径对了但请求方式不对，比如后端定义的是@PostMapping，前端却用了GET请求。我用IDEA打开后端的端点面板（http://localhost:8080/actuator/mappings），可以直接看到所有已注册的接口路径和方法，排查起来非常快。

接口返回值是"timeout"或"network error"：这种问题一般不一定是前端问题。先检查后端控制台有没有异常日志，再看数据库的连接池是不是满了。我之前遇到过MySQL连接数被打满导致接口无响应的情况，后来在配置里加了一个连接池上限和等待超时时间：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      connection-timeout: 3000

数据渲染不出来但接口返回正常：这种情况大概率是前端数据路径写错了，比如接口返回的是{code: 200, data: {list: []}}，但你在Vue里取了res.data.rows。建议统一封装Axios响应拦截器，把真正有效的数据结构固定下来，所有页面都按同一套约定取值。

4.6 单元测试与接口自测的实操经验

毕业设计答辩时，评委老师经常会问"你这个项目测试过吗？怎么测试的？"如果回答"用Postman调过"，虽然不算错，但如果有几个正经的单元测试，会更有说服力。

我在项目中写了两个核心测试类。第一个是订单服务的业务测试，用@SpringBootTest启动整个Spring容器，然后在测试方法里构造一个预订请求，断言数据库里能查到订单和明细记录：

java复制@SpringBootTest
@Transactional
class OrderServiceTest {

    @Autowired
    private OrderService orderService;

    @Test
    void createOrder_shouldInsertOrderAndDetails() {
        OrderCreateDTO dto = new OrderCreateDTO();
        dto.setRoomTypeId(1L);
        dto.setStartDate(LocalDate.now().plusDays(1));
        dto.setEndDate(LocalDate.now().plusDays(3));
        dto.setUserId(100L);

        boolean result = orderService.createOrder(dto);
        assertTrue(result);

        List<Order> orders = orderService.listByUserId(100L);
        assertEquals(1, orders.size());
    }
}

注意这里加了@Transactional注解，目的是测试结束后自动回滚，避免污染数据库。这个技巧非常实用，保证测试可以反复跑，而且不会留下脏数据。

第二个是并发控制的测试，验证两个线程同时预订同一房间时只有一个能成功：

java复制@Test
void createOrder_concurrentBooking_shouldOnlyOneSucceed() throws Exception {
    int threadCount = 2;
    ExecutorService executor = Executors.newFixedThreadPool(threadCount);
    CountDownLatch latch = new CountDownLatch(threadCount);
    AtomicInteger successCount = new AtomicInteger();

    for (int i = 0; i < threadCount; i++) {
        executor.submit(() -> {
            try {
                OrderCreateDTO dto = new OrderCreateDTO();
                // ... 构造相同的预订参数
                boolean success = orderService.createOrder(dto);
                if (success) {
                    successCount.incrementAndGet();
                }
            } finally {
                latch.countDown();
            }
        });
    }
    latch.await();
    assertEquals(1, successCount.get());
}

这个测试跑通的意义在于：它证明你的系统在并发场景下数据是安全的，而不仅仅是"功能能跑"。我当时在答辩现场演示这段测试的时候，评委老师明显比较认可，因为大多数毕设项目根本不会考虑并发问题，更不会去验证。

5. 从毕设到生产：项目扩展方向与经验沉淀

做毕设这件事，我以前总觉得自己是在"交作业"，但等真的把四季来酒店管理系统从头到尾做完，回头再看，其实是把一个完整业务链路的技术实现走了一遍。如果后续你想把它当作一个作品展示或者继续打磨，这里有三个我推荐的扩展方向。

第一个方向是接入真实支付。目前系统的支付方式只是简单地记录一个"已支付"状态，并没有真正对接微信或支付宝。你可以用支付宝的沙箱环境或者微信支付的测试商户号，把支付流程跑通。这样系统就从"内部管理工具"升级为"可实际运营的平台"，技术含量瞬间提升一个档次。支付回调这块还可以顺便练一练接口签名、幂等处理、异步通知这些偏工程化的能力，都是面试时的高频考点。

第二个方向是补充算法或报表能力。酒店行业的营收管理很大一部分靠数据分析，比如"节假日房价动态调整""入住率预测""客户价值分层"。你可以引入定时任务框架，每天凌晨跑一次统计任务，把经营指标写入汇总表，前端展示趋势图。如果觉得纯统计不够技术含量，还可以加入简单的预测模型——用户复购概率、房型偏好推荐等，用前端的ECharts画出来，答辩的时候能讲的东西就更多了。

第三个方向是完善权限与操作审计。现在系统的权限是RBAC模型，粒度到角色。如果你愿意继续深挖，可以加上"数据权限"的概念——比如经理只能看到自己门店的数据，集团管理员才能跨店查看。操作日志方面，目前只是简单记录了操作类型和时间，你可以接入一些脱敏存储和异常告警机制，让系统更接近企业级的技术标准。

最后说一下这个项目对我个人的经验积累。从一个只会在教程里跑Demo的小白，到能独立设计数据库表结构、处理并发冲突、封装统一返回体、部署上线，这个过程最大的收获不是记住了SpringBoot的某个注解，而是建立起了一套"从业务需求到代码落地"的思考框架。遇到问题时先拆解问题本质，再想技术方案，而不是拿到需求就急着写代码。这种思维方式，在做任何一个系统的时候都用得上。

如果你正准备做类似的酒店管理系统，或者任何SpringBoot相关的业务系统，希望这篇博客能帮你少走几步弯路。也建议你动手把表结构建出来，把核心的几个流程（预订、入住、退房）自己走一遍——写代码这件事，光看是没有用的，自己踩过坑，才真正长在自己身上。

SpringBoot酒店管理系统核心设计与实战解析