Spring Boot酒店管理系统设计：从表结构到并发预订防超卖

每年毕业设计选题季，“springboot酒店管理系统”几乎是最不缺人的一个题目。你去开源社区搜一下，光带完整源码的项目就有上百个，但真正的难点从来不是“找不到代码”，而是拿到一套代码之后，你有没有能力讲清楚表为什么这么建、接口为什么这么写、遇到并发预订时怎么保证不超卖。这篇内容我想从一个带过多个毕业设计的过来人角度，把酒店管理系统的核心设计、Spring Boot后端实现和最容易翻车的细节一次性讲透，无论是只求能跑通答辩，还是想认真做点增量，都应该能从中拿到一些可以直接抄走的东西。

1. 先想清楚：酒店管理系统到底要管什么

很多人做毕设的第一步就是打开IDE、新建Spring Boot项目，结果没写几天就把自己绕晕了——不是代码不会写，而是根本不知道系统要管哪些数据、业务怎么流转。所以先从理清边界开始。

1.1 为什么这个题目是Spring Boot毕设的“万金油”

酒店管理系统的热度不是没道理，它有点像“小型的进销存系统”，有明确的实体对象，客户、房间、订单、账单，也有完整的状态流转，空闲、预订、入住、退房、清扫。一个基础版系统能把需求分析、数据库设计、后端接口、前端页面这些毕业设计硬指标全带起来，而且难度可控。不像电商系统那样涉及复杂的促销、库存、支付回调，也不像纯OA系统那样逻辑松散，酒店系统业务链路天然清晰，适合用来呈现你掌握Spring Boot的程度。

从技术角度讲，Spring Boot也非常适合这个项目。它内嵌Tomcat，不用单独配置服务器；起步依赖把Spring MVC、JSON序列化、参数校验、日志等东西都集成了，可以让开发者把精力集中到业务本身。同时它的“自动配置”特性也给了答辩一个很好的问点：为什么引入spring-boot-starter-web就能跑接口？因为Spring Boot在spring.factories或AutoConfiguration.imports里注册了一堆自动配置类，根据classpath里的依赖和属性配置来决定要不要创建对应的Bean。这个概念能做深也能做浅，很适合拿来回答“请介绍一下Spring Boot的原理”这类问题。

1.2 功能模块怎么划分才不会把自己卷死

我见过太多学生一上来就想做“全功能酒店管理平台”，结果会员、秒杀、优惠券、多门店、权限管理五个模块全做完，最后答辩前数据库乱了、页面也崩了。毕设不是商业项目，功能不是越多越好，而是要把一条核心业务主链走通。

建议分成三层去看：

• 基础版：用户登录、员工管理、房间类型管理、房间管理、客房预订、入住登记、退房结账、预订记录查询。
• 进阶版：在基础版上加客户管理、房态修改、退款功能、操作日志、简单的统计报表。
• 加分版：前台首页显示可订房型、日历预订、价格随日期波动、数据可视化看板、过期订单自动关闭、Docker一键部署。

基础版已经能覆盖大部分学校的查重要求，进阶版能让论文“业务模块”部分更有内容，加分版则适合那些希望在答辩时展示亮点的同学。每个层级之间是增量关系，别一开始就把所有功能塞进表结构里。

1.3 技术选型：一套不容易踩坑的组合

如果你没有特殊要求，直接照下面这套组合用：

这里我要特别强调一下版本问题。现在Spring Boot 3.x已经普及，但如果你还没有完全搞明白javax和jakarta命名空间的区别，也不熟悉Spring Security 6的新写法，我强烈建议毕设还是用Spring Boot 2.7系列。很多教程、开源项目都是基于2.x写的，按着能跑通，一旦选了3.x，你搜到的大部分老代码都会有兼容性问题。除非导师明确要求“必须用Spring Boot 3”，否则别给自己增加不必要的排错成本。

2. 表结构设计：不要让状态字段变成“薛定谔的房间”

数据库设计是酒店管理系统最核心的部分，因为它直接决定了后端接口好不好写、数据会不会乱。如果你连表的字段都没想清楚就开始建库，后面大概率要翻工。

2.1 核心表应该从业务闭环倒推，而不是从菜单抄

设计表之前，先在纸上画一遍业务流转：客人从前台或电话发起订房，系统先查有没有可用的房间，然后生成预订记录；客人到店后办理入住，系统把预订状态改成已入住并分配房间；住店期间可能会有商品消费、加床、续住等操作；退房时系统结算房费和其他消费，生成账单，同时把房间改成“待打扫”状态；保洁完成后，房间恢复“空闲”，又可以进入下一轮预订。

