简介一份基于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 底层原理不适合做业务交付。SSMSpring 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.xJDK 17 及以上可以上 Spring Boot 3.x。注意 Spring Boot 3 的包名从javax迁到了jakarta很多老教程代码直接拷贝会编译报错这个坑在第 5 章单独说。2.3 最小依赖与项目骨架pom.xml 和分模块包结构先看一个能直接启动的基础依赖清单删掉无关组件只保留业务真正要用的内容。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.5/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependenciesspring-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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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: 0serverTimezoneAsia/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取消时回滚加 1status控制这天是否开售比如淡季可以直接停售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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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. 锁住整个入住区间的价格日历行防止并发改价和并发扣库存 ListPriceCalendar 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(ListPriceCalendar 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.8pom 里引入的却是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.xJDK 17 再用 3.x。下载 JDK 时到正规官网选对应主版本注意新版安装包不再自动写环境变量需要手动补JAVA_HOME和PATH配完重启命令行窗口再验证。5.2 翻车点二LocalDate 存成 DatetimeJSON 序列化与统计全乱现象价格日历表里日期字段建的是datetime实体类用的是LocalDate。前端查询某一天的房价接口返回的不是目标日期而是带T00:00:00的午夜时间戳按日分组统计时还会出现“日期差 8 小时”导致数据落到前一天或后一天。原因JDBC 驱动在datetime字段和LocalDate之间转换时会经过Timestamp而Timestamp带时区语义数据源 URL 里没有配置serverTimezone时驱动取的是 JVM 默认时区。前后端 JSON 序列化时LocalDateTime 和 LocalDate 的默认格式也不一致导致展示层看到的是一长串带 T 的字符串。解决纯日期字段统一用DATE类型对应 Java 的LocalDate时间字段才用DATETIME对应LocalDateTime。数据源 URL 加serverTimezoneAsia/ShanghaiJackson 全局配置里把LocalDate的序列化格式固定为yyyy-MM-ddLocalDateTime固定为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需要吃的后悔药会少很多。希望帮到你。本文还有配套的精品资源点击获取