Spring Boot酒店管理系统：从自动装配到并发防重实战

简介：基于SpringBoot的酒店管理系统设计与实现文档，面向计算机专业毕业设计或课程设计场景，帮助学习者解决传统酒店人工管理效率低、预定与入住信息难同步的问题。资源为单个docx格式文档，压缩包大小约3.11MB，文件体积轻量但内容完整，覆盖从系统需求分析、框架选型到具体功能模块设计的完整流程。文档采用标准论文结构，包含中英文摘要、绪论及系统设计章节，内容组织清晰。已有54人学习下载，适合正在开展酒店管理类项目或需要撰写相关论文的学生参考。全文围绕SpringBoot框架、MySQL数据库与IntelliJ IDEA开发环境的组合展开，依次介绍前台、用户、管理员、员工四类界面，并详细阐述客房预订、客房信息管理、入住安排管理等核心模块，可作为毕业设计说明书基础、系统开发蓝图或课题答辩参考资料。

1. 酒店管理系统是个springboot练手项目，也是并发与状态机的一座坑

一个二十多间房的小酒店，前台拿着一份Excel排房表，客人电话预订时先靠记忆找空房，退房时再靠Excel翻历史。重复预订和账单改错是每天都会发生的常规事故。酒店管理系统要解决的不是“弄个网页录单”，而是三件事：房型与房价的维护、订单从预订到离店的状态流转、以及退房时的账单核算。Spring Boot把这类系统的起步成本压到了最低——自动配置、内嵌容器打一个jar包，但真正决定项目能不能用的，是数据模型和并发控制。这里直接从一个springboot酒店管理系统设计与实现的角度，把工程骨架、表结构、预订接口、redis缓存、登录拦截和并发防重一条线讲下来。适合准备spring boot项目的毕业生，也适合想快速搭一个中小型管理后台的Java工程师。

2. springboot工程骨架：版本选择、包结构与自动装配

很多人的第一个坑不是业务代码，而是版本。Spring Boot目前主流是2.7.x和3.x：2.7.x基于Spring Framework 5.3，支持Java 8到Java 21，代码里还在用javax.命名空间；3.x基于Spring Framework 6，强制Java 17以上，命名空间整体改成jakarta.。按旧教程写import javax.servlet.*，放到3.x工程里编译直接报错；反过来，把3.x的代码挪回2.7又会出现依赖版本对不齐的情况。先把版本关系理清楚，后面的代码才不用反复改import。

2.1 版本与JDK：先解决springboot版本太高导致的“起不来”问题

先用一个表格把关键差异挑出来，再决定pom怎么写：

对于酒店管理系统这种以CRUD和状态流转为核心的工程，钉在2.7.18这类稳定历史版本上是比较稳的组合，历史版本资料多，教程、遇到的报错都好搜；想体验新特性再上3.2.x配JDK 17。pom.xml里用spring-boot-starter-parent当parent，能少写一堆版本号：

<!-- 历史版本组合：Spring Boot 2.7.18 + JDK 8 --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <properties> <java.version>8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> </dependencies>

这段依赖只包含web、data-jpa和mysql驱动，是最小可跑的组合。注意mysql-connector-java在Spring Boot 3.x里改成了com.mysql:mysql-connector-j，自动版本管理会带上对应驱动；2.7.x里写mysql-connector-java没问题。第一次启动如果数据源连不上，Spring Boot会直接抛Failed to configure a DataSource，原因大概率是没配置spring.datasource.url，先配数据库再跑。

补充一句：遇到“springboot版本太高”导致的老项目依赖不兼容，比如Log4j、Quartz的groupId和版本对不上，先看Maven仓库里该版本的dependency-management，不要动不动就强依赖外部本地jar。版本锁死了，后面的自动装配才有讨论基础。

2.2 包结构：controller-service-repository在酒店项目里的对应关系

酒店管理系统的分层不用画太复杂，三层足够。控制层只接收参数和回显结果，服务层管业务规则和事务，数据层不出现任何业务判断。这样面试时被问“一个订单从创建到退房谁负责状态流转”，答案很干净：service层。