这个流程里隐藏了六张核心业务表：

• 房间类型表room_type：房型名称、面积、床型、挂牌价、可住人数、图片。
• 房间表room：房间编号、楼层、所属房型、状态。
• 客户表customer：散客/会员信息，姓名、手机号、证件号。
• 预订单表reservation：预订人、联系方式、房型/房间、预计入住退房时间、状态。
• 入住单表checkin：实际入住客人、房间、入住时间、应退时间、实际退房时间、状态。
• 账单表/订单流水表bill：入住单ID、费用项、金额、支付时间、支付方式。

另外还要有系统管理相关的表：用户表、角色表、菜单权限表。如果要做员工登录和操作日志，这些表的优先级也很高。

不要试图把所有信息塞进一张大表。比如预订、入住、账单如果全放在order表里，用状态字段区分，前期写起来快，后面统计“本月实际出租间夜数”时，你会发现过滤条件根本写不干净。

2.2 房态状态机：别让房间被改成一个无解的状态

房间状态最忌讳用字符串随便存，比如“vacant”“locked”“已住”，换个人写代码可能又变成“已预订”“空闲中”，数据很快就没人看得懂。建议统一用tinyint定义状态，并在代码里做成常量或枚举：

• 0：空闲，可预订。
• 1：已预订，在预订时间范围内被锁定，不能办理入住。
• 2：已入住，房间正在使用。
• 3：待清扫，客人已经退房，但保洁还未确认。
• 4：维修中，房内有设施问题，不能售卖。

状态流转必须符合业务逻辑。正常情况下，房间只能按 0 → 1 → 2 → 3 → 0 循环，特殊情况才会走到4。具体到代码实现，不要让每个Controller想改状态就改状态，而是要经过对应的业务方法，比如checkIn()、checkOut()、cleanRoom()，方法内部先做状态校验，校验通过再更新数据库。这样即使以后加了更多入口，状态也不会被无脑覆盖。

我见过不少项目在退房时漏了“房间状态改为待清扫”，导致客人刚退房，这个房间又能被预订出去，而数据库里其实还有一堆未整理的床单。房态机这种事，必须退房和清扫两段都走到，系统才敢把它标记为空闲。

2.3 预订单和入住单要不要分两张表

这是很多同学容易纠结的地方。我的建议是：要分。

预订单表达的是“未来可能发生的入住”，它不一定真实发生，客人可能不来、可能取消、也可能改期。入住单表达的是“客人已经实际到店并占用房间”，它才对应真实的客房收入和保洁周期。如果合在一起，就会出现“预订成功后算不算已经卖出房间”的争议，也会导致退房和取消的逻辑纠缠不清。

各自字段可以这样设计：

• reservation表：id、order_no、customer_name、customer_phone、room_type_id或room_id、expected_check_in、expected_check_out、status、remark。
• checkin表：id、reservation_id、customer_name、customer_phone、room_id、actual_check_in、expected_check_out、actual_check_out、is_settled、status。

预订后如果客人到店，后端就根据预订单生成一条入住记录，同时把预订单状态置为“已入住”，把房间状态置为“已入住”。退房后产生的费用则写入账单表。这样每张表职责单一，论文里写数据字典时也更好看。

2.4 金额、日期和删除标记的细节不要偷懒

金额字段必须用DECIMAL(10,2)，不要图省事用FLOAT或DOUBLE。二进制浮点数无法精确表达十进制小数，房费计算、折扣后金额、找零这些场景一旦出现精度误差，答辩现场演示时非常尴尬。日期时间字段建议直接用datetime或Java里的LocalDateTime，存入值要统一好时区，连接串里设置serverTimezone=Asia/Shanghai，避免部署到别的电脑上时间差8小时。

还有，业务表最好都带一个逻辑删除字段，比如deleted，默认0，删除时置1。像客户、预订记录这些数据，物理删除后不但不好恢复，而且会让“已退房客人历史记录”丢失。到了论文里写“本系统采用逻辑删除，保证数据可追溯性”，这也是一句能加印象分的描述。

3. 后端实现：从工程结构到核心接口一次通

数据库设计好了，Spring Boot后端写起来就像填格子。但工程结构、统一返回、权限校验、事务控制这些东西，决定了你的代码是“能跑”还是“经得起问”。

