简介：一份基于Java的民宿管理系统毕业设计论文文档，面向计算机相关专业学生、毕业设计选题者及民宿信息化开发人员。文档以SSM框架、Java语言和MySQL数据库为核心技术栈，围绕民宿基本信息管理、预订管理、客户关系管理、财务管理等模块展开设计与论述，同时包含系统安全措施与可行性分析，为同类Web管理系统的设计提供完整参考。包体仅含1个docx文件，大小约924KB，文件为完整论文正文，包含中英文摘要、目录、绪论、相关技术介绍、系统分析等章节，结构清晰，便于直接阅读或二次编辑。目前已有58人浏览学习，适合需要快速了解民宿管理系统设计思路、论文写作框架或SSM框架应用实践的读者参考。
1. 基于Java的民宿管理系统：先搞清楚这不是普通酒店后台
很多人做课程设计或毕业设计时选中“基于java的民宿管理系统设计与实现”，第一反应是“这就是个增删改查”。实际写完一遍就会发现，民宿预订的核心不在CRUD，而在三条主线：房源的按天库存怎么扣、价格日历怎么随节假日浮动、订单状态在取消和退款之间怎么不扯皮。这套系统很适合用来练Spring Boot、MySQL和面向对象设计的完整链路，也能直接改造成可交付的小型民宿后台。这篇笔记按选型、建表、下单、避坑、验证的顺序，把一条能跑通、能答辩、也能接业务的实现路径讲清楚。适合正在做毕设或想快速上手的Java学习者，也适合想看清单体应用边界的熟手。先别急着写代码，把业务闭环想明白再说。
2. 技术选型：为什么是 Spring Boot + MyBatis-Plus，而不是 Servlet 硬写
2.1 民宿业务闭环：多房源、价格浮动和按天库存
民宿和标准酒店的最大区别，是“一间房源在某个日期上只有有限的售卖机会”。酒店可以把200间房按“房型+数量”来管理，民宿则常见一个房东名下有七八套不同位置的房源，每套房源又分出几个房型，每个房型下面可能只有两三间实际可住的房间。于是库存不能用“总数减已售”的静态字段来表达，必须落到“日期+房型+剩余间数”的维度上。
用户端的核心流程是：搜索房源 → 查看房型和价格日历 → 选择入住/离店日期 → 下单 → 支付或等待房东确认 → 入住 → 退房，退房后还可以评价。管理端则要管房源与房型维护、按日期批量调价、接单确认、办理入住、退房结算、以及最基础的入住率和营收统计。两边夹在一起，真正难做的点是“任意日期区间内，同一房型不能被两个订单重叠占用”，以及“取消订单后库存要准确吐回去”。做技术选型时，所有决定都应该围绕这两个目标展开。
2.2 选型对比：Servlet、SSM 与 Spring Boot，为什么选后者
现在做 Java 后端项目，Servlet/JSP 手写一套已经很少见了，它适合拿来讲 HTTP 底层原理，不适合做业务交付。SSM（Spring + Spring MVC + MyBatis）曾经是主流，但配置繁琐：XML 要写数据源、写 SqlSessionFactory、写事务管理器，三个框架版本一旦不对齐就卡很久。Spring Boot 把自动配置和内置 Tomcat 带上之后，开发体验是代际差别，这也是 java 面试题里“为什么用 Spring Boot 而不用 SSM”的标准答案之一。
就民宿管理系统这种规模，Spring Boot + MyBatis-Plus 是当前最常见、最不容易走弯路的组合。MyBatis-Plus 在 MyBatis 之上提供了通用 CRUD、分页插件、逻辑删除，能省下大量重复的 mapper XML。事务一致性用 Spring 的@Transactional声明式事务解决，库存并发用数据库行锁加乐观锁解决，不需要一开始就引入 Redis 这类重组件。面向对象编程 java 的功底在这套系统里也派得上用场：订单状态机可以拆成枚举加状态流转校验，价格计算可以用策略模式按“平日/周末/节假日”切换，套餐与清洁费则适合用模板方法抽象。
| 方案 | 搭建成本 | 内置容器 | 适合场景 |
|---|---|---|---|
| Servlet/JSP | 高，手动处理请求映射 | 需外置 Tomcat | 教学演示、理解 HTTP 底层 |
| SSM | 高，多份 XML 配置 | 需外置 Tomcat | 老项目维护 |
| Spring Boot + MyBatis-Plus | 低，自动配置 | 内置 Tomcat | 单体业务系统、毕设与小型交付 |
版本上我一般这么配：JDK 8 就选 Spring Boot 2.7.x 搭配 MyBatis-Plus 3.5.x，JDK 17 及以上可以上 Spring Boot 3.x。注意 Spring Boot 3 的包名从javax迁到了jakarta，很多老教程代码直接拷贝会编译报错，这个坑在第 5 章单独说。
2.3 最小依赖与项目骨架：pom.xml 和分模块包结构
先看一个能直接启动的基础依赖清单，删掉无关组件，只保留业务真正要用的内容。
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</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>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> </dependencies>spring-boot-starter-web提供了 Spring MVC 和内置 Tomcat，后端接口、静态资源、异常处理都靠它。mybatis-plus-boot-starter帮我们免掉 SqlSessionFactory 的手动配置，同时把分页插件、逻辑删除这些能力带进来。mysql-connector-j是 MySQL 8 的官方驱动，注意旧版mysql-connector-java的坐标已经迁移到这个名字了。spring-boot-starter-validation用来做参数校验，比如预订时入住日期不能晚于离店日期，空指针到处飘的问题一多半可以靠它挡在 Controller 层外。
包结构建议按职责分层，而不是按“页面”分。controller只做参数接收和结果包装，service写业务规则，mapper跟数据库交互，entity对应表结构，dto承载请求和响应参数，vo负责给前端拼装展示层数据。另建一个common包放枚举、统一返回体、业务异常和全局异常处理器。这样的结构在答辩被问“系统怎么保证可扩展性”时，比把代码全塞在 controller 里体面得多。
2.4 数据源与 MyBatis-Plus 配置：一篇能直接跑的 application.yml
资源文件里最核心的是数据源和 MyBatis-Plus 的开关项。
spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/homestay?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.example.homestay.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezone=Asia/Shanghai必加，否则 JDBC 驱动会用服务器默认时区，时间字段出现 8 小时偏移，后面 LocalDate 序列化也会跟着乱。map-underscore-to-camel-case: true让check_in_date自动映射到checkInDate，省掉一堆@TableField注解。logic-delete-field: deleted开启全局逻辑删除，订单取消后我们不物理删除记录，而是打删除标记，统计对账时还能找到原始数据。StdOutImpl是 SQL 日志，开发期开着能看到每一条执行的 SQL，排查慢查询和分页问题非常直观，上线前再关掉。
到这里项目骨架已经能启动了。下一步做数据库设计，这是整个系统最容易返工的地方。
3. 数据库设计：把房型、价格日历和订单区间拆成可靠的表
3.1 表设计的主线：house、room_type、room 三级结构
民宿业务对象要拆成三层：house是房源，代表一套独立的物业，字段包括房东信息、位置、小区、设施描述、清洁费、押金规则；room_type是房型，比如“大床房”“家庭套房”，字段有床型、面积、可住人数、基准价；room是物理房间，落实到具体房间号，一个房型下面可以有多间。
为什么不能把房源和房间合成一张表？因为民宿管理端需要“一套房源下配置多个不同价位的房型”，用户下单时一般只锁房型而不指定具体房号，真正入住时才由前台分配房间。如果一开始就把房间表当成预订主体，后面做“同房型多间房”和“入住分配”都会很被动。room表还承担一个职责：给价格日历的inventory提供初始化数据，一个房型下面有几间可用房间，价格日历里的可售间数初始值就是几。
3.2 价格日历表：民宿价格建模的核心，不用“每晚均价”
民宿价格不是固定的，周末、节假日、连住打折都影响成交价。如果只在房型表里存一个“每晚均价”，订单金额就只能按“均价 × 晚数”算，节假日调价和淡旺季活动全部没法做。常见做法是单独维护一张price_calendar表，每个房型每天一行。
字段上至少要有id、room_type_id、date、price、inventory、status、version。price是当晚单价，单位用分存整数，避免浮点误差；inventory表示当天还可售几间，下单时扣 1，取消时回滚加 1；status控制这天是否开售，比如淡季可以直接停售；version是乐观锁用的版本号，并发扣库存时靠它防超卖。管理端调价时按日期区间批量更新，比如把 5 月 1 日到 5 月 3 日的价格统一改为 668 元，一次 SQL 就能完成，这也是后台系统里最常用的操作。
3.3 订单表与日期明细：区间查询的索引设计
订单主表orders保存一笔预订的摘要信息：订单号、用户、房源、房型、入住日期、离店日期、晚数、间数、应付总额、状态、创建时间、支付时间。这里有一个容易被忽略的点：民宿订单的“区间占用”无法用数据库唯一约束直接表达，两笔订单可能下单日期完全不同但住的是重叠的夜晚。所以查询有没有冲突订单，必须用“入住日期小于目标离店日期且离店日期大于目标入住日期”的区间重叠条件。
订单明细表order_date_detail按每晚存一条记录，包含订单号、日期、当晚单价、状态。这张表的价值在于价格快照：下单时把每晚单价固化下来，之后改价不会影响已支付订单，退款时也可以按晚精确分摊。索引设计上，orders表要建(room_type_id, status, check_in_date, check_out_date)联合索引支撑重叠查询，price_calendar表建(room_type_id, date)唯一索引保证每天只有一条价格数据，“改了重复日期插不进”这层约束由数据库兜底。
CREATE TABLE house ( id BIGINT PRIMARY KEY AUTO_INCREMENT, owner_id BIGINT NOT NULL COMMENT '房东用户ID', name VARCHAR(64) NOT NULL COMMENT '房源名称', address VARCHAR(128) NOT NULL COMMENT '地址', description VARCHAR(512), clean_fee INT DEFAULT 0 COMMENT '清洁费(分)', status TINYINT DEFAULT 1 COMMENT '1上架 0下架', deleted TINYINT DEFAULT 0, create_time DATETIME, update_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='民宿房源'; CREATE TABLE room_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, house_id BIGINT NOT NULL, name VARCHAR(32) NOT NULL COMMENT '大床房/双床房等', bed_type VARCHAR(32), area INT, max_guests INT DEFAULT 2, base_price INT NOT NULL COMMENT '基准价(分)', deleted TINYINT DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房型'; CREATE TABLE price_calendar ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_type_id BIGINT NOT NULL, date DATE NOT NULL, price INT NOT NULL COMMENT '当晚单价(分)', inventory INT NOT NULL COMMENT '可售间数', status TINYINT DEFAULT 1 COMMENT '1可售 0停售', version INT DEFAULT 0, UNIQUE KEY uk_room_date (room_type_id, date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='价格日历'; CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, house_id BIGINT NOT NULL, room_type_id BIGINT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, nights INT NOT NULL, total_price INT NOT NULL COMMENT '总价(分)', status TINYINT NOT NULL COMMENT '订单状态', deleted TINYINT DEFAULT 0, create_time DATETIME, pay_time DATETIME, UNIQUE KEY uk_order_no (order_no), KEY idx_room_status_date (room_type_id, status, check_in_date, check_out_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表'; CREATE TABLE order_date_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, date DATE NOT NULL, price INT NOT NULL, status TINYINT DEFAULT 0, KEY idx_order_no (order_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单日期明细';建表时金额字段全部用整数存“分”，在 Java 里对应Integer或Long。用BigDecimal存金额在展示时确实直观，但涉及 SUM、比较和分页排序时容易出现精度与索引问题，实际项目中我更愿意在 SQL 里除以 100 转成元，或者统一在 VO 层转换。表名和字段用下划线命名，配合 MyBatis-Plus 的驼峰映射，实体类里可以直接写checkInDate。
4. 核心功能实现：订单状态机和库存扣减的落地写法
4.1 订单状态机：从待付款到已入住的流转与取消
订单在民宿场景里不是一个“下单就有”的线性过程。很多民宿由房东人工接单，所以订单要先经历“待房东确认”。常规状态我拆成六个：待支付、待确认、已确认、入住中、已完成、已取消，再单独加一个已退款作为资金回流的终点。用 Java 枚举管理这些状态，比在业务代码里到处写魔法数字可靠得多。
| 当前状态 | 触发操作 | 下一状态 | 是否回滚库存 |
|---|---|---|---|
| 待支付 | 用户支付 | 待确认 | 否 |
| 待确认 | 房东确认 | 已确认 | 否 |
| 已确认 | 办理入住 | 入住中 | 否 |
| 入住中 | 退房结算 | 已完成 | 否 |
| 待支付 | 用户取消 | 已取消 | 是 |
| 待确认 | 用户取消 / 房东拒绝 | 已取消 | 是 |
| 已确认 | 用户取消并退款 | 已退款 | 是 |
任何状态下取消并发生了资金往来，都要进入已退款，而不是直接变成已取消。这样财务对账时，“已取消”只代表未支付订单的作废，“已退款”代表钱退过。状态之间不要允许任意跳转，比如入住中直接改成已完成是合理的，但待支付直接改成已完成就一定是 bug。状态机逻辑可以封装在一个独立方法里，统一校验当前状态和目标状态是否匹配，再执行更新、回滚库存、记录流转日志这三个动作。
4.2 库存扣减方案对比：区间锁、乐观锁与 Redis 的取舍
库存扣减是民宿系统里 java 面试题常考的高频场景，本质是“多用户同时抢同一个日期区间怎么不超卖”。常见做法有三种。
第一，下单时直接对price_calendar行执行乐观锁更新：UPDATE ... SET inventory = inventory - 1, version = version + 1 WHERE id = ? AND inventory > 0 AND version = ?。这种方式简单直接，但只解决了当天库存这一行的原子性，拦不住“两笔订单分别占用相邻日期、中间夹着同一晚”的区间重叠问题。
第二，事务内先锁 价格日历行，再查重叠订单，最后扣减库存。锁行用SELECT ... FOR UPDATE，重叠订单用区间条件判断。这个方案在单体应用和中小并发下足够可靠，也是目前最稳的落地方案。
第三，引入 Redis 预占库存、异步落库。性能最好，但需要处理 Redis 宕机、数据回滚、预占超时释放等一系列问题，改造和排查成本高。民宿预订的并发量远达不到需要 Redis 扛峰值的程度，毕设和中小型交付用第二种方案就够，别为了炫技把系统搞成分布式。
4.3 下单核心 Java 实现：事务里完成校验、锁行与扣减
我先把下单流程压缩成一段可运行的核心逻辑，关键路径都写在注释里。
@Service public class OrderServiceImpl implements OrderService { @Resource private PriceCalendarMapper priceCalendarMapper; @Resource private OrderMapper orderMapper; @Resource private OrderDateDetailMapper orderDateDetailMapper; @Override @Transactional(rollbackFor = Exception.class) public OrderCreateVO createOrder(OrderCreateDTO dto) { // 1. 基础校验：日期必须合法 if (dto.getCheckInDate().isAfter(dto.getCheckOutDate())) { throw new BizException("入住日期不能晚于离店日期"); } LocalDate checkIn = dto.getCheckInDate(); LocalDate checkOut = dto.getCheckOutDate(); // 2. 锁住整个入住区间的价格日历行，防止并发改价和并发扣库存 List<PriceCalendar> calendars = priceCalendarMapper .lockBatchByRoomTypeAndDateRange(dto.getRoomTypeId(), checkIn, checkOut); if (calendars.size() != ChronoUnit.DAYS.between(checkIn, checkOut)) { throw new BizException("所选日期有停售或未配置价格的时段"); } // 3. 校验每晚都有库存 boolean stockEnough = calendars.stream() .allMatch(c -> c.getInventory() != null && c.getInventory() > 0); if (!stockEnough) { throw new BizException("所选日期房源已被预订"); } // 4. 区间重叠校验：已有订单占用即拒绝 int overlapCount = orderMapper.countOverlapOrders( dto.getRoomTypeId(), checkIn, checkOut, OrderStatus.PENDING_CONFIRM.getCode(), OrderStatus.CONFIRMED.getCode(), OrderStatus.CHECKED_IN.getCode()); if (overlapCount > 0) { throw new BizException("所选日期与已有订单冲突"); } // 5. 逐日扣减库存，乐观锁兜底 calendars.forEach(c -> { int affected = priceCalendarMapper.decreaseStock(c.getId(), c.getInventory()); if (affected == 0) { throw new BizException("库存扣减失败，请重试"); } }); // 6. 保存订单主表 String orderNo = "HS" + System.currentTimeMillis(); Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setRoomTypeId(dto.getRoomTypeId()); order.setCheckInDate(checkIn); order.setCheckOutDate(checkOut); order.setNights((int) ChronoUnit.DAYS.between(checkIn, checkOut)); order.setTotalPrice(calcTotalPrice(calendars)); order.setStatus(OrderStatus.PENDING_PAY.getCode()); orderMapper.insert(order); // 7. 保存每晚价格快照 calendars.forEach(c -> { OrderDateDetail detail = new OrderDateDetail(); detail.setOrderNo(orderNo); detail.setDate(c.getDate()); detail.setPrice(c.getPrice()); orderDateDetailMapper.insert(detail); }); OrderCreateVO vo = new OrderCreateVO(); vo.setOrderNo(orderNo); vo.setTotalPrice(order.getTotalPrice()); return vo; } private Long calcTotalPrice(List<PriceCalendar> calendars) { return calendars.stream() .mapToLong(PriceCalendar::getPrice) .sum(); } }步骤 2 的lockBatchByRoomTypeAndDateRange对应的 SQL 是SELECT * FROM price_calendar WHERE room_type_id = ? AND date >= ? AND date < ? AND status = 1 FOR UPDATE。加FOR UPDATE的目的是把区间内的所有日历行在当前事务里锁住，另一个并发事务如果也来下单，会在这一步阻塞，等前一个事务提交或回滚后再继续，从根上挡住区间冲突。
步骤 4 的重叠判断条件是核心：目标入住日期记为newCheckIn，目标离店日期记为newCheckOut，已有订单只要满足check_in_date < newCheckOut AND check_out_date > newCheckIn就说明两个区间有交集。这里务必用<和>，不要用<=和>=，否则相邻订单会被误判为冲突。订单状态过滤只统计仍然有效的待确认、已确认和入住中，已取消和已完成都释放了日期占用。
@Transactional(rollbackFor = Exception.class)声明了整个方法作为一个事务，任何一步抛异常，前面扣掉的库存都会自动回滚，不会出现“订单创建失败但库存少了”的脏数据。这个方法把“数据一致性”这个抽象概念落到了具体代码上，也是答辩时最值得展开讲的一段。
4.4 报表统计：入住率与营收的几条 SQL
管理端报表是整个系统的门面，常见统计口径有两个：入住率和营收。入住率不建议用“订单数除以房型总数”这种粗口径，正确的分母是“可售间夜数”，即每个房型每天的可售间数累加；分子是实际产生的有效占用间夜数，包含已确认、入住中、已完成三种状态的订单。
-- 按月统计各房型入住率 SELECT DATE_FORMAT(dd.date, '%Y-%m') AS month, o.room_type_id, COUNT(dd.id) AS occupied_nights, (SELECT COUNT(*) FROM price_calendar pc WHERE pc.room_type_id = o.room_type_id AND DATE_FORMAT(pc.date, '%Y-%m') = DATE_FORMAT(dd.date, '%Y-%m') AND pc.status = 1) AS sellable_nights FROM order_date_detail dd JOIN orders o ON o.order_no = dd.order_no WHERE o.status IN (2, 3, 4) GROUP BY month, o.room_type_id;需要注意，order_date_detail是按晚拆分的明细，所以用它做间夜统计最准确。营收则直接聚合并过滤掉退款订单的差额，口径要和财务一致，否则后台显示的营收和房东实际收到的钱对不上。
5. 避坑：民宿管理系统开发中的 5 个高频翻车点
5.1 翻车点一：Spring Boot 3 用了 JDK 8，项目都起不来
现象：本地 java 环境是 1.8，pom 里引入的却是spring-boot-starter-parent3.x，启动时报UnsupportedClassVersionError，提示 class 文件由更高版本 JDK 编译。即使能启动，代码里import javax.servlet也直接编译报错，因为 Spring Boot 3 已经把包名迁到了jakarta.servlet。
原因：Spring Boot 3 要求 JDK 17 及以上，javax命名空间整体迁移到了jakarta。网上大量教程仍然基于 Spring Boot 2.x 写的是javax，直接照抄就翻车。老项目里也常见 IDE 编译级别配了 17，但命令行环境JAVA_HOME还指向 8，两边不一致启动就玄学报错。
解决：先看java -version和echo $JAVA_HOME确认当前生效的 JDK。JDK 8 就老老实实用 Spring Boot 2.7.x，JDK 17 再用 3.x。下载 JDK 时到正规官网选对应主版本，注意新版安装包不再自动写环境变量，需要手动补JAVA_HOME和PATH，配完重启命令行窗口再验证。
5.2 翻车点二：LocalDate 存成 Datetime，JSON 序列化与统计全乱
现象：价格日历表里日期字段建的是datetime，实体类用的是LocalDate。前端查询某一天的房价，接口返回的不是目标日期，而是带T00:00:00的午夜时间戳；按日分组统计时还会出现“日期差 8 小时”导致数据落到前一天或后一天。
原因：JDBC 驱动在datetime字段和LocalDate之间转换时会经过Timestamp，而Timestamp带时区语义，数据源 URL 里没有配置serverTimezone时，驱动取的是 JVM 默认时区。前后端 JSON 序列化时，LocalDateTime 和 LocalDate 的默认格式也不一致，导致展示层看到的是一长串带 T 的字符串。
解决：纯日期字段统一用DATE类型对应 Java 的LocalDate，时间字段才用DATETIME对应LocalDateTime。数据源 URL 加serverTimezone=Asia/Shanghai，Jackson 全局配置里把LocalDate的序列化格式固定为yyyy-MM-dd，LocalDateTime固定为yyyy-MM-dd HH:mm:ss。这样下单、报表、对账三个环节看到的日期完全一致。
5.3 翻车点三：取消订单不回滚库存，民宿越卖越少
现象：用户下单支付后取消，订单状态变成了已取消，但价格日历里对应日期的inventory没有加回来。连续几天有人取消，后台看订单明明不多，前台却显示无房可订，旺季这种问题直接损失订单。
原因：下单时扣减库存的逻辑写在createOrder里，但取消订单在另一个方法里只更新了订单状态，没有补偿库存。这个本质上是缺少“资金回流与库存回滚联动”的补偿事务。还有更隐蔽的：用户重复点击取消按钮，同一个订单被回滚两次，库存反而多了。
解决：取消和退款必须是带状态校验的补偿事务，方法上加@Transactional，先通过状态判断当前是否允许取消，再更新订单状态，最后执行UPDATE price_calendar SET inventory = inventory + 1 WHERE id = ?。状态用枚举限制后，重复请求在第一步就被拦截，不会二次回滚。如果订单已经入住，取消操作应该禁止，只能走退房结算。
5.4 翻车点四：MyBatis-Plus 分页插件没注册，报表全表扫
现象：管理端报表使用selectPage查询订单列表，返回的total一直是 0，数据看起来只有第一页。把 SQL 日志打开后，发现执行的语句里根本没有LIMIT关键字，而是把全表数据查出来后在内存里包装了一下。
原因：MyBatis-Plus 的分页功能依赖拦截器PaginationInnerInterceptor，没有在配置类里注册这个 bean 时，分页方法不会拼接数据库层的LIMIT。项目里如果只有一个简单查询，数据量小注意不到，但订单和价格日历表一旦上了万行，报表接口就会越来越慢，属于典型的“黑匣子”问题。
解决：新建一个MybatisPlusConfig配置类，注册MybatisPlusInterceptor并追加PaginationInnerInterceptor，数据库类型指定为DbType.MYSQL。分页拦截器要放在拦截器链的第一位，避免和其他插件冲突。配置完成后回头看日志，应该能看到LIMIT ?参数，这就是分页真正生效的证据。
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }5.5 翻车点五：价格日历改价穿透已付款订单，被用户投诉
现象：运营在后台把 5 月 3 日的房价从 488 改成 688，结果当天已经付款的订单在退房结算时总价也变成了 688。用户拿着支付记录来对账，前后台价格对不上，财务只能手工退款补差。
原因：订单表里只存了一个总价，没有保存每晚单价快照，结算或展示时又去查最新的价格日历，导致价格变动直接穿透到历史订单。这是民宿系统里最典型的设计失误。
解决：下单时把每晚单价固化到order_date_detail.price，所有结算、退款、报表都从这个明细表取数，不再查实时价格。管理后台做改价操作时再加上一道校验：只允许修改“当前无有效订单占用”的日期，如果有订单，要么保留原价，要么在页面上提示运营这笔日期会按快照结算。价格日历加version字段后，配合事务内锁行，还能防止改价和下单同时发生时互相覆盖。
6. 交付验证：回归清单与一个让并发问题现形的压测小技巧
6.1 回归测试清单：按订单生命周期过一遍
系统开发完不要急着写论文，先按订单生命周期走一遍回归。我把每轮必测的场景列成清单，放在手边随时对照。
| 测试场景 | 输入与操作 | 预期结果 | 常见失败点 |
|---|---|---|---|
| 价格展示 | 查询 5.1-5.3 价格日历 | 每天单价正确，停售日不展示 | 日期差 8 小时、价格取错 |
| 正常下单 | 预订 5.1-5.2 大床房 | 订单生成，库存减 1，明细有每晚价格 | 库存未扣、快照缺失 |
| 重叠预订 | 同房型再订 5.1-5.2 | 提示日期冲突，事务回滚 | 区间判断用了<= |
| 取消退款 | 取消已支付订单 | 状态变已退款，库存加回 | 重复取消导致库存双加 |
| 入住登记 | 已确认订单办入住 | 状态变入住中，分配房间 | 状态跳转未校验 |
| 退房结算 | 入住中订单退房 | 生成账单，状态变已完成 | 总价与快照不一致 |
| 报表统计 | 按当月房源统计 | 入住率、营收与订单明细对得上 | 口径混乱、退款未排除 |
6.2 并发不超卖的验证：一个能直接跑的并发脚本
界面上手工点几次看不出来并发问题，我用CountDownLatch写一个最朴素的并发测试：同一时刻放 20 个线程同时抢同一个日期区间，断言最终库存不少于应有的初始值减 1，订单表里成功创建的订单只有 1 笔。
int threadCount = 20; CountDownLatch ready = new CountDownLatch(threadCount); CountDownLatch start = new CountDownLatch(1); CountDownLatch done = new CountDownLatch(threadCount); for (int i = 0; i < threadCount; i++) { new Thread(() -> { ready.countDown(); try { start.await(); orderService.createOrder(dto); // 同一房型、同一日期区间 } catch (Exception e) { // 预期内大量冲突异常 System.out.println(e.getMessage()); } finally { done.countDown(); } }).start(); } ready.await(); start.countDown(); done.await(); // 对账：价格日历库存 + 有效订单数 = 初始可售数跑完之后不要只看异常数量，还要执行一条对账 SQL：把价格日历当天的inventory加上有效订单的占用间夜数，必须等于初始可售数。这条 SQL 才是判定系统没有超卖、没有少卖的唯一证据。我在这套系统的开发中最后悔的就是先写业务代码再补状态机，后来为了改取消回滚、价格快照重写了将近一半的接口。先把状态流转和价格快照定死在设计里，再动手写 Java，需要吃的后悔药会少很多。希望帮到你。
本文还有配套的精品资源，点击获取