src/main/java/com/example/hotel ├── HotelApplication.java ├── config │ ├── RedisConfig.java │ └── WebMvcConfig.java ├── controller │ ├── AuthController.java │ ├── RoomController.java │ └── ReservationController.java ├── service │ ├── RoomService.java │ ├── ReservationService.java │ └── BillService.java ├── repository │ ├── RoomRepository.java │ ├── ReservationRepository.java │ └── BillRepository.java ├── entity │ ├── Room.java │ ├── Reservation.java │ └── Bill.java └── common ├── Result.java └── BusinessException.java

common下的Result是统一返回结构，酒店前台接口不太可能给你时间去定制各种报文格式，Result保持三个字段就够：code、message、data。BusinessException配合全局异常处理，避免Service里抛出一堆RuntimeException没人管。entity与表一一对应，repository只放接口，Spring Data JPA在启动时自动生成实现类，不需要手动写DAO实现。

2.3 springboot自动装配原理：为什么加依赖就能跑起来

启动类上只有一个@SpringBootApplication，它其实由@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan组合。真正干重活的是@EnableAutoConfiguration：它会去classpath下读取自动配置类的文件名列表，从Spring Boot 2.7开始这类文件是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，把里面列出的类按条件注解加载。

每个自动配置类上都有一堆@ConditionalOnClass和@ConditionalOnProperty。比如你引入了redis的starter，但没配置spring.redis.host，配置类会按照默认值创建连接工厂，连接真正失败是在第一次操作时暴露，而不是“加了依赖就生效”。排查这类问题有一个实用开关：启动参数加--debug，或配置文件写debug: true，启动日志会把所有自动配置类的匹配和不匹配原因输出成ConditionEvaluationReport。看到Negative matches下面写的为什么没生效，再对症处理，比盲目加注解高效得多。

注意：--debug只影响自动配置报告，不影响业务日志级别，调试完记得去掉，否则日志量会明显变大。

3. 房型、订单、账单：酒店核心数据模型与接口实现

房间的业务数据其实只有三类：房、单、账。很多springboot酒店系统做不好，不是框架问题，而是表结构里没有体现出房态与订单状态的边界。房间表里别放一段备注扛业务，订单表别把账单拆成几十行冗余字段。先把最小可用的表结构定下来。

3.1 数据模型：room、reservation、bill三张核心表的设计

先给出三张最小可用表：

CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL, room_type VARCHAR(20) NOT NULL, price DECIMAL(10,2) NOT NULL, status VARCHAR(10) NOT NULL DEFAULT 'FREE', version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_room_no (room_no) ); CREATE TABLE reservation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, room_id BIGINT NOT NULL, customer_name VARCHAR(50) NOT NULL, phone VARCHAR(20), check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, total_amount DECIMAL(10,2), status VARCHAR(10) NOT NULL, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_order_no (order_no) ); CREATE TABLE bill ( id BIGINT PRIMARY KEY AUTO_INCREMENT, reservation_id BIGINT NOT NULL, room_amount DECIMAL(10,2), extra_amount DECIMAL(10,2) DEFAULT 0, paid_amount DECIMAL(10,2) DEFAULT 0, settle_date DATETIME );

从字段角度解释：room.status用一个不超过10的字符串，FREE表示空闲、BOOKED表示已预订、CHECKED_IN表示在住，比0/1/2的数字魔法值更好读，排查时不用翻代码猜含义。reservation单独拆order_no，业务上用户拿订单号对账、前台按订单号查操作记录，比拿自增id可靠；check_in_date和check_out_date用DATE类型，跨天计算时比TIMESTAMP清爽。version列给乐观锁用，第4章会用到。

3.2 用Spring Data JPA还是MyBatis Plus：我选JPA的理由

酒店系统表不多、关联不深，Spring Data JPA是Spring Boot官方默认，接口方法名可以直接表达查询意图：findByStatus、findByRoomIdAndStatus。MyBatis Plus也很好，但需要额外引入依赖和XML或注解SQL。两者都能做，但JPA在“按日期区间查可用房”这类查询上更直接，不用手写复杂的动态SQL。

@Entity @Table(name = "room") public class Room { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "room_no", length = 10, nullable = false) private String roomNo; @Column(name = "room_type", length = 20, nullable = false) private String roomType; @Column(name = "price", nullable = false) private BigDecimal price; @Column(name = "status", length = 10, nullable = false) private String status; @Column(name = "version", nullable = false) private Integer version; // getter / setter 省略，按业务需要补充 }