3.1 工程目录建议：按业务分层，别把代码全写进Controller

推荐一个比较清晰的包结构：

code复制com.example.hotel
├── common          // 统一返回、异常、常量、状态枚举
├── config          // 拦截器、WebMvc配置、Cors配置
├── controller      // 接口层
├── entity          // 数据库实体
├── mapper          // MyBatis-Plus Mapper接口
├── service         // 业务接口和实现
├── dto             // 入参对象
├── vo              // 出参对象
└── utils           // JWT工具类、日期工具类

Controller里不要写复杂业务，只做参数接收、简单校验、调用Service返回结果。Service负责业务规则。这样答辩时老师问“业务逻辑在哪里”，你能直接指给TA看，而且日后再改也好维护。

接口统一返回结构非常重要。我的习惯是写一个Result<T>类，提供Result.ok(data)和Result.error(code, msg)静态方法：

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> ok(T data) {
        Result<T> r = new Result<>();
        r.code = 200;
        r.message = "success";
        r.data = data;
        return r;
    }

    public static <T> Result<T> error(Integer code, String msg) {
        Result<T> r = new Result<>();
        r.code = code;
        r.message = msg;
        return r;
    }
}

再配一个@RestControllerAdvice全局异常处理器接口，把业务异常、参数校验异常、未知异常统一转成Result结构。前端对接时只认一种JSON格式，联调效率会高很多。

3.2 权限控制：用JWT加拦截器，别一上来就盲目Security

酒店管理系统一般会有普通前台和管理员两种角色。如果每天每个接口都能被任何人直接调用，答辩时基本会被问穿。但Spring Security配置复杂，对于只需要登录拦截的项目，用JWT加拦截器反而更容易讲清楚。

登录接口流程是这样的：用户提交用户名密码，后端校验用户是否存在、密码是否一致，创建token并返回。token里只放用户id、用户名、角色等必要信息，加上过期时间。前端后续请求在header里带Authorization: Bearer token，后端通过拦截器解析token，未登录或过期就返回401。

拦截器注册代码示例：

java复制@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(jwtInterceptor)
            .addPathPatterns("/**")
            .excludePathPatterns(
                "/user/login",
                "/user/register",
                "/doc.html",
                "/swagger-ui/**",
                "/swagger-resources/**",
                "/v3/api-docs/**",
                "/webjars/**"
            );
}

有一个细节要注意：JWT本身是无状态的，服务器不保存token，所以“退出登录”并不能真正让token失效。毕设阶段解决办法很简单，token过期时间不要设太长，比如8小时；想更严谨一点，就用Redis存一个“在线token白名单”，用户退出时删除。如果答辩问起来，能说出这个思路就足够。

3.3 MyBatis-Plus配置与复杂SQL的使用边界

单表增删改查可以用MyBatis-Plus的BaseMapper，能少写大量XML。但“查可订房列表”“统计每日营业额”这种查询必然会涉及多表关联，此时还是要自己写SQL。

建议在application.yml里加上SQL日志：

yaml复制mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

这样每次执行SQL都能在控制台看到完整语句，排查问题会轻松不少。

以“根据时间段查可订房间”为例，可以写一个自定义Mapper方法：

sql复制SELECT r.id, r.room_no, rt.name AS room_type_name,
       rt.price, r.floor
