简介基于SpringBoot的民宿管理平台系统毕业设计全套资源包内含完整源码、数据库脚本、系统文档与答辩PPT面向正在完成毕业设计的大学生或希望上手Java Web开发实战的学习者。资源共832个文件以Java后端代码、Vue前端组件、JavaScript逻辑、SQL数据库脚本以及HTML/CSS样式为主同时提供安装启动批处理和运行命令压缩包整体约24.66MB目录结构清晰便于按模块检索。系统围绕管理员、用户、商家三类角色设计了民宿信息管理、房间类型与信息维护、预订与退订流程、投诉反馈处理、个人收藏管理等核心模块前台页面还集成了在线客服完整演示了SpringBoot与Vue前后端分离项目的开发思路。文档部分详细说明需求分析、数据库设计和功能模块PPT可用于答辩汇报与项目展示代码注释相对完整可导入主流IDE快速部署运行也能作为二次开发的基础。当前已有114人学习对毕业设计选题、工程实践或求职作品积累均具有实用参考价值。1. 民宿管理平台的复杂度不在功能多而在订单与房态的状态流转“基于SpringBoot的民宿管理平台系统”这个名字听起来像是又一个增删改查练习但真正动手把表建出来、把接口写完才发现民宿和酒店最大的区别在于“同一房源有多间房但每间房的售卖单元是“夜”而不是“间”。一个用户要订 6 月 1 日到 6 月 3 日的大床房系统要同时判断这一天哪几间房可订、价格是平日价还是周末价、订单取消后房态何时释放。这些逻辑全部压在数据库设计和订单状态机上SpringBoot 只负责把业务串起来。这篇文章从建表、分层实现、鉴权上传到部署排查把一套可直接落地的民宿后台的实现路径讲清楚适合正在做课程设计或准备接手这类业务系统的开发者看完能直接照着把工程跑起来也能看懂别人项目里的代码为什么要这么写。2. 表结构先行房态、订单与价格的关系怎么落库2.1 核心五张表从房间到订单的关联路径民宿系统的数据模型不能照搬电商订单因为电商卖的是库存商品而民宿卖的是某房间在某时间段的使用权时间是核心维度。我习惯先拆出五张基础表用户表、民宿表、房间表、房间价格表、订单表其中民宿表和房间表是一对多房间表和价格表是一对多。订单表不直接关联民宿而是通过房间 id 反查民宿这样后续做民宿维度的订单统计时少一次 join。有一个容易忽略的点价格表不要只存一个原价字段。民宿的价格往往按星期变化周五周六是峰值价节假日可能还有独立价格。常见做法是价格表里存date、price_type、price三个字段price_type用来标记平日价、周末价或节假日价。这样用户在选日期范围时可以按日期逐天取价格而不是取一个均价。要注意的是如果入住跨周末订单总额是逐日价格之和这一逻辑要在 Service 层算不能依赖 SQL 的sum简单带过因为还要叠加优惠和押金。订单表是核心中的核心字段上除了常见的order_no、user_id、room_id必须要有check_in_date、check_out_date、total_price、status这四个。check_out_date在业务上是不包含在住宿内的比如 6 月 1 日入住、6 月 3 日退房实际占用的是 1 日和 2 日两晚这直接决定后续的房态冲突校验怎么写。status字段用 int 类型存储拒绝用字符串因为状态既要参与数据库索引又要做数值比较。表名核心字段职责userid, username, password, phone用户与登录凭证homestayid, name, address, location民宿基本信息与定位roomid, homestay_id, room_no, capacity物理房间同一民宿下多间room_priceid, room_id, date, price_type, price按日价格支持周末价ordersid, order_no, user_id, room_id, check_in_date, check_out_date, total_price, status订单与房态依赖的核心2.2 订单状态机与数据库同步状态为什么放订单表而不放房间表很多初学设计者会把房态设计成房间表的一个字段比如room_status 0表示空闲、1表示已订。这个方案在单机小程序里能跑但一旦出现“一个房间未来 7 天有 3 天被订”的场景单个状态字段就完全不够用。正确做法是房态不落库而是通过订单动态推导只要在目标日期范围内存在有效状态的订单则该房间在该日期不可订。这里“有效状态”是关键已取消的订单必须排除在外。订单的状态流转建议控制为五个状态待支付、已支付、入住中、已完成、已取消。待支付和已取消是“不占房”的状态已支付和入住中是“占房”状态。这就引出一个最关键的业务规则创建订单时如果只是生成一条待支付记录那房间应该立刻被锁住防止另一个用户同时下单同一房间。很多系统在支付回调里才涨房态结果会出现两个待支付订单同时存在、先支付的人反而被拒绝的情况。我的处理方式是订单状态为待支付即视为预占资源但在订单表上加一个lock_expire_time字段比如 15 分钟未支付自动把状态置为已取消并用定时任务扫描过期订单。这个字段表面上是一个时间戳实际是分布式环境下的锁租约比单独用 Redis 加锁再额外同步数据库要简单得多。2.3 建表 SQL预留索引和唯一约束的关键写法下面给出订单表和价格表的核心建表语句注意索引和默认值的设计CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint(20) NOT NULL, room_id bigint(20) NOT NULL, check_in_date date NOT NULL, check_out_date date NOT NULL, total_price decimal(10,2) NOT NULL DEFAULT 0.00, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2入住中 3已完成 4已取消, lock_expire_time datetime DEFAULT NULL COMMENT 待支付订单锁房到期时间, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_room_date (room_id, check_in_date, check_out_date), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT民宿订单表; CREATE TABLE room_price ( id bigint(20) NOT NULL AUTO_INCREMENT, room_id bigint(20) NOT NULL, price_date date NOT NULL, price_type tinyint(4) NOT NULL DEFAULT 0 COMMENT 0平日 1周末 2节假日, price decimal(10,2) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_room_date (room_id, price_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房间每日价格表;uk_room_date这个唯一约束特别重要它保证同一个房间同一天只能有一条价格记录。后台在导入价格时可以直接用insert ... on duplicate key update做幂等不需要先查一遍再决定插入还是更新。订单表上的idx_room_date是房态查询的核心索引校验某房间在某个日期段是否可用时SQL 会先按room_id过滤再对日期范围做 range 扫描效率远高于单独查room_id索引后逐条比对。有一点要注意check_out_date在索引里排在最后如果查询条件里只有room_id加check_in_date这个索引依然能走只是check_out_date参与因果有限这在数据量超过十万条后才会感受到差别前期不用过度优化。3. SpringBoot 分层落地从 Controller 到 Mapper 的增删改查骨架3.1 工程结构与 SpringBoot 版本怎么定代码组织上我不建议用网上那种一个controller包下面挂着几百行业务代码的写法。民宿系统的核心是订单业务推荐按模块分包即controller、service、mapper保持三层但service下按order、room、user再拆一层每个模块的接口和实现分开。Controller 层只做参数接收和简单校验业务逻辑全部下沉到 Service这样后续写单元测试能直接跳过 Web 层。SpringBoot 版本选择有一个容易被新手忽略的问题不要一上来就拉最新版。SpringBoot 3.x 要求 JDK 17且 jakarta 命名空间与 2.x 完全不同很多教材里的javax.servlet代码在 3.x 下会直接编译失败。如果本地环境是 JDK 8老老实实选 SpringBoot 2.7.x这是 2.x 系列的最后一个维护版本稳定且资料多。如果要用 JDK 17那再上 3.x。springboot 整合 MyBatis 时还要注意2.7.x 对应 mybatis-spring-boot-starter 2.3.x而 3.x 对应 3.0.x版本配错会出现Invalid value type for attribute factoryBeanObjectType这类启动异常。3.2 创建订单的核心逻辑时间冲突与超卖创建订单是整个系统最需要业务深度的接口。先校验用户登录态再校验房间存在且未下架然后做两个核心判断一是订单时间是否合法二是目标时间段内房间是否可售。下面的代码是 Service 里的核心方法刻意省略了 Controller 包装Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 入参校验入住日期必须在退房日期之前 if (!dto.getCheckInDate().isBefore(dto.getCheckOutDate())) { throw new BizException(入住日期必须早于退房日期); } LocalDate today LocalDate.now(); if (dto.getCheckInDate().isBefore(today)) { throw new BizException(不能预订过去的日期); } // 2. 查询该房间在入住区间内的所有有效订单 ListOrders conflictOrders ordersMapper.selectConflictOrders( dto.getRoomId(), dto.getCheckInDate(), dto.getCheckOutDate(), Arrays.asList(OrderStatus.PAID, OrderStatus.CHECKED_IN)); if (!CollectionUtils.isEmpty(conflictOrders)) { throw new BizException(该时间段房间已被预订); } // 3. 计算总价逐日取价格并累加 ListRoomPrice priceList roomPriceMapper.selectByRoomIdAndDateRange( dto.getRoomId(), dto.getCheckInDate(), dto.getCheckOutDate()); BigDecimal totalPrice BigDecimal.ZERO; for (LocalDate d dto.getCheckInDate(); d.isBefore(dto.getCheckOutDate()); d d.plusDays(1)) { BigDecimal price priceList.stream() .filter(p - p.getPriceDate().equals(d)) .map(RoomPrice::getPrice) .findFirst() .orElseThrow(() - new BizException(该日期未配置价格)); totalPrice totalPrice.add(price); } // 4. 生成订单号并落库状态为待支付 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setRoomId(dto.getRoomId()); order.setCheckInDate(dto.getCheckInDate()); order.setCheckOutDate(dto.getCheckOutDate()); order.setTotalPrice(totalPrice); order.setStatus(OrderStatus.WAIT_PAY); order.setLockExpireTime(LocalDateTime.now().plusMinutes(15)); ordersMapper.insert(order); return convertToVO(order); }selectConflictOrders的 SQL 就是前面idx_room_date索引发挥作用的地方条件写成check_in_date #{endDate} AND check_out_date #{startDate}这是判断日期区间是否相交的通用写法。注意不能写成等值匹配因为订单 A 是 6 月 1 日到 3 日订单 B 是 3 日到 5 日B 的入住日恰好等于 A 的退房日两者不冲突只有交叉才冲突。Transactional保证订单写入和状态变更在同一事务里避免出现订单生成成功但锁房状态未同步的情况。这里的价格逐日累加逻辑比一次性取一个平均价再乘天数要严谨得多因为周末价和节假日价的存在会导致金额误差。3.3 分页查询与多条件筛选MyBatis-Plus 的 QueryWrapper 用法民宿后台最常见的操作是订单列表按状态、日期范围、民宿名称筛选这属于典型的多条件动态查询。手写动态 SQL 能完成但代码非常啰嗦用 MyBatis-Plus 的QueryWrapper可以大幅简化同时保持可读性public PageResultOrderVO pageOrders(OrderQueryDTO query) { PageOrders page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperOrders wrapper new LambdaQueryWrapper(); wrapper.eq(query.getStatus() ! null, Orders::getStatus, query.getStatus()) .ge(query.getStartDate() ! null, Orders::getCheckInDate, query.getStartDate()) .le(query.getEndDate() ! null, Orders::getCheckInDate, query.getEndDate()) .orderByDesc(Orders::getCreateTime); PageOrders ordersPage ordersMapper.selectPage(page, wrapper); // 手动做关联查询填充用户名和民宿名避免在 SQL 里写死 join return convertToPageResult(ordersPage); }.eq和.ge的第一个参数是 boolean 条件只有当前端传入了对应参数时才拼接这条条件这是动态筛选的核心。这里有意不写 join而是分两次查询去填充用户名和民宿名原因是订单表数据量大后join 会让分页 count 查询变慢拆成两次查询后每次都可以走独立索引对后台管理系统来说用户体验更好。如果确实需要订单表和房间表实时联查也会把 join 写成子查询而不是笛卡尔积式的关联这一点是写 Mapper XML 时容易踩的坑。4. 登录鉴权、图片上传与打包部署4.1 用拦截器做轻量登录鉴权不引 Spring Security 的理由民宿管理系统的用户角色通常只有管理员和普通用户两种权限模型非常简单引入 Spring Security 反而带来配置复杂度。登录接口先校验用户名密码成功后签发 JWT Token前端后续请求在 Header 里带上 Token后端用拦截器统一解析。这里用拦截器而不是过滤器因为拦截器能拿到 HandlerMethod可以针对不同接口做细粒度的权限判定。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !token.startsWith(Bearer )) { throw new BizException(未登录或登录已过期); } // 解析 JWT把 userId 放入 ThreadLocal方便 Controller 直接取用 Long userId JwtUtil.parseToken(token.substring(7)); UserContext.set(userId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }拦截器里只解析 Token 和校验有效期不做数据库查询这样能保证高并发场景下鉴权逻辑本身不成为瓶颈。UserContext是一个ThreadLocal封装注意在afterCompletion里必须清理否则线程池复用时会读到上一个请求的用户数据这是线上最容易出现的隐蔽 bug。Token 过期时间一般设为 2 小时管理后台可以延长到 24 小时但不要用永久 Token这种偷懒方案。4.2 图片上传与静态资源映射房间图为什么存磁盘不存库民宿后台必然涉及房间图片上传这里推荐一个比较务实的做法图片文件存本地磁盘或对象存储数据库只存 URL 路径。很多人把图片转成 Base64 直接存进 MySQL 的longtext字段这种做法的查询性能和存储成本都很差。配置层面最简单的方式是在application.yml里声明上传路径并注册静态资源映射spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB mvc: static-path-pattern: /upload/** web: resources: static-locations: file:D:/homestay/upload/static-locations指定磁盘物理路径后访问http://ip:8080/upload/room/xxx.jpg就能直接映射到D:/homestay/upload/room/xxx.jpg。上传接口接收MultipartFile后文件名不要用原始文件名用UUID 后缀重命名避免中文名乱码和路径穿越攻击。图片上传后返回相对路径前端拼上baseUrl就能展示。如果是部署到 Linux把路径改成/home/homestay/upload/即可这是 springboot 配置里最值得记住的一处。4.3 Linux 部署jar 直接跑还是配 nginx 反代后台管理系统打包成 jar 后部署是最省事的方案但生产环境我一般会搭配 nginx 做反向代理。nginx 负责监听 80 端口、转发/api/前缀到 SpringBoot 的 8080同时直接托管前端静态资源这样前后端共用一个域名避免了跨域问题。启动脚本用nohup java -jar时务必加上 JVM 参数nohup java -Xms256m -Xmx512m -jar homestay-admin-1.0.0.jar \ --spring.profiles.activeprod \ --server.port8080 \ --spring.datasource.urljdbc:mysql://localhost:3306/homestay?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai \ /logs/homestay.log 21 -Xms和-Xmx设置为相同值可以避免 JVM 运行期动态申请内存带来的性能抖动512MB 对于这套系统足够了。serverTimezoneAsia/Shanghai一定要显式声明否则插入数据库的日期时间会和本地时间差 8 小时这是 springboot 整合 MySQL 最经典的时区问题。--spring.profiles.activeprod指定生产环境配置数据源密码不要写死在 yml 里用环境变量注入比如--spring.datasource.password${DB_PASSWORD}避免打包后的 jar 泄露敏感信息。5. 三类常见故障启动失败、慢 SQL 与数据不一致5.1 SpringBoot 版本太高导致的启动报错网上很多课程设计模板用的是 SpringBoot 2.1.x但本地环境可能装了新版 JDK于是启动时直接报UnsupportedClassVersionError或者Invalid value type for attribute factoryBeanObjectType。前者是 JDK 版本太高编译字节码版本超过了 SpringBoot 运行期兼容范围后者是 SpringBoot 3.x 和 MyBatis 旧版 starter 不兼容。处理方式不是换 JDK而是统一版本JDK 8 搭配 SpringBoot 2.7.18 和 mybatis-spring-boot-starter 2.3.2三者的兼容性已经被大量生产项目验证过。升级到 SpringBoot 3.x 前先确认所有依赖是否发布了对应的 jakarta 版本这是 springboot 版本选择的基本原则。5.2 慢 SQL 和订单状态与房态不一致的修复民宿系统上线一段时间后订单量增长会出现两个典型问题。第一个是订单列表加载变慢排查步骤是先开启 MySQL 慢查询日志定位到select * from orders where user_id ? order by create_time desc limit 10这类语句然后检查是否命中索引。如果user_id和create_time是联合索引的一部分这条 SQL 可以走索引覆盖但如果查询条件是where status ?那必须确认选择性是否足够好status 只有 5 个取值选择性很差这时索引并不一定有用直接全表扫描反而更快。第二个问题更隐蔽用户支付成功后订单状态是已支付但前一天有一个同房间的待支付订单因为定时任务还没跑仍然锁着这间房导致新订单支付后房间号冲突。快速修复思路是写一个补偿脚本扫描所有已支付订单把同房间同时间段内其他待支付订单直接置为已取消释放锁房。这个脚本用的 SQL 是典型的自连接更新执行前先备份 order 表UPDATE orders o JOIN ( SELECT room_id, check_in_date, check_out_date, MIN(id) AS keep_id FROM orders WHERE status IN (0, 1, 2) GROUP BY room_id, check_in_date, check_out_date HAVING COUNT(DISTINCT order_no) 1 ) t ON o.room_id t.room_id AND o.check_in_date t.check_in_date AND o.check_out_date t.check_out_date SET o.status 4 WHERE o.id ! t.keep_id AND o.status 0;脚本的GROUP BY以房间和日期段为维度找到重复订单组keep_id保留最早创建的那条其余待支付订单强制置为已取消。这个补偿脚本只解决存量数据真正根治还是要靠创建订单时的行级锁或分布式锁来保证同一房间同一时段只有一个有效订单。如果项目并发了再上 Redis 锁前期直接在事务里对房间记录执行select ... for update就能挡住大部分冲突。本文还有配套的精品资源点击获取 SpringBoot民宿管理系统实战：订单状态机与数据库设计核心
简介基于SpringBoot的民宿管理平台系统毕业设计全套资源包内含完整源码、数据库脚本、系统文档与答辩PPT面向正在完成毕业设计的大学生或希望上手Java Web开发实战的学习者。资源共832个文件以Java后端代码、Vue前端组件、JavaScript逻辑、SQL数据库脚本以及HTML/CSS样式为主同时提供安装启动批处理和运行命令压缩包整体约24.66MB目录结构清晰便于按模块检索。系统围绕管理员、用户、商家三类角色设计了民宿信息管理、房间类型与信息维护、预订与退订流程、投诉反馈处理、个人收藏管理等核心模块前台页面还集成了在线客服完整演示了SpringBoot与Vue前后端分离项目的开发思路。文档部分详细说明需求分析、数据库设计和功能模块PPT可用于答辩汇报与项目展示代码注释相对完整可导入主流IDE快速部署运行也能作为二次开发的基础。当前已有114人学习对毕业设计选题、工程实践或求职作品积累均具有实用参考价值。1. 民宿管理平台的复杂度不在功能多而在订单与房态的状态流转“基于SpringBoot的民宿管理平台系统”这个名字听起来像是又一个增删改查练习但真正动手把表建出来、把接口写完才发现民宿和酒店最大的区别在于“同一房源有多间房但每间房的售卖单元是“夜”而不是“间”。一个用户要订 6 月 1 日到 6 月 3 日的大床房系统要同时判断这一天哪几间房可订、价格是平日价还是周末价、订单取消后房态何时释放。这些逻辑全部压在数据库设计和订单状态机上SpringBoot 只负责把业务串起来。这篇文章从建表、分层实现、鉴权上传到部署排查把一套可直接落地的民宿后台的实现路径讲清楚适合正在做课程设计或准备接手这类业务系统的开发者看完能直接照着把工程跑起来也能看懂别人项目里的代码为什么要这么写。2. 表结构先行房态、订单与价格的关系怎么落库2.1 核心五张表从房间到订单的关联路径民宿系统的数据模型不能照搬电商订单因为电商卖的是库存商品而民宿卖的是某房间在某时间段的使用权时间是核心维度。我习惯先拆出五张基础表用户表、民宿表、房间表、房间价格表、订单表其中民宿表和房间表是一对多房间表和价格表是一对多。订单表不直接关联民宿而是通过房间 id 反查民宿这样后续做民宿维度的订单统计时少一次 join。有一个容易忽略的点价格表不要只存一个原价字段。民宿的价格往往按星期变化周五周六是峰值价节假日可能还有独立价格。常见做法是价格表里存date、price_type、price三个字段price_type用来标记平日价、周末价或节假日价。这样用户在选日期范围时可以按日期逐天取价格而不是取一个均价。要注意的是如果入住跨周末订单总额是逐日价格之和这一逻辑要在 Service 层算不能依赖 SQL 的sum简单带过因为还要叠加优惠和押金。订单表是核心中的核心字段上除了常见的order_no、user_id、room_id必须要有check_in_date、check_out_date、total_price、status这四个。check_out_date在业务上是不包含在住宿内的比如 6 月 1 日入住、6 月 3 日退房实际占用的是 1 日和 2 日两晚这直接决定后续的房态冲突校验怎么写。status字段用 int 类型存储拒绝用字符串因为状态既要参与数据库索引又要做数值比较。表名核心字段职责userid, username, password, phone用户与登录凭证homestayid, name, address, location民宿基本信息与定位roomid, homestay_id, room_no, capacity物理房间同一民宿下多间room_priceid, room_id, date, price_type, price按日价格支持周末价ordersid, order_no, user_id, room_id, check_in_date, check_out_date, total_price, status订单与房态依赖的核心2.2 订单状态机与数据库同步状态为什么放订单表而不放房间表很多初学设计者会把房态设计成房间表的一个字段比如room_status 0表示空闲、1表示已订。这个方案在单机小程序里能跑但一旦出现“一个房间未来 7 天有 3 天被订”的场景单个状态字段就完全不够用。正确做法是房态不落库而是通过订单动态推导只要在目标日期范围内存在有效状态的订单则该房间在该日期不可订。这里“有效状态”是关键已取消的订单必须排除在外。订单的状态流转建议控制为五个状态待支付、已支付、入住中、已完成、已取消。待支付和已取消是“不占房”的状态已支付和入住中是“占房”状态。这就引出一个最关键的业务规则创建订单时如果只是生成一条待支付记录那房间应该立刻被锁住防止另一个用户同时下单同一房间。很多系统在支付回调里才涨房态结果会出现两个待支付订单同时存在、先支付的人反而被拒绝的情况。我的处理方式是订单状态为待支付即视为预占资源但在订单表上加一个lock_expire_time字段比如 15 分钟未支付自动把状态置为已取消并用定时任务扫描过期订单。这个字段表面上是一个时间戳实际是分布式环境下的锁租约比单独用 Redis 加锁再额外同步数据库要简单得多。2.3 建表 SQL预留索引和唯一约束的关键写法下面给出订单表和价格表的核心建表语句注意索引和默认值的设计CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint(20) NOT NULL, room_id bigint(20) NOT NULL, check_in_date date NOT NULL, check_out_date date NOT NULL, total_price decimal(10,2) NOT NULL DEFAULT 0.00, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2入住中 3已完成 4已取消, lock_expire_time datetime DEFAULT NULL COMMENT 待支付订单锁房到期时间, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_room_date (room_id, check_in_date, check_out_date), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT民宿订单表; CREATE TABLE room_price ( id bigint(20) NOT NULL AUTO_INCREMENT, room_id bigint(20) NOT NULL, price_date date NOT NULL, price_type tinyint(4) NOT NULL DEFAULT 0 COMMENT 0平日 1周末 2节假日, price decimal(10,2) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_room_date (room_id, price_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房间每日价格表;uk_room_date这个唯一约束特别重要它保证同一个房间同一天只能有一条价格记录。后台在导入价格时可以直接用insert ... on duplicate key update做幂等不需要先查一遍再决定插入还是更新。订单表上的idx_room_date是房态查询的核心索引校验某房间在某个日期段是否可用时SQL 会先按room_id过滤再对日期范围做 range 扫描效率远高于单独查room_id索引后逐条比对。有一点要注意check_out_date在索引里排在最后如果查询条件里只有room_id加check_in_date这个索引依然能走只是check_out_date参与因果有限这在数据量超过十万条后才会感受到差别前期不用过度优化。3. SpringBoot 分层落地从 Controller 到 Mapper 的增删改查骨架3.1 工程结构与 SpringBoot 版本怎么定代码组织上我不建议用网上那种一个controller包下面挂着几百行业务代码的写法。民宿系统的核心是订单业务推荐按模块分包即controller、service、mapper保持三层但service下按order、room、user再拆一层每个模块的接口和实现分开。Controller 层只做参数接收和简单校验业务逻辑全部下沉到 Service这样后续写单元测试能直接跳过 Web 层。SpringBoot 版本选择有一个容易被新手忽略的问题不要一上来就拉最新版。SpringBoot 3.x 要求 JDK 17且 jakarta 命名空间与 2.x 完全不同很多教材里的javax.servlet代码在 3.x 下会直接编译失败。如果本地环境是 JDK 8老老实实选 SpringBoot 2.7.x这是 2.x 系列的最后一个维护版本稳定且资料多。如果要用 JDK 17那再上 3.x。springboot 整合 MyBatis 时还要注意2.7.x 对应 mybatis-spring-boot-starter 2.3.x而 3.x 对应 3.0.x版本配错会出现Invalid value type for attribute factoryBeanObjectType这类启动异常。3.2 创建订单的核心逻辑时间冲突与超卖创建订单是整个系统最需要业务深度的接口。先校验用户登录态再校验房间存在且未下架然后做两个核心判断一是订单时间是否合法二是目标时间段内房间是否可售。下面的代码是 Service 里的核心方法刻意省略了 Controller 包装Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 入参校验入住日期必须在退房日期之前 if (!dto.getCheckInDate().isBefore(dto.getCheckOutDate())) { throw new BizException(入住日期必须早于退房日期); } LocalDate today LocalDate.now(); if (dto.getCheckInDate().isBefore(today)) { throw new BizException(不能预订过去的日期); } // 2. 查询该房间在入住区间内的所有有效订单 ListOrders conflictOrders ordersMapper.selectConflictOrders( dto.getRoomId(), dto.getCheckInDate(), dto.getCheckOutDate(), Arrays.asList(OrderStatus.PAID, OrderStatus.CHECKED_IN)); if (!CollectionUtils.isEmpty(conflictOrders)) { throw new BizException(该时间段房间已被预订); } // 3. 计算总价逐日取价格并累加 ListRoomPrice priceList roomPriceMapper.selectByRoomIdAndDateRange( dto.getRoomId(), dto.getCheckInDate(), dto.getCheckOutDate()); BigDecimal totalPrice BigDecimal.ZERO; for (LocalDate d dto.getCheckInDate(); d.isBefore(dto.getCheckOutDate()); d d.plusDays(1)) { BigDecimal price priceList.stream() .filter(p - p.getPriceDate().equals(d)) .map(RoomPrice::getPrice) .findFirst() .orElseThrow(() - new BizException(该日期未配置价格)); totalPrice totalPrice.add(price); } // 4. 生成订单号并落库状态为待支付 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setRoomId(dto.getRoomId()); order.setCheckInDate(dto.getCheckInDate()); order.setCheckOutDate(dto.getCheckOutDate()); order.setTotalPrice(totalPrice); order.setStatus(OrderStatus.WAIT_PAY); order.setLockExpireTime(LocalDateTime.now().plusMinutes(15)); ordersMapper.insert(order); return convertToVO(order); }selectConflictOrders的 SQL 就是前面idx_room_date索引发挥作用的地方条件写成check_in_date #{endDate} AND check_out_date #{startDate}这是判断日期区间是否相交的通用写法。注意不能写成等值匹配因为订单 A 是 6 月 1 日到 3 日订单 B 是 3 日到 5 日B 的入住日恰好等于 A 的退房日两者不冲突只有交叉才冲突。Transactional保证订单写入和状态变更在同一事务里避免出现订单生成成功但锁房状态未同步的情况。这里的价格逐日累加逻辑比一次性取一个平均价再乘天数要严谨得多因为周末价和节假日价的存在会导致金额误差。3.3 分页查询与多条件筛选MyBatis-Plus 的 QueryWrapper 用法民宿后台最常见的操作是订单列表按状态、日期范围、民宿名称筛选这属于典型的多条件动态查询。手写动态 SQL 能完成但代码非常啰嗦用 MyBatis-Plus 的QueryWrapper可以大幅简化同时保持可读性public PageResultOrderVO pageOrders(OrderQueryDTO query) { PageOrders page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperOrders wrapper new LambdaQueryWrapper(); wrapper.eq(query.getStatus() ! null, Orders::getStatus, query.getStatus()) .ge(query.getStartDate() ! null, Orders::getCheckInDate, query.getStartDate()) .le(query.getEndDate() ! null, Orders::getCheckInDate, query.getEndDate()) .orderByDesc(Orders::getCreateTime); PageOrders ordersPage ordersMapper.selectPage(page, wrapper); // 手动做关联查询填充用户名和民宿名避免在 SQL 里写死 join return convertToPageResult(ordersPage); }.eq和.ge的第一个参数是 boolean 条件只有当前端传入了对应参数时才拼接这条条件这是动态筛选的核心。这里有意不写 join而是分两次查询去填充用户名和民宿名原因是订单表数据量大后join 会让分页 count 查询变慢拆成两次查询后每次都可以走独立索引对后台管理系统来说用户体验更好。如果确实需要订单表和房间表实时联查也会把 join 写成子查询而不是笛卡尔积式的关联这一点是写 Mapper XML 时容易踩的坑。4. 登录鉴权、图片上传与打包部署4.1 用拦截器做轻量登录鉴权不引 Spring Security 的理由民宿管理系统的用户角色通常只有管理员和普通用户两种权限模型非常简单引入 Spring Security 反而带来配置复杂度。登录接口先校验用户名密码成功后签发 JWT Token前端后续请求在 Header 里带上 Token后端用拦截器统一解析。这里用拦截器而不是过滤器因为拦截器能拿到 HandlerMethod可以针对不同接口做细粒度的权限判定。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !token.startsWith(Bearer )) { throw new BizException(未登录或登录已过期); } // 解析 JWT把 userId 放入 ThreadLocal方便 Controller 直接取用 Long userId JwtUtil.parseToken(token.substring(7)); UserContext.set(userId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }拦截器里只解析 Token 和校验有效期不做数据库查询这样能保证高并发场景下鉴权逻辑本身不成为瓶颈。UserContext是一个ThreadLocal封装注意在afterCompletion里必须清理否则线程池复用时会读到上一个请求的用户数据这是线上最容易出现的隐蔽 bug。Token 过期时间一般设为 2 小时管理后台可以延长到 24 小时但不要用永久 Token这种偷懒方案。4.2 图片上传与静态资源映射房间图为什么存磁盘不存库民宿后台必然涉及房间图片上传这里推荐一个比较务实的做法图片文件存本地磁盘或对象存储数据库只存 URL 路径。很多人把图片转成 Base64 直接存进 MySQL 的longtext字段这种做法的查询性能和存储成本都很差。配置层面最简单的方式是在application.yml里声明上传路径并注册静态资源映射spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB mvc: static-path-pattern: /upload/** web: resources: static-locations: file:D:/homestay/upload/static-locations指定磁盘物理路径后访问http://ip:8080/upload/room/xxx.jpg就能直接映射到D:/homestay/upload/room/xxx.jpg。上传接口接收MultipartFile后文件名不要用原始文件名用UUID 后缀重命名避免中文名乱码和路径穿越攻击。图片上传后返回相对路径前端拼上baseUrl就能展示。如果是部署到 Linux把路径改成/home/homestay/upload/即可这是 springboot 配置里最值得记住的一处。4.3 Linux 部署jar 直接跑还是配 nginx 反代后台管理系统打包成 jar 后部署是最省事的方案但生产环境我一般会搭配 nginx 做反向代理。nginx 负责监听 80 端口、转发/api/前缀到 SpringBoot 的 8080同时直接托管前端静态资源这样前后端共用一个域名避免了跨域问题。启动脚本用nohup java -jar时务必加上 JVM 参数nohup java -Xms256m -Xmx512m -jar homestay-admin-1.0.0.jar \ --spring.profiles.activeprod \ --server.port8080 \ --spring.datasource.urljdbc:mysql://localhost:3306/homestay?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai \ /logs/homestay.log 21 -Xms和-Xmx设置为相同值可以避免 JVM 运行期动态申请内存带来的性能抖动512MB 对于这套系统足够了。serverTimezoneAsia/Shanghai一定要显式声明否则插入数据库的日期时间会和本地时间差 8 小时这是 springboot 整合 MySQL 最经典的时区问题。--spring.profiles.activeprod指定生产环境配置数据源密码不要写死在 yml 里用环境变量注入比如--spring.datasource.password${DB_PASSWORD}避免打包后的 jar 泄露敏感信息。5. 三类常见故障启动失败、慢 SQL 与数据不一致5.1 SpringBoot 版本太高导致的启动报错网上很多课程设计模板用的是 SpringBoot 2.1.x但本地环境可能装了新版 JDK于是启动时直接报UnsupportedClassVersionError或者Invalid value type for attribute factoryBeanObjectType。前者是 JDK 版本太高编译字节码版本超过了 SpringBoot 运行期兼容范围后者是 SpringBoot 3.x 和 MyBatis 旧版 starter 不兼容。处理方式不是换 JDK而是统一版本JDK 8 搭配 SpringBoot 2.7.18 和 mybatis-spring-boot-starter 2.3.2三者的兼容性已经被大量生产项目验证过。升级到 SpringBoot 3.x 前先确认所有依赖是否发布了对应的 jakarta 版本这是 springboot 版本选择的基本原则。5.2 慢 SQL 和订单状态与房态不一致的修复民宿系统上线一段时间后订单量增长会出现两个典型问题。第一个是订单列表加载变慢排查步骤是先开启 MySQL 慢查询日志定位到select * from orders where user_id ? order by create_time desc limit 10这类语句然后检查是否命中索引。如果user_id和create_time是联合索引的一部分这条 SQL 可以走索引覆盖但如果查询条件是where status ?那必须确认选择性是否足够好status 只有 5 个取值选择性很差这时索引并不一定有用直接全表扫描反而更快。第二个问题更隐蔽用户支付成功后订单状态是已支付但前一天有一个同房间的待支付订单因为定时任务还没跑仍然锁着这间房导致新订单支付后房间号冲突。快速修复思路是写一个补偿脚本扫描所有已支付订单把同房间同时间段内其他待支付订单直接置为已取消释放锁房。这个脚本用的 SQL 是典型的自连接更新执行前先备份 order 表UPDATE orders o JOIN ( SELECT room_id, check_in_date, check_out_date, MIN(id) AS keep_id FROM orders WHERE status IN (0, 1, 2) GROUP BY room_id, check_in_date, check_out_date HAVING COUNT(DISTINCT order_no) 1 ) t ON o.room_id t.room_id AND o.check_in_date t.check_in_date AND o.check_out_date t.check_out_date SET o.status 4 WHERE o.id ! t.keep_id AND o.status 0;脚本的GROUP BY以房间和日期段为维度找到重复订单组keep_id保留最早创建的那条其余待支付订单强制置为已取消。这个补偿脚本只解决存量数据真正根治还是要靠创建订单时的行级锁或分布式锁来保证同一房间同一时段只有一个有效订单。如果项目并发了再上 Redis 锁前期直接在事务里对房间记录执行select ... for update就能挡住大部分冲突。本文还有配套的精品资源点击获取