Room实体里没有写@ManyToOne之类的复杂关联，一间房在订单里只存roomId。酒店系统的查询大多是按日期和状态过滤，不维护外键对象反而让接口更好读。接下来是Repository接口，注意这里@Query里写的是JPQL而不是原生SQL：

public interface RoomRepository extends JpaRepository<Room, Long> { @Query("select r from Room r where r.roomType = :roomType and r.status = 'FREE' " + "and r.id not in (select res.room.id from Reservation res " + "where res.status in ('CREATED','PAID','CHECKED_IN') " + "and res.checkInDate < :checkOutDate and res.checkOutDate > :checkInDate)") List<Room> findAvailableRooms(String roomType, LocalDate checkInDate, LocalDate checkOutDate); }

这个查询把“可用房”定义清楚：先限定房间状态是FREE，再排除那些订单时间与本次入住区间有重叠的房间。其中res.checkInDate < :checkOutDate and res.checkOutDate > :checkInDate是判断两个日期区间重叠的经典写法，比分别比较“入住日是否在某订单范围内”要严谨，能覆盖提前到店和延迟离店的情况。

3.3 预订接口：Controller、Service与事务边界

创建预订是最容易出现“数据库有空房，实际订不到”的地方，核心事务要放在service方法上，Controller只做参数接收和结果返回：

@RestController @RequestMapping("/api/reservation") public class ReservationController { private final ReservationService reservationService; public ReservationController(ReservationService reservationService) { this.reservationService = reservationService; } @PostMapping public Result<OrderVO> create(@Valid @RequestBody CreateOrderRequest req) { OrderVO order = reservationService.create(req); return Result.ok(order); } }

Service里的create方法，重点看事务边界和房态占用的顺序：

@Transactional public OrderVO create(CreateOrderRequest req) { Room room = roomRepository.findById(req.getRoomId()) .orElseThrow(() -> new BusinessException("房间不存在")); if (!"FREE".equals(room.getStatus())) { throw new BusinessException("该房间已被预订"); } String orderNo = generateOrderNo(); Reservation res = new Reservation(); res.setOrderNo(orderNo); res.setRoomId(room.getId()); res.setCheckInDate(req.getCheckInDate()); res.setCheckOutDate(req.getCheckOutDate()); res.setStatus("CREATED"); res = reservationRepository.save(res); // 条件更新房态，影响行数为0说明被并发抢先 int rows = roomRepository.updateStatus(room.getId(), "FREE", "BOOKED"); if (rows == 0) { throw new BusinessException("手慢了，房间刚被订走"); } return toVO(orderNo, room.getPrice(), res); }

@Transactional保证这中间任何一步抛异常，前面保存的订单会一起回滚，不会出现“订单存在但房态还是FREE”的脏数据。两个坑需要记住：一是@Transactional自调用时失效，比如类内部一个普通方法调另一个带@Transactional的方法，事务不生效；二是这里先save订单再更新房态，updateStatus返回0时抛出BusinessException，整个事务回滚，正好把订单删掉。

4. redis缓存、登录拦截与并发防重：让springboot酒店系统跑稳

后台系统一旦同时有两三个前台在操作，问题就都会冒出来：同一间房被订两次、“我明明下单了但页面没反应”、退房时账单对不上。前面把表结构和接口搭起来只是第一步，稳定运行要靠缓存、拦截器和并发控制。

4.1 用redis缓存房型与今日房价，防击穿的兜底做法

房价不会每分钟变，但前台查房、算房价的请求每分钟都有。用redis缓存可以明显减少数据库压力。springboot使用redis的方式很成熟：加starter，配连接信息，然后在service里定义缓存Key。

application.yml中的redis配置：

spring: redis: host: 127.0.0.1 port: 6379 timeout: 3s

注意：Spring Boot 2.x用spring.redis.host，Spring Boot 3.x用spring.data.redis.host。这个配置位置变化就是版本升级时最常见的“redis在springboot中的使用”报错点。再看一个service里用redis的写法：

@Service public class PriceService { private static final String PRICE_KEY = "hotel:price:roomType:%s"; private final StringRedisTemplate stringRedisTemplate; public PriceService(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; } public BigDecimal getPrice(String roomType) { String key = String.format(PRICE_KEY, roomType); String cached = stringRedisTemplate.opsForValue().get(key); if (cached != null) { return new BigDecimal(cached); } BigDecimal price = queryPriceFromDb(roomType); int ttl = 600 + new Random().nextInt(60); stringRedisTemplate.opsForValue().set(key, price.toString(), ttl, TimeUnit.SECONDS); return price; } }

随机过期时间的目的很明确：避免同一类Key在同一秒集体失效，流量同时打到数据库，这是缓存击穿的一种轻量解法。如果queryPriceFromDb这一步也慢，可以把数据库查询结果在进程内再放一份，但不要为了这个需求引入一套完整本地缓存框架，酒店管理系统的规模用不上。

4.2 用HandlerInterceptor做登录拦截，轻量不需要Spring Security

酒店后台的页面少、接口也不多，登录拦截用Spring MVC自带的HandlerInterceptor就够了，比引入Spring Security整套配置轻得多。拦截器里看到没有token就返回401，再由全局异常处理器统一包装JSON。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !TokenStore.isValid(token)) { response.setStatus(401); return false; } return true; } }