FROM room r
LEFT JOIN room_type rt ON r.room_type_id = rt.id
WHERE r.status = 0
  AND r.id NOT IN (
      SELECT c.room_id FROM checkin c
      WHERE c.status IN (0, 1)
        AND (#{startTime} < c.expected_check_out AND #{endTime} > c.actual_check_in)
  )

注意这里跨天入住、钟点房、续住等情况会非常复杂，毕设不用追求完美，但只要把“预订时间区间与已入住区间重叠”的判断写对，就能覆盖绝大多数场景。

3.4 预订和退房这两个核心Service要把握事务

预订房间的接口是最容易出并发问题的。两个前台同时让同一个房间预订同一晚，如果程序只做“查状态→判断可订→插入记录”，就可能在并发时把同一间房卖出去两次。解决方法有很多，毕业设计里比较实用的是在事务里用数据库行锁，先对房间记录加锁，再查状态、再下单：

java复制@Transactional(rollbackFor = Exception.class)
public Long createReservation(ReservationDTO dto) {
    Room room = roomMapper.selectRoomForUpdate(dto.getRoomId()); // select ... for update
    if (room == null || !room.getStatus().equals(RoomStatus.FREE)) {
        throw new BusinessException(500, "该房间暂不可预订");
    }
    // 校验所选日期段内无冲突订单
    // 插入预订单
    // 把房间状态改为“已预订”
    return reservation.getId();
}

select ... for update是数据库层级的悲观锁，虽然后续并发性能不高，但应对毕设展示完全够用，而且面试官能理解，实际项目才会考虑乐观锁或异步削峰。这里的关键不只在于锁，还在于所有数据修改必须在同一个事务里完成。如果插入订单成功但修改房间状态失败，事务回滚，数据才是一致的。

退房结账也是同理。退房时要做四件事：计算房费、汇总住客消费、把费用插入账单、把入住单置为已结算、把房间状态改为待清扫。这四步必须包在同一个事务里，否则可能出现钱算了但房间还是已入住的情况。

3.5 日期格式、跨域、开发期热部署这几个小事提前配好

后端接口返回LocalDateTime时，默认可能是一个数组格式，前端非常难受。在application.yml里统一配置一下格式：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

如果做的是前后端分离项目，还要配置跨域。最简单的方案是写一个CorsFilter，允许的前端地址根据你实际启动的端口填写，不要图省事直接*，否则携带token的请求还是会有问题。

开发阶段建议加上spring-boot-devtools，改完代码自动重启，能节省不少时间。还可以放一个自定义Banner，网上有很多“springboot banner在线生成器”，把文本图片打出来虽然不一定加功能分，但至少显得你熟悉这些周边生态。

4. 高频问题与排查技巧：照着这张表自查

Spring Boot项目在开发中报错是常态，真正烦人的是那种一报错就懵、不知道从哪下手的情况。这一节我把学生最容易踩的问题整理成速查表。

4.1 版本不一致：为什么别人能启动你却启动不了

Spring Boot版本的兼容性问题排第一。很多同学不愿意用2.7.18，非要下载最新3.x，然后项目一启动就报Failed to instantiate或ClassNotFoundException，搜解决方案时老代码里全是javax.servlet，你项目里却全是jakarta.servlet，越改越乱。

建议：新建项目时选择一个稳定的版本。现在多数教程和开源毕设代码还在2.7时代，如果你没有太多年级压力，也不必强行追赶最新版本。同理，MyBatis-Plus要用适配Spring Boot 2.7的版本，Druid连接池、Redis依赖等也要注意配套，不要所有依赖闭眼写latest。

还有一种经典报错是Spring Boot版本高于2.4后，spring.factories自动配置文件被拆分到META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，如果你自己写自定义starter会发现找不到配置。不过毕设一般不会碰到这一点，了解即可。

4.2 数据库连接报错：时区、SSL、驱动一个都不能少

最典型的报错就是Access denied for user、Could not create connection to database server、The server time zone value ... is unrecognized。其实大部分都是连接串参数和驱动问题。

一个稳妥的MySQL 8连接串长这样：

code复制jdbc:mysql://localhost:3306/hotel?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval这个参数在MySQL 8.0.30以后经常需要，不加会报Public Key Retrieval is not allowed。驱动类建议配置成com.mysql.cj.jdbc.Driver，数据库版本如果是5.7也能兼容。

4.3 Mapper接口扫描不到：总是报无效绑定

Invalid bound statement (not found)通常是两种原因：一是启动类没有加@MapperScan，二是XML文件没被打包到target目录。判断方法很简单，先看控制台是否打印了“Building JPA repository”或“MapperFactoryBean”，再看target/classes/mapper下有没有对应的XML。

如果XML放在src/main/java里，需要在pom.xml里加资源目录配置，否则Maven默认不会把java目录下的XML拷过去。我个人的习惯是XML统一放到src/main/resources/mapper，并在application.yml里配置mybatis-plus.mapper-locations: classpath*:mapper/**/*.xml，这样结构最清晰。

4.4 接口响应变成500，日志里却没有业务异常

这种情况多半是代码里抛出的自定义异常被Spring默认处理成了500。如果你已经写了全局异常处理器，一定要确认处理器是否捕获了Exception，并且异常类是否被Spring扫描到。最省事的做法是把全局异常类放在启动类所在包的子包下，并用@RestControllerAdvice注解。

还有一个我在实际指导中反复看到的低级错误：Controller方法里返回的是Result，但方法没有加@ResponseBody，或者类上用的是@Controller而不是@RestController。前端拿到的不是JSON，而是错误页面模板内容，看起来像“又报错了”，其实是返回类型没配对。

4.5 常见问题速查表

5. 让系统从“能跑”变成“好答辩”的三个小亮点

很多同学到了后期都会问同一个问题：我的系统就是一个普通CRUD，怎么让答辩显得更有水平？我的建议是不要临时堆功能，而是在现有核心链路基础上做三个性价比最高的小改进。

5.1 加一个经营数据看板：一张图顶十句话

酒店管理系统最不缺的就是数据，每天的订单量、房价收入、入住率、退房数，天然适合可视化。你可以提供一个统计接口，按天/按月查询订房数量和营业额，再在管理后台首页用ECharts柱状图或折线图展示。

实现的难点不在前端图表，而在SQL统计。比如“近30天入住率”可以按天分组查询：

sql复制SELECT DATE_FORMAT(actual_check_in, '%Y-%m-%d') AS date,
       COUNT(DISTINCT id) AS checkin_count
FROM checkin
WHERE actual_check_in BETWEEN #{startDate} AND #{endDate}
GROUP BY DATE_FORMAT(actual_check_in, '%Y-%m-%d')

日期没有订单的那几天会是空档，如果用图表展示会有断点，建议后端把连续日期补零。这个细节做好了，论文“系统测试”部分能直接给出带图表的截图，比纯文字表格有说服力得多。

5.2 实现“预订超时未确认自动取消”：会让系统真实一点

酒店预订通常有保留时限，如果客人预订了但迟迟不到店，房间不能一直锁着。给预订单加一个“创建时间”和“最后确认时间”字段，再写一个定时任务，每5分钟扫描一次超过保留时限且状态为“已预订”的订单，自动将其置为“已取消”，并把房间状态恢复成“空闲”。

Spring Boot做定时任务非常简单，在启动类或配置类上加@EnableScheduling，然后在方法上加@Scheduled(fixedDelay = 300000)即可。这一功能不依赖额外组件，代码量不大，但能明显体现出你对业务细节的理解。

很多同学会问，为什么不直接上RabbitMQ延迟队列或者Redis过期监听？不反对，但如果只是“定时扫描未支付状态”，用MQ属于过度设计。答辩时被问到“为什么不用延迟消息”，你能回答“第一，当前系统并发量没有高到需要消息中间件异步处理；第二，定时任务足够满足酒店预订的低频业务”，这个答案反而比硬装技术更有说服力。

5.3 用Docker Compose一键启动演示环境

毕设最尴尬的事情之一，就是答辩现场环境坏了。今天数据库密码忘了，明天Redis连不上，后天对方电脑上没有MySQL。如果你能把项目打包成Docker镜像，再用一个docker-compose.yml把MySQL和应用服务一起起起来，现场演示只需要装一个Docker Desktop。

一个基础Spring Boot项目的Dockerfile可以这样写：

dockerfile复制FROM maven:3.8.6-jdk-8 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn clean package -DskipTests

FROM openjdk:8-jre-alpine
COPY --from=build /app/target/hotel.jar /hotel.jar
ENTRYPOINT ["java", "-jar", "/hotel.jar"]

再用docker-compose把MySQL也定义进去，数据库初始化脚本挂载到/docker-entrypoint-initdb.d/，应用启动时通过环境变量连接MySQL。这样同一套环境能复制到任何电脑。不过这个属于加分项，如果你的基础还不够稳，可以先把它当成一个后期的小目标，别在项目初期就被Docker困住。

如果你真的想加入更重一点的中间件，比如用Flowable做审批流、用RabbitMQ做消息通知，我会建议先问自己三个问题：这个能力是否真的被酒店业务流程需要？你能否在十分钟内讲清楚它解决的问题？如果老师追问它内部原理，你是否接得住？如果有一个答案是否定的，那就不如不要加。毕设说到底不是代码越炫越好，而是逻辑越自洽越好。

我个人带毕设时最怕看到的一种情况，是学生把代码跑通就以为万事大吉，等到答辩现场被老师问了一句“你这里为什么要用Redis”就卡住了。所以如果你正在做这个题目，请一定不要只停留在“把接口调通”这一步，而是要拿着核心流程，从数据库表开始，一条一条链路过一遍。比如客人订房时，从打开页面到最终账单生成，中间经过了哪些接口、哪些表、哪些状态变化，每一步都吃透了，毕业设计答辩就真的稳了。