1. 从选题到落地：这套区域酒店住宿系统到底要解决什么问题
每年到毕业设计选题季，“酒店管理系统”都是计算机专业被选烂了的题目。你要是直接拿一个所谓的“通用酒店管理系统”去交差，大概率会被答辩老师问住：你的系统跟前几届学长做的区别在哪里？数据量稍微大一点会不会崩？如果酒店分布在多个区域，你怎么处理这种区域维度的数据关系？
我最初接触这个“Spring Boot 区域酒店住宿信息系统”题目的时候，第一反应也是“又是一个典型 CRUD”。但真正把需求拆开以后会发现，这套系统远不是简简单单的增删改查，它里面对业务场景的归纳、对表结构的组织、对区域维度的处理，恰好覆盖了 Spring Boot 开发中最常被考察的核心能力。作为毕业设计，它既不会难到无法完成，又能让答辩老师看到你在业务分析和架构设计上的思考。
这个题目要交付的东西，用一个场景描述就是这样：一个连锁酒店品牌，旗下酒店分布在不同的城市和行政区，用户进入系统后，先选区域（城市/商圈/行政区），系统再按该区域展示可订房型、房价和剩余房量，用户下单后生成住宿订单，后台管理员能维护酒店信息、房型库存、订单状态，同时运营方能拿到各区域酒店的入住率数据。
痛点很明确：很多酒店系统是“单店模式”，数据结构设计时根本没有区域维度这一层，导致后面想要按城市或者商圈的粒度去做房源聚合、价格分析、入住率统计时，只能在后端写一堆重复的 SQL 硬查。而这套系统的设计，核心就是把“区域”这个概念从立项第一天就嵌进数据结构和业务逻辑里，不是为了花哨，而是省级酒店集团做管理和报表时确实就是这么划分业务单元的。
适合参考这套系统的人，我总结下来有三类：
- 准备做酒店、住宿、民宿类管理系统的毕业生，想找一个业务上立得住、技术上又能展示亮点的题目。
- 在校练手 Spring Boot 项目，但不想再写“图书管理”“学生管理”那种纯单表 CRUD 的，希望增加一点真实业务复杂度的人。
- 工作后需要做类似区域类业务系统（比如区域门店管理、分区域订单平台）的初级开发者，可以参考它的数据建模思路。
说起技术选型，为什么题目指名道姓要用 Spring Boot，而不是 SSM，也不是 Spring Cloud？答案其实很简单：Spring Boot 是目前 Java 后端单体应用中最平衡的选择。它用自动配置把 Spring 体系的繁琐配置压到了最低，内置 Tomcat 可以打成 jar 直接跑，配合 Spring Data JPA 或 MyBatis-Plus 能极大缩短数据访问层的开发时间。对于毕设这个周期的项目来说，Spring Boot 让你把精力放在业务逻辑是否完整、功能是否闭环上，而不是在 xml 配置里 Debug 三天。
另外，Spring Boot 也是面试出场率最高的 Java 框架，没有之一。你可能不信，答辩老师或者面试官看到“基于 Spring Boot 的酒店住宿系统”这个题目的第一反应，往往就是顺着你的设计问出这些问题：Spring Boot 的自动配置原理是什么？它的启动流程和 Spring 传统项目有什么不同？你用的 starter 底层是怎么加载进来的？如果这几点你能结合自己项目里的实际配置讲清楚，那这套系统就不仅是“能跑”，而是你真的理解它。这也是我下文所有方案设计的出发点：每一个技术选型都不是拍脑袋，而是为了让项目兼顾“可展示”和“可深问”。
2. 业务建模和模块设计：先定边界，再写代码，能少走一半弯路
2.1 区域粒度怎么分才合理
做这类系统的第一个关键决策，是区域的层级怎么定义。是省、市、区三级固定树形结构，还是一张自关联的区域表？
我建议用一张自关联表：区域表里有一个 parent_id 指向自己的上级区域。省就是顶级节点，市指向省，区/县指向市。如果系统将来业务扩展到商圈粒度，也只要在中间插入一个新节点，不需要改表结构。
这种设计的好处有两点。第一，前端页面的“区域选择器”可以直接遍历这张树，用户可以在省市区之间逐级联动，很自然。第二，后端在查询酒店时，传入某个区域 id，既能查该区域内全部酒店，也能通过 parent_id 递归查出某个省下面所有城市的酒店，这对后续入住率统计很有价值。
实际做的时候要注意，酒店表里只需要存最低层级的区域 id。比如说你选择了“深圳市南山区”这个节点，就存南山区的 id，不要存深圳市也不存广东省。为什么？因为向上查询区域归属永远容易，向下查找子区域反而麻烦。这样查询时，如果你要列出南山区全部酒店，直接where region_id = ?；如果你要查深圳市全部酒店，先用一条 SQL 拿到深圳的所有子区域 id，再where region_id in (...)就行。
2.2 核心数据表拆解
再来拆核心表。我的建议是六张起步：区域表、酒店表、房型表、订单表、用户表、管理员/操作日志表。底下我给出一个经过简化的建表思路，字段命名和类型可以用 Navicat 或者 MySQL Workbench 直接对着建，想要用代码管理表结构也可以配好 JPA 的 ddl-auto 让它自动同步，但毕设答辩时我更推荐把 SQL 文件也导出一份，方便老师直接导入查看。
区域表 region：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint 主键 | 区域节点 id |
| name | varchar(50) | 区域名称，比如“广东省” |
| parent_id | bigint | 父级区域 id，顶级填 0 |
| level | tinyint | 层级，1省 2市 3区县 |
| sort | int | 同级排序号 |
酒店表 hotel：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 酒店 id |
| name | varchar(100) | 酒店名称 |
| region_id | bigint | 所属区域 id，存最低层级 |
| address | varchar(255) | 详细地址 |
| star_level | int | 星级（1-5） |
| phone | varchar(20) | 联系电话 |
| status | tinyint | 0停业 1营业 |
| create_time | datetime | 创建时间 |
房型表 room_type：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 房型 id |
| hotel_id | bigint | 所属酒店 |
| type_name | varchar(50) | 房型名，大床房/双床房等 |
| price | decimal(10,2) | 门市价 |
| area | varchar(20) | 房间面积 |
| bed_info | varchar(50) | 床型信息 |
| total_count | int | 该房型总房间数 |
| available_count | int | 可用房间数 |
| status | tinyint | 0下架 1上架 |
订单表 orders：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 订单主键 |
| order_no | varchar(32) | 订单编号，全局唯一 |
| user_id | bigint | 下单用户 |
| hotel_id | bigint | 酒店 id |
| region_id | bigint | 冗余区域 id，方便按区域统计订单 |
| room_type_id | bigint | 房型 id |
| check_in_date | date | 入住日期 |
| check_out_date | date | 离店日期 |
| nights | int | 住宿晚数 |
| total_amount | decimal(10,2) | 订单总额 |
| status | tinyint | 0待支付 1已支付 2已入住 3已退房 4已取消 |
用户表 users 和操作日志表 operation_log 我就不展开列字段了。用户表就是 id、用户名、密码（加密存储）、手机号、注册时间；操作日志表记管理员对酒店、房型、订单的每一次关键操作，这个表在毕设里是加分项，因为很多人的系统做了但没有审计意识，你加了这张表，答辩时能讲出“这个系统具备基本的数据审计能力”，档次一下就上去了。
2.3 数据冗余与状态机设计
这里重点说一下订单表里的 region_id 这个冗余字段。正常来说，订单关联酒店就能反查区域，不需要单独冗余一个 region_id。但实际开发里，运营后台要按区域统计“某区这个月的订单量”和“各区域的收入排行”，如果你不做冗余，那 SQL 就要JOIN hotel再到JOIN region，数据量一大性能就很受影响。冗余虽然违背了严格的三范式，但在这个场景下，是以空间换查询性能的经典思路，你可以在答辩时主动提一句：“我在这张订单表冗余了区域字段，因为订单创建后区域不会再变，这种稳定字段的冗余是安全的”，这是一句非常专业的表述。
房间状态这块也要认真设计。很多同学在房型表里只放一个 total_count，然后通过统计订单来判断是否满房。这样的问题是，一个房型的订单可能横跨多个日期，如果用户入住日期是 7 月 1 日到 7 月 3 日，订单状态是“已取消”，它到底算不算占用房源？因此我的建议是，房状态不要实时去订单表里 count，而是做一个“每日房态表”，用日期+房型 id 唯一确定某一天的可售数量。
这个表看起来多了一张表，但逻辑非常清晰。每次用户提交订单时，系统检查入住期间的每一天可用房量是否大于等于 1，够就一次性扣减这些日期的量，生成订单；用户取消订单时，反向把日期段内每日可用量加回去。这个做法叫“库存预占”，是订房类系统通行的方案。你的毕设如果只有几十个并发用户，不用这个方案也能糊弄过去，但如果老师追问“这段日期内房间会不会被超卖”，你单独 count 订单的方案就会很难自圆其说，而“每日房态预占”这个回答几乎是无懈可击的。
2.4 区域主页流程的一条线走通
把功能闭环串一下：用户登录后，首页展示省市区的区域树，点击“深圳市”跳转到深圳酒店列表页，里面是该区域下所有营业中的酒店卡片，再点进去一家酒店，能看到所有上架房型，以及每个房型在所选日期区间内“余 X 间”的实时状态，选定后填写入住人提交订单，支付（毕业设计一般用模拟支付）后订单状态流转为“已支付”。后台管理员端则维护酒店和房型信息，处理订单退款，查看各区域酒店当日入住率。
这一条线走通，这套系统的主干就有了。剩下的全是细节打磨，例如搜索条件和分页、接口返回码统一、参数校验、全局异常捕获。接下来要进入的，是工程搭建环节。
3. 用 Maven 方式构建 Spring Boot 项目，工程结构和依赖这样配才规范
3.1 为什么毕设也要认真建 Maven 工程
很多初学者喜欢用 IDEA 里的 Spring Initializr 一下就把工程生成了，然后不管三七二十一，代码全堆在一个包下面。Controller 里写业务逻辑，Service 直接查了数据库就返回，Entity 兼职当 VO 用，表一多项目就乱成一锅粥。
用 Maven 构建 Spring Boot 项目，不只是一个“构建工具”层面的选择，它是给你养成工程化习惯的入口。Maven 最大的价值是依赖管理和标准化的目录结构。你只要遵循约定，src/main/java写代码，src/main/resources放配置，Maven 就会自动帮你在编译、测试、打包阶段执行好对应的生命周期插件。对你来说，体验最直观的就是：代码写完以后，在命令行执行mvn clean package，打完以后的target目录下就会生成一个可直接执行的 jar 包，一行java -jar就能启动整个系统，没有外部 Tomcat 依赖，也省去了 IDE 里一堆 Run Configuration 的折腾。
这种构建方式在面试中也有话可说。比如面试官问“你用过哪些构建工具，Maven 和 Gradle 有什么区别吗？”，你可以接上：“我项目是用 Maven 构建的，依赖管理用的中央仓库坐标机制，项目里打出来的 jar 包可以用 Spring Boot Maven 插件做可执行打包。”这些实践过的细节，比背书强得多。
3.2 一个能直接跑通的 pom.xml 长什么样
下面这份 pom.xml 的核心依赖，是我在一个酒店住宿系统项目里实际使用并验证过的组合。为了不过分绑架你的版本，我用 Spring Boot 3.x 时代最常见的配置（JDK 17）。
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> <relativePath/> </parent> <groupId>com.example</groupId> <artifactId>hotel-region-system</artifactId> <version>1.0.0</version> <name>hotel-region-system</name> <description>区域酒店住宿信息管理系统</description> <properties> <java.version>17</java.version> <mybatis-plus.version>3.5.5</mybatis-plus.version> <jjwt.version>0.11.5</jjwt.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-validation</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-spring-boot3-starter</artifactId> <version>${mybatis-plus.version}</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>${jjwt.version}</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>${jjwt.version}</version> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-jackson</artifactId> <version>${jjwt.version}</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>我说下为什么这么配。Web 和 Validation 两个 starter 属于基础配置，前者提供了 Spring MVC 和内置 Tomcat，后者让你能用@Valid注解对入参做声明式校验，省掉一堆手写的 if 判断。Redis 的引入一方面是为了做用户登录 token 的存储，另一方面是给后面的消息队列场景留位置。MyBatis-Plus 是我个人比较推荐的数据访问层框架，单表 CRUD 几乎不用手写 SQL，复杂查询又保留了 XML 自定义 SQL 的口子，非常适合毕设阶段快速开发。JWT 是用来做前后端分离时认证令牌的，简单、无状态，配合拦截器也方便前后端联调。
这些依赖之间的版本冲突问题，Spring Boot 的 parent BOM 已经替你管住了一大半，你几乎不需要手动指定 starter 的版本。我唯一需要手动锁定的是 MyBatis-Plus 的版本，因为它的版本更新节奏是独立的，如果版本和 Spring Boot 3 不匹配，会出现组件扫描不到 Mapper 这类诡异问题，所以我直接固定在了和 Spring Boot 3 兼容良好的版本上。
3.3 分层分包，代码该放哪就放哪
工程的包结构我建议这样分，虽然不是强制，但这种分包能让你在任何代码评审面前都显得很专业：
com.example.hotel ├── controller // Controller 层：接收请求、参数校验、返回统一结果 ├── service // 业务逻辑层：核心业务规则都在这里 │ └── impl ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库表对应的实体 ├── dto // 前端入参封装对象 ├── vo // 后端返回给前端的数据视图对象 ├── common // 公共类：统一返回体、异常类、常量 │ └── result ├── config // 配置类：Redis 配置、拦截器配置、CORS 配置 ├── util // 工具类：JWT 工具、日期工具等 └── HotelApplication.java // 启动类Controller 层只做“接参数、转对象、调 Service、包结果返回”，Service 层实现真正的业务规则。为什么要这么做？核心目的是可测试性和可维护性。你的下单逻辑可能涉及库存检查、订单状态流转、积分计算三步，这些如果全部堆在 Controller 里，一方面 Controller 变得巨长，另一方面你没法对业务逻辑单独做单元测试。而拆到 Service 层以后，Controller 只是瘦瘦的一层壳，业务变了只改 Service，接口变了才动 Controller。
举一个实际的接口设计例子。后端给前端的一个“酒店列表”接口，返回的字段可能来自酒店表、还带上了区域名称、该酒店最低房价。如果你直接把 Entity 扔给前端，字段会包含一些不必要的 createTime、updateTime 等字段。我更建议定义一个 HotelVO，只暴露前端需要的几个字段。这个“前端要什么就返回什么”的意识，很多人工作两年都没有养成，如果你在毕设里就掌握了，面试时能说出“我用 DTO 做入参校验，用 VO 做返参裁剪，避免把实体直接暴露给客户端”，面试官对你的印象分完全不同。
3.4 启动类到底做了什么
Spring Boot 的启动类核心是@SpringBootApplication这一个注解。很多人只知道“加了它就能启动”，但如果你能在毕设中正确讲述它的本质，会非常加分。这个注解是一个复合注解，它囊括了三个能力。
第一是@SpringBootConfiguration，它表示当前类是一个配置类，可以挂@Bean等方法级配置。第二是@EnableAutoConfiguration，这是 Spring Boot 的自动配置核心。它在启动时会尝试读取 classpath 下的 META-INF 配置文件，加载你引入的 starter 对应的自动配置类，然后再根据一系列@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty以及@EnableConfigurationProperties条件判断决定哪些配置类生效。放在我们这个项目里，你只要引入了 spring-boot-starter-web 并确保项目里有spring-webmvc的相关类，自动配置就会帮你注册 DispatcherServlet；只要 classpath 有DataSource相关的类而且你在 application.yml 里配好了数据库地址，数据源也会被自动装配好。第三是@ComponentScan，它默认扫描启动类所在包及其子包，这就是为什么你的 Controller、Service、Mapper 必须在启动类的子包里的原因，出包了扫描不到，项目起得来但是访问就报 404。
启动流程上，Spring Boot 会先创建 SpringApplication 实例，推断应用类型、加载主配置类、准备 Environment、创建容器、刷新上下文，最后把CommandLineRunner或ApplicationRunner里自定义的 bean 跑一遍。这个“启动时执行一段初始化逻辑”的钩子在我们这个酒店系统里有一个很实用的场景：系统启动时从数据库读取所有酒店和房型，预热到 Redis 缓存里，这样用户第一次访问首页酒店列表时就不会打到数据库了。
4. Redis Stream 在预订与消息处理里的实际应用
4.1 为什么要引入 Redis Stream，而不是 MQ
毕设级别的酒店系统，要不要上消息队列？答案很明确：不需要上 RabbitMQ 或 Kafka，但你可以用 Redis Stream 来实现一个轻量级的“队列效果”。原因有两点。
第一，轻量。Redis Stream 是 Redis 5.0 引入的数据结构，它不像 RabbitMQ 那样需要独立部署交换机、队列、绑定关系，只要项目里有 Redis，就能直接使用。第二，这个场景本身适合。酒店系统里哪些地方可以用到消息队列？一个典型场景是订单超时未支付自动取消。用户下单后如果把 15 分钟内支付，需要一个延迟任务来检查超时订单。用 Redis 的 Key 过期监听或者定时任务扫表可以实现，但前者有丢消息风险，后者说白了就是定时轮询，不够优雅。另一个典型场景是“日志异步落库”，管理员每一次操作都写一条日志，如果同步插入会拖慢主流程一点点，可以用 Stream 把日志事件先推到队列里，再异步消费写入数据库。
你可能会问，为什么这个项目要坚持使用 Redis Stream 来“拉取队列消息”？因为如果有两三个消费者同时从同一个 Stream 里读消息，用消费者组可以做到每条消息只被一个消费者处理。比如订单创建成功的短信通知、房态变更的通知，可能有多个服务关心，但你并不希望每个服务都去数据库里翻。用 Stream 的消费者组功能，可以将这些消息按组分发，处理逻辑解耦得非常干净。写简历时你甚至可以写明“使用 Redis Stream 实现系统内模块间的异步解耦”，这比“用过 Redis 存验证码”这种描述高到不知道哪里去了。
4.2 消息生产与消费的完整代码
先演示一个简化版的生产者。房态预占成功、订单创建后，把日志内容推送给 stream：
@Service @RequiredArgsConstructor public class OrderLogProducer { private final StringRedisTemplate redisTemplate; public void sendOperateLog(String operator, String action, Long orderId) { Map<String, String> message = new HashMap<>(); message.put("operator", operator); message.put("action", action); message.put("orderId", String.valueOf(orderId)); message.put("timestamp", String.valueOf(System.currentTimeMillis())); // 推送到 hotel:order-log 这个 Stream redisTemplate.opsForStream().add("hotel:order-log", message); } }消费端有两种写法。一种是简单地从 Stream 里读消息，但考虑到我们不希望消息被重复消费，我建议用消费者组模式。先创建消费者组：
XGROUP CREATE hotel:order-log log-group 0 MKSTREAM然后在代码里写一个消费者，用XReadGroup命令拉取属于本组的新消息：
@Component public class OrderLogConsumer { @Scheduled(fixedDelay = 1000) public void consume() { List<MapRecord<String, Object, Object>> records = redisTemplate.opsForStream() .read(Consumer.from("log-group", "consumer-1"), StreamReadOptions.empty().count(10).block(Duration.ofSeconds(1)), StreamOffset.create("hotel:order-log", ReadOffset.lastConsumed())); for (MapRecord<String, Object, Object> record : records) { try { String operator = (String) record.getValue().get("operator"); String action = (String) record.getValue().get("action"); // 写入数据库操作日志表 saveLog(operator, action); // 确认消息已被处理 redisTemplate.opsForStream().acknowledge("hotel:order-log", "log-group", record.getId()); } catch (Exception e) { // 处理失败的消息可以放入 PENDING 列表等待重试 } } } }这里有个非常关键的操作，就是acknowledge。Stream 里的消费者组维护了一个 PENDING（待确认）列表，如果消费者拉取了消息但没有确认，这条消息会一直停留在 PENDING 里，便于 Group 内其他消费者重新读取。这其实是给消费端提供了一个不丢消息的保障机制。实操中，我遇到过消费者线程在写入数据库前突然宕机，消息没有 ACK，重启后程序会把 PENDING 里的消息重新拉出来消费，从而避免了日志漏记。这种“至少一次”的消费语义，配合业务上做幂等去重，才是完整的消息处理方案。
另外，为什么我用@Scheduled(fixedDelay = 1000)轮询而不是用XREADGROUP BLOCK长轮询？两者都可以，@Scheduled的写法在毕设里更容易被看懂和解释。当然专业一点的做法是长轮询减少资源消耗，但这就需要在@PostConstruct里启动一个独立的阻塞线程，工程上会稍微复杂一些。对于毕设项目，每秒一次或每 500 毫秒一次轮询，实打实够用，而且代码可读性极高。
4.3 用 Redis 做分布式锁，防止房态超卖
订单创建时“检查每日可用房量”和“扣减库存”这两个操作如果并发执行，会产生经典的超卖问题。比如某日只剩 1 间房，两个用户同时下单，都读到剩余 1 间，都认为可订，最后把同一间房卖给了两个人。解决办法之一就是对“房型+日期”这个库存维度加一个分布式锁。
Redis 分布式锁的标准实现是SET lock_key unique_value NX EX。NX 保证只有没有 key 时才能设置成功，EX 防止客户端宕机后死锁。Spring Boot 里可以用 RedisTemplate 的setIfAbsent方法来实现，下面是一个简化版本的锁工具：
public boolean tryLock(String key, String requestId, long expireSeconds) { return redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); } public void unlock(String key, String requestId) { String current = (String) redisTemplate.opsForValue().get(key); if (requestId.equals(current)) { redisTemplate.delete(key); } }这里 requestId 的设计很讲究——它必须是每个请求唯一的标识（比如 UUID），释放锁时也只能释放自己持有的锁，否则你可能会误删别人刚获取的锁。解锁时“先查再删”不是原子操作，更严谨的做法是用 Lua 脚本保证原子性，但毕设阶段上面这段配合 requestId 判断基本够用。真正要理解的是，如果集群部署多个实例，Java 内置的 synchronized 只能在单机内生效，必须用到 Redis 这类跨进程共享的中间件，锁才有意义。这句话想明白了，回答面试官“为什么用 Redis 分布式锁”就没问题了。
4.4 秒级超时订单取消怎么做
订单 15 分钟未支付自动取消，是我很推荐加进毕设的一个功能。这个功能一方面体现了你对业务流程闭环的思考，另一方面是线上项目的高频真实需求。
做法上用 Redis 的过期通知是最常见的方案：用户下单后，设置一个 keyorder:expire:{orderId}，过期时间 15 分钟，同时开启 Redis 的 keyspace notifications。当 key 过期时，客户端监听__keyevent@0__:expired频道，收到之后去订单表里查一下该订单状态，如果还是“待支付”，则更新为“已取消”，并把之前预占的每日房量回补。
但要提醒你，Redis 默认并未开启过期通知，需要修改配置notify-keyspace-events Ex才能生效。在实际开发中，redis.conf 里把这一项加上，或者通过命令CONFIG SET notify-keyspace-events Ex临时开启即可。这个方案有一个小缺陷：Redis 的过期通知并不是精确到毫秒立即触发的，它是 key 被清理时才发事件，正常情况下延迟很小，毕设场景完全够用。你的设计说明里可以坦然地说这个方案有较好的实时性且实现成本低，适合中小型应用。
5. Micrometer + Spring Boot Actuator：让毕设从“能跑”进化到“可观测”
5.1 为什么要引入 Actuator 和 Micrometer
很多人做完 Spring Boot 项目，从没看过它的运行指标。而 Micrometer 和 Spring Boot Actuator 这对组合，是 Spring Boot 应用在生产环境做健康检查、指标采集、运行监控事实上的标准方案。
Actuator 本身不负责“存储度量数据”，它更像一个数据暴露层，把 Spring Boot 应用内部的健康状态、当前线程信息、Bean 列表、环境变量、日志级别这些运行期信息，通过 HTTP 端点暴露出来。Micrometer 则像一个度量门面，它定义了一套统一的指标 API（Counter、Timer、Gauge、DistributionSummary），应用代码只需要面向 Micrometer 的 API 记录指标，后端可以把指标输出到 Prometheus、InfluxDB 或者简单地暴露/actuator/prometheus让监控系统来抓取。
选用这套组合在毕设里的价值，不只是“看起来高大上”，而是它能回答一个很实际的问题：系统运行得好不好？内存有没有泄漏？接口平均响应时间是多少？哪个接口最慢？比如在酒店项目中，用户高频访问的“房态查询”接口，你希望确知它的平均耗时，如果超过 500ms 就需要优化缓存策略。没有监控，就只能靠感觉去猜。有了监控，拿数据说话。
5.2 具体的配置和暴露哪个端点
引入的依赖非常轻量：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>下面这段是我实际项目的配置，它非常好用：
management: endpoints: web: exposure: include: health,info,metrics,prometheus endpoint: health: show-details: always metrics: tags: application: ${spring.application.name}配置好以后启动项目，访问/actuator/health，你会得到一个 JSON，状态 UP 表示应用是正常的。如果 Redis、MySQL 连接失败，状态会变成 DOWN，这就是 Actuator 帮你自动探测外部健康状态的能力。
真正要展示的指标，还是 Prometheus 格式的数据。访问/actuator/prometheus，你会看到类似下面这种输出：
# HELP http_server_requests_seconds # TYPE http_server_requests_seconds summary http_server_requests_seconds_count{application="hotel-region-system",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/hotel/list"} 328.0 http_server_requests_seconds_sum{application="hotel-region-system",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/hotel/list"} 12.84看到没有，Micrometer 已经自动帮你采集了 HTTP 请求的次数和总耗时。从/hotel/list这个 URI 上，你看一眼就知道线上环境这个接口一共被调了 328 次，总共耗时 12.84 秒，平均下来每次四五十毫秒上下。如果要查某个接口的 P99 延迟，可以用 Prometheus 的histogram_quantile函数在那一端算，如果你是在毕设里，直接用平均数就能说明问题。
在系统运行时，我也推荐自己埋点统计业务指标。比如订单创建量，可以用 Micrometer 的 Counter：
@Service public class OrderMetricsService { private final Counter orderCreateCounter; public OrderMetricsService(MeterRegistry meterRegistry) { this.orderCreateCounter = Counter.builder("hotel.order.created.total") .description("累计创建订单总数") .register(meterRegistry); } public void recordCreateOrder() { orderCreateCounter.increment(); } }用register(meterRegistry)把这个指标注册到 MeterRegistry，之后在/actuator/prometheus端点就能看到hotel_order_created_total这个指标了。答辩时你可以加一句：“我通过微服务中常用的 Micrometer 指标门面，对订单创建量做了业务埋点，这样除了系统层面的 CPU、内存指标之外，还能看到业务量的变化趋势。”这句话让答辩老师听出来你不仅懂框架，还懂业务监控。
5.3 给项目增加可视化面板
到这里，Actuator 只是暴露了指标，如果你想给毕设加一个看起来特别有排面、又能截图写进论文的功能，那就搭配 Prometheus + Grafana 做可视化监控面板。
Prometheus 的配置文件 prometheus.yml 里，把 Spring Boot 应用加入抓取任务：
scrape_configs: - job_name: 'hotel-system' metrics_path: '/actuator/prometheus' static_configs: - targets: ['localhost:8080']启动 Prometheus 后，它会每 15 秒去 Spring Boot 应用的/actuator/prometheus拉取一次指标。接着在 Grafana 里添加 Prometheus 数据源，导入一个 JVM / Spring Boot 的 dashboard 模板，填入 Prometheus 的地址，不出 10 分钟，一个包含 JVM 内存曲线、HTTP 请求吞吐量、响应时间热力图的监控面板就出来了。
我能告诉你的经验是，这个面板一旦做出来，截图放进你的毕业设计论文“系统测试”那一章，是真的很能打。它展示的不只是功能测试通过，而是系统层面的运行观测能力，这是很多同学完全没有设想到的差异化亮点。不过要注意，Prometheus 和 Grafana 的安装下载可能对网络有要求，建议提前准备好离线安装包，或者把配置过程剪辑成视频片段，在答辩时直接展示 Web 页面效果即可。
5.4 从监控数据里能发现什么实际问题
说一个我在实际测试中遇到的例子。系统做完后，我用 JMeter 并发 50 个用户对“房态查询”接口做了 3 分钟压测。跑完以后打开 Actuator 暴露的 Prometheus 指标，发现http_server_requests_seconds_max这个接口的最长响应时间到了 4.2 秒，很不正常。顺着链路排查下去，定位到房态 Query 每次都要实时去 Redis 和数据库做日期区间判断，缓存没有生效，导致数据库压力一大，接口就出现毛刺。后来我把“可售房量”在每日凌晨批量预热到 Redis，并针对热点房型的当日库存做了一个 10 秒短缓存，接口的最长响应时间降到了 700ms 以内。
如果没有监控数据，这类问题只能靠用户反馈才能感知。有了指标以后，接口的响应时间分布一目了然。所以我一直强调，做毕设不要只把系统“跑通”当终点，加上 Actuator 的监控能力，会让你的工作方式看起来更像一个有经验的工程师，而不是作业做完了就交的学生。
6. 实测实录：启动、联调、压测过程中最容易翻车的地方
6.1 Spring Boot 版本和 JDK 版本要对号入座
现在用 Spring Boot 3.x 的人越来越多，但很多人一上来就踩版本坑：JDK 8 却用了 Spring Boot 3，项目直接起不来。Spring Boot 3 最低要求 JDK 17，所以你建项目之前，最好先确认自己的 IDE 和 JDK 版本。我推荐直接用 JDK 17 搭配 Spring Boot 3.2.x，这是目前比较稳定且教学资料丰富的组合。
如果你的生产/演示环境只有 JDK 8，那就老老实实用 Spring Boot 2.7.x。两者最主要的区别在于：3.x 基于 Jakarta EE，原来的javax.*包前缀变成了jakarta.*。也就是说用 Spring Boot 3 时，JPA 实体的@Entity、参数校验的@NotNull、Servlet 相关的类，都要从jakarta开头的包导入，别导成javax了，否则启动直接报ClassNotFoundException。这个问题极其常见，我自己刚开始切 Boot 3 时也照着手感导错过，后来排查半天才发现就是包前缀的问题。
6.2 常见问题和排查方法速查表
我整理了下面这个表，是我做这套系统时真实踩过坑的汇总，很多问题在网上的报错帖子中反复出现，可以直接作为排查手册使用。
| 现象 | 原因 | 排查思路 |
|---|---|---|
启动报Failed to configure a DataSource | 没有配置数据源属性，自动配置创建 DataSource 失败 | 检查 application.yml 里 spring.datasource.url/username/password，或排除 DataSourceAutoConfiguration |
| Mapper 接口扫描不到，启动提示找不到 bean | 没有在启动类或配置类上加@MapperScan | 在启动类上扫包：@MapperScan("com.example.hotel.mapper") |
| 接口 POST 请求返回 415 | 前端没传 Content-Type，或者后端没加@RequestBody | 检查请求头 Content-Type 是否为 application/json，Controller 参数是否加了@RequestBody |
请求返回 500：No serializer found | 实体对象里有关联对象懒加载，或字段类型 RedisSerializer 不支持 | Controller 不要直接返回 Entity，序列化为 VO；延迟加载字段不在当前会话内访问 |
| JSON 日期格式是一串数字 | LocalDateTime 默认序列化为数组或时间戳 | 在 application.yml 里配置spring.jackson.date-format，或加@JsonFormat |
| Redis 连接超时 | 没有配置连接超时、Redis 服务没启动、或地址写错 | 先redis-cli ping，确认本地能连通；再检查application.yml中的host和port |
| 跨域请求访问失败 | 前后端分离时，后端未开启 CORS | 写一个 CorsFilter 配置类，或使用@CrossOrigin注解 |
| 打包后运行 jar 包提示没有主清单属性 | 没有使用 spring-boot-maven-plugin 进行 repackage | 在 pom.xml 的 build 节点加入spring-boot-maven-plugin后重新mvn clean package |
| 内存溢出或者频繁 Full GC | 通常是查询没有分页，全表捞出来了 | 数据库查询统一Page分页，检查日志里慢 SQL |
6.3 一些调试心得：怎么定位问题，不走弯路
排查接口问题时，我习惯的路径是：先用浏览器或 Postman 直接调接口，确认请求能到 Controller 吗？如果请求连后端都到不了，问题大概率在路由、跨域或拦截器，而不会在数据库。如果请求到了后端但返回了错误，再去看 IDEA 的 Console 日志，Spring Boot 的默认错误信息通常已经包含了异常类型和出错的代码行号，这一步能省掉大量盲目调试的时间。
有一个很值得养成的习惯：在项目的resources目录下开启 SQL 日志输出。使用 MyBatis-Plus 时，配置：
mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl打开以后，每次执行 SQL 都会在控制台打印，你能清晰看到 MyBatis 帮你拼出来的 SQL 长什么样。很多参数占位符透传、字段名映射错误的问题，看着打印出来的 SQL 就能一眼发现。但是注意，这个配置非常 verbose，调试完以后建议关掉，不然日志刷起来会把真正的错误信息淹没掉。
再一个容易被忽视的点是配置文件多环境切分。我建议做三份配置：application-dev.yml 配本地开发库；application-prod.yml 配演示环境的库；application.yml 只是公共部分，通过spring.profiles.active=dev去激活对应环境。这个动作虽然简单，但它是专业开发的基本习惯。答辩时老师如果问“你怎么管理不同环境的配置”，你就说“用了多 Profile 管理，开发环境一份配置，演示环境一份配置，切换环境只改启动参数”，然后顺手打开 IDEA 的 Program arguments 填--spring.profiles.active=dev给他看，印象分直接拉满。
7. 这套系统背后：Spring Boot 面试最常追问的六个问题
做完这套区域酒店住宿信息系统，你有一个隐性收益是可以把项目里的实际代码作为素材，去应对 Spring Boot 一系列经典面试问题。我在这节把最常被问到、又和这个系统强相关的问题梳理出来，并告诉你怎么用自己的项目切口去讲。
第一个问题：Spring Boot 自动配置的原理是什么？结合这个项目，你可以说“以一个 Shiro 或 MyBatis-Plus 的 starter 为例，它会在 META-INF 下放一个 AutoConfiguration.imports 文件，Spring Boot 启动到自动配置阶段，会从 classpath 扫描这些文件并加载其中声明的自动配置类。在自动配置类里，使用 @ConditionalOnMissingBean 这类条件注解，判断当前应用容器里是否已有某个默认组件，如果没有，则按配置创建默认的组件，比如没有配置数据源就根据 spring.datasource.url 帮你创建一个连接池。整个过程实际上是一种‘规约大于配置’的启发式装配套件”。
第二个问题：Spring Boot 的 Starter 是做什么的。这就是我这套系统里的一个最好例子：引入 MyBatis-Plus starter 后，用户只需要最少量的配置就能拥有 Mapper 扫描、分页插件和依赖注入能力。Starter 本质是 Maven 依赖集合加自动配置类的组合，它的存在让框架之间的集成成本降到了最低。
第三个问题：为什么使用 Redis，以及怎么用它做分布式锁。回答的开头可以先说明这个问题在酒店系统里的来源：“房态库存不能超卖，必须保证并发下单时同一房型的同一天不能被重复售卖”。然后引出分布式锁场景：单体项目可以用 synchronized 锁一段代码，但这种锁只在一个进程内生效，应用多实例部署后就失效，因此需要引入 Redis 的 setnx 命令实现跨进程的锁。回答最后补上一句，锁的 key 设计为“库存维度唯一”，例如room:{roomTypeId}:{date}，value 是请求唯一 ID，配合过期时间防止死锁，释放锁时先校验。如果能完整把这个场景说下来，面试官基本不会再追问这套方案的可行性。
第四个问题：RESTful 接口怎么设计，校验怎么做。你可以用酒店系统里的接口来举例：创建订单 POST /api/orders，查询酒店列表 GET /api/hotels?regionId=xxx，取消订单 PUT /api/orders/{orderNo}/cancel。项目里的参数校验用的是 Spring Validation，入参用 DTO 接收并用 @NotNull、@Size 等注解做声明，Controller 上统一用 @Valid 触发校验，校验失败时会被全局异常处理器捕获并转成统一格式的错误返回。答辩和面试中能把这些细节流畅讲出来，基本就能证明你的接口实践经验是扎实的，而不是只会写“接口 + SQL”的堆砌。
第五个问题：微服务环境和单体之间如何选择。很多人以为简历里写微服务就高级，但实际是要看业务需求的。在做这个区域酒店系统时，我会在面试中强调一点，“从业务规模看它处于单体应用阶段，所以优先采用 Spring Boot 单体架构，保证开发效率和可维护性；同时引入了 Redis、Actuator 监控和模块化设计，这些能力为将来业务量上来后按模块拆分微服务预留了演进空间”。这句话显示了你有架构演进意识，而不是盲目追逐复杂架构。
第六个问题：项目如何做监控与排查。切入点就是我上面讲的 Actuator + Micrometer。你可以说“项目接入 spring-boot-starter-actuator 暴露 health 和 prometheus 端点，Micrometer 统一管理 JVM、HTTP 请求指标，提供给 Prometheus 抓取并展示到 Grafana，如果系统出现接口异常，能通过指标曲线快速定位到是数据库还是 Redis 的瓶颈。”“性能从盲人摸象变成了有据可查”是一个非常接地气且到位的总结。
8. 做完整套系统后，我的一些个人体会
在做这类 Spring Boot 毕设项目的过程中，我最喜欢的一句话是“先跑通，再跑好”。很多人在一开始就纠结到底要不要加 Redis Stream 消息队列，要不要上监控中心，结果是前期选择困难，后期时间紧张，功能草草收场。我的建议是分阶段推进：第一版先实现酒店展示、房态查询、下单支付、后台管理这条主链路，把它跑通，有了可视化页面和操作闭环，项目就已经能打了；第二版再往里面加 Redis 缓存、分布式锁、订单超时取消；第三版如果还有时间，再上 Actuator 监控和操作日志。这样每一期都能交付一个可用版本，无论中间阶段出什么状况，你手里始终有一个成品兜底。
另一个重要心得是：文档和代码不能脱节。无论你是用 Git 管理代码，还是用 Word 写设计论文，都要保证代码里的一些核心决策能够在文档里找到对应的解释。比如你用了订单冗余区域字段，那么在数据库设计说明里最好写一句“因为订单创建后区域归属不会变化，为降低高频区域统计查询的关联成本，这里做了冗余字段设计”；你加了每日房态表，那就写清楚它是为解决日期区间内库存预占并发问题而引入的。这些一句话解释，能让评审者快速理解你的设计意图，也是论文“创新点”写作最自然的素材来源。
最后，我想专门说下答辩演示的准备工作。做这类系统演示时，建议准备一份演示脚本，把你主要想展示的链路固定下来：注册/登录、切换区域树查看不同城市酒店、进入房态页、下单 -> 模拟支付、到后台管理面板修改房型价格、查看订单列表、展示监控面板的指标。遇到断网的情况也不要慌，因为你的核心系统跑在 localhost 上，Redis 和 MySQL 都是本地环境，其实不受外网影响；Prometheus 和 Grafana 那部分如果本地没装，直接把页面截图插到 PPT 里或者提前录屏，也可以达到演示目的。
区域酒店住宿信息系统这个题目，初看不起眼，但真正沉下心做完整套以后你会发现，它几乎把 Spring Boot 日常开发的全部技术栈都覆盖了一遍：Web 层、持久层、缓存、消息队列、分布式锁、可观测性、工程化构建。把这些点逐个吃透，并能在口头讲解时有条理、有依据地表达出来，这套项目的含金量真的不比外面培训班的商业项目差。