注册拦截器，明确放行登录、静态资源与健康检查：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/error", "/actuator/health"); } }

addPathPatterns写/api/**表示只拦截业务接口；excludePathPatterns里放登录接口和actuator健康检查，否则前台登录前连健康检查都打不通。TokenStore这里可以用一个简单的ConcurrentHashMap模拟，正式项目换redis加有效期过期判断，逻辑不变。

4.3 并发下单与防超卖：条件更新、乐观锁与幂等号

酒店房间数量少，但订单集中在节假日，同一间房被两个前台抢订的场景是真实存在的。并发防超卖在springboot里最常用的是条件更新，对应的SQL长这样：

UPDATE room SET status = 'BOOKED', version = version + 1 WHERE id = ? AND status = 'FREE'

影响行数为0说明房间状态已经不是FREE，直接让这次请求失败。乐观锁则更通用，在实体上加@Version，更新时JPA自动带上版本条件。对于酒店管理这种并发量级，条件更新已经够用，不需要上分布式锁。

防重还有一个容易被忽略的点：订单幂等。同样一个订单被用户双击提交两次，会产生两笔预订。用uk_order_no这个唯一索引约束，配合orderNo的前缀设计（日期加随机数），第二次插入唯一键冲突时捕获DuplicateKeyException返回“订单已提交”，不要向上抛500。表结构里的uk_order_no就是为了兜住这种情况。

这三层想清楚，面试被问“如何避免两个前台同时订到一间房”就能讲出完整链路：先查房态，再条件更新房态，落到订单时用唯一键防重复。

5. 上线前的一组springboot自查：traceId、actuator与接口验证

5.1 加一个traceId日志字段，退房对账不再靠眼睛翻串

订单处理日志如果只有线程名和类名，出问题时要在十几条相同样式的info里靠人工反复对照。常见的做法是在日志pattern里加入MDC字段，最合适的key就是traceId。

<pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - [%X{traceId}] %msg%n</pattern>

在拦截器里往MDC放UUID，请求结束后清理：

@Override public boolean preHandle(...) throws Exception { MDC.put("traceId", UUID.randomUUID().toString().replace("-", "")); // 原有逻辑不变 } @Override public void afterCompletion(...) throws Exception { MDC.remove("traceId"); }

5.2 用actuator做只读健康检查，别把所有端点都暴露出去

pom里加spring-boot-starter-actuator，配置文件只暴露health和info，保证不会把beans、env这些内部信息暴露到外网。

management: endpoints: web: exposure: include: health,info

验证Health端点是否正常的命令：

curl http://127.0.0.1:8080/actuator/health

返回{"status":"UP"}说明应用和数据源都正常，比看启动日志更直接。

5.3 用一条curl把预订-房态-账单串联起来

写一个验证脚本，顺序调用登录、创建订单、查询房态，检查返回值，把接口级回归从手动点页面变成一条命令。脚本里可以这样写：

curl -s -X POST http://127.0.0.1:8080/api/auth/login curl -s -X POST http://127.0.0.1:8080/api/reservation \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"roomId":1,"checkInDate":"2025-07-10","checkOutDate":"2025-07-12","customerName":"张三"}'

第一个curl拿到token后，第二个curl创建订单。正常返回orderNo，再查一次房间接口，确认room状态已经变成BOOKED，这条链路就算通了。最后把日志里的traceId和订单号一起归档到本地，出问题时第一件事就是grep traceId。

本文还有配套的精品资源，点击获取