做民宿预订系统，或者任何带房态管理的业务后台，最怕什么？不是功能少，而是订单算错、房型超卖、状态乱掉。最近我把一套完整的企业级民宿在线预定平台管理系统源码完整跑了一遍，后端SpringBoot+MyBatis，前端Vue，数据落在MySQL里，前后端分离但又能打包到一起部署，非常适合做课程设计、毕业设计，也能当小团队快速起量的业务底座。这篇文章把这套系统的技术选型、数据库设计、后端核心逻辑、前端联调和部署流程完整拆一遍，里面很多坑是我实际运行中踩出来的，希望你能少走点弯路。

这套系统的价值不在于“能跑”，而在于把民宿预订的核心业务闭环真正打通了：用户搜房、看房态、下单、支付、后台管理、统计报表，全部串联。房态按日期锁定，订单有状态流转，并发下单不会超卖，定时任务自动关闭超时订单。下面就从整体设计开始，一步步往里拆。

1. 项目整体设计与技术选型拆解

1.1 为什么选SpringBoot+Vue前后端分离

民宿预定这种业务，典型的特征是“前台要好看、后台要复杂”。前台用户需要流畅地浏览房源、选日期、看图片，体验要求高；后台管理员则要操作大量的表格、弹窗、状态切换。如果还沿用传统JSP页面揉在一起，前端改样式很容易碰坏后端逻辑，开发效率非常低。

所以这套源码采用了前后端分离架构。后端只负责提供API接口，返回JSON数据；前端用Vue框架做页面渲染和数据交互。这样做有几个非常实际的好处：

• 前后端可以并行开发，后端定义好接口文档，前端拿Mock数据就能开工。
• 同一套后端API，以后还能扩展小程序、App、H5多端，不需要重写业务逻辑。
• 部署灵活，开发环境用Node代理联调，生产环境可以打包成静态文件扔进SpringBoot，也能独立扔到Nginx，按量级决定。

SpringBoot在这个架构里的角色是“最省心的后端底座”。它内嵌Tomcat，不需要额外装容器，配置都收敛在application.yml里，起步快。相比SSH（Spring+Struts+Hibernate）那套老配置，SpringBoot让团队把精力放在业务实现上，而不是跟XML配置搏斗。Vue这边则用组件化的方式组织页面，民宿列表、订单表格、日期选择器这些都是独立组件，维护边界清楚，出问题好定位。

1.2 MyBatis与MySQL的组合逻辑

选MyBatis而不选其他ORM，这套源码是有考虑的。民宿预订涉及大量的多表联查、动态条件查询、统计报表，比如“查询某城市、某日期区间、可订且价格小于某值的房源”，这种需求用MyBatis的XML写动态SQL非常顺手，SQL是显式可控的，性能瓶颈容易排查。相比MyBatis-Plus这类增强框架，原生MyBatis虽然要手写SQL，但恰恰适合学习底层的同学把SQL基本功练扎实。

MySQL作为存储层，满足了几个核心诉求：免费、稳定、事务支持好。订单和支付这类数据离不开ACID，InnoDB引擎的行锁和事务机制能保证并发下不超卖。民宿数据量级在百万以内，MySQL完全扛得住，不需要一上来就上分布式数据库。

这套组合的代价是手写SQL量会多一些，但换来的清晰度和可控性，对于中小型业务非常值。实际开发中，我把复杂查询都写在XML里，Mapper接口保持干净，后面维护成本很低。

1.3 系统模块与功能清单

整套系统按用户角色分成前台门户和后台管理两大部分。前台面向游客和注册用户，后台面向民宿管理员、经营者和系统超级管理员。

模块划分如下表所示：

这套模块划分很科学，它把“房”和“单”分开管理，又通过房态和订单绑在一起。初学者拿到源码后，可以从“房源-房间-房态-订单-评价”这条主链路去理解，比漫无目的地看代码高效得多。

2. 数据库设计与核心业务逻辑

2.1 民宿预订核心表结构设计

数据库设计是整个系统的地基。这套源码的表设计走的是经典逻辑，我拆开看主要有六张核心表：用户表、民宿表、房间表、房态表、订单表、评价表。

用户表主要字段包括id、手机号、密码（加密后）、昵称、头像、角色、创建时间。手机号做唯一索引，角色字段区分普通用户和管理员，密码用BCrypt加密存储，不存明文。

民宿表是房源主表，包含民宿名称、所在城市、详细地址、经纬度、封面图、描述、联系电话、审核状态、上下架状态。这里要注意经纬度字段，因为后面如果接地图定位、按距离排序，这两个字段就是基础。价格相关字段不在民宿表里，而是挂在房间表或房态表，因为民宿的价格往往按房型、按日期浮动。

房间表记录每个民宿下的物理房间，比如“标准大床房A”，每个房间有房间号、所属民宿id、房型名称、床型、面积、可住人数、基础价格、设施列表。一个民宿有多个房间，一个房间在不同日期有不同的可订状态和价格，这就引出房态表。

房态表是整个系统最核心的一张表，我单独拿一个章节说。它的逻辑是“房间+日期”维度的库存记录，每条记录代表某个房间在某个具体日期是否可订、价格是多少。这种设计很像酒店房价表，把房间和日期组合拆开，才能做精细化的房态管理。

订单表记录了用户每一次预订，包含订单号、用户id、民宿id、房间id、入住日期、退房日期、总价（按日期累加）、状态、下单时间、支付时间、支付流水号。订单号需要全局唯一，一般用时间戳加随机数或雪花ID，不能依赖数据库自增当订单号给人看。

评价表比较简单，关联订单和民宿，记录评分和内容。这几张表之间用逻辑外键关联，不建物理外键约束，这样的好处是以后分库分表或者删除数据时灵活，但代价是代码里必须保证数据一致性。源码在这个处理上比较成熟，初学者最好不要轻易往表里加物理外键，否则后面批量清理数据会特别痛苦。

2.2 房态管理：每日房态与状态机

民宿不同于标准酒店，房间数量少，而且一次性预订往往跨越多个日期。举个例子，客人订了3月5日到3月7日两晚，那这个房间在3月5日和3月6日这两天都应该是“占用”状态，3月7日退房后可以重新售卖。如果只在订单表里存入住日期和退房日期，查询“某一天有没有空房”就会非常麻烦，还要判断区间重叠。所以这套系统把房态拆到“日期”粒度。

房态表字段一般包括：id、房间id、日期、房态状态、当日价格。状态值建议这样定义：0代表可订，1代表锁定（已被订单占用），2代表后台手动关闭不售卖。当天可订且未过期的记录，前台才能搜出来。

订单状态在这套源码里则是一个完整的状态机：

• 待支付：用户下单但未付款，房态暂时锁定。
• 已支付：支付成功，等待店家接单或直接确认。
• 已入住：到了入住日期，客人办理入住。
• 已退房：客人离店，房间释放，可以回收房态。
• 已取消：用户取消或超时系统取消，需要释放房态。
• 已退款：支付后取消产生的退款状态，一般从已支付或已取消中产生。

状态机看着简单，实际开发十几个坑都是状态边界没处理清楚。比如待支付期间用户点取消，支付后店家取消，谁有权限取消？取消后房态要不要立刻释放？这些都要在代码里严格区分。源码里把订单状态变更都收敛到Service层，并通过事务保证订单状态和房态变更同时成功或同时失败，这个设计是值得借鉴的。

2.3 预订核心：库存扣减与并发控制

在线预订最难的不是CRUD，而是“并发不超卖”。两个用户同时看到同一个房间可订，同时下单，如果代码只是简单查询可订状态再插入订单，就会出现一个房间同一天被订出去的严重事故。

这套源码采用的是“原子更新房态”方案。下单流程很简单清晰：

1. 根据前端传来的房间id和入住/退房日期，查出需要占用的所有日期。
2. 在事务中，对房态表执行更新语句：将日期在入住到退房之间且状态为0的房间记录改为1。
3. 影响行数等于需要的晚数，说明全部锁定成功；小于晚数，说明部分日期已被抢，立刻抛异常回滚。
4. 锁定成功后插入订单，状态设为待支付。
5. 把锁定的房态和订单绑定，后续支付、取消通过订单号反查。

关键SQL类似这样：

UPDATE room_status SET status = 1 WHERE room_id = #{roomId} AND date BETWEEN #{startDate} AND #{endDate} AND status = 0

这条语句在MySQL InnoDB下会按主键或索引对命中的行加锁，并发时第二个事务会等待第一个事务提交，因此不会重复锁定。影响行数就是很好的校验手段，不需要先SELECT再UPDATE，避免并发幽灵读。

订单超时关闭则用定时任务处理，每隔一段时间扫描待支付且超过15分钟的订单，把订单状态改为已取消，同时把对应房态改回0。这里的核心是定时任务和下单逻辑都要操作同一张房态表，事务隔离级别默认用REPEATABLE READ即可，不需要上升到串行化，避免性能损耗。

有个需要注意的细节：如果房间跨度很长，比如住了10天，那一次要更新10条房态记录，客户端请求等待时间稍微长一些。所以不要把这套操作放到大事务里做太多无关逻辑，房态锁定、插订单、发通知足够。凡是外部网络调用（比如发短信）必须放在事务外，否则数据库连接会被拖死，这是我实测踩过的坑。

3. 后端核心实现与踩坑经验

3.1 SpringBoot项目搭建与分层规范

这套源码的后端目录结构非常标准，拿过来就能看懂。顶层是启动类，下面按功能分包：

com.example.homestay ├── common // 通用返回结果、异常、常量、工具类 ├── config // 配置类，比如跨域、拦截器、Swagger ├── controller // 控制器，只做参数接收和结果返回 ├── service // 业务层，接口+实现 ├── mapper // MyBatis的Mapper接口 ├── entity // 数据库实体类 ├── vo // 视图对象，给前端返回的聚合数据 └── task // 定时任务

这种分层不是摆设。controller层要薄，只负责参数校验、调用service、包装返回Result；service层承载业务规则，比如下单流程、取消订单流程；mapper层只写SQL映射，不写业务判断。很多初学者喜欢把业务写在controller里，那样代码会越来越臃肿。

application.yml是配置中心，源码里主要配置了数据源、MyBatis、日志级别、端口。启动项目前第一件事就是检查这里的数据库账号密码是否正确。SpringBoot的端口默认是8080，如果你本机8080被占用了，可以在配置里改：

server: port: 8081

另外建议开启MyBatis的SQL日志打印，方便排查问题。我当时加了两行配置，一次排查SQL错误省了很多时间：

mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

日志打开后，控制台会输出每条SQL和参数，确认动态SQL拼接是否符合预期。生产环境记得关掉，否则有SQL注入暴露风险且日志量太大。

3.2 MyBatis XML与动态SQL实战

这套源码用XML文件映射SQL，在resource/mapper目录下可以看到每个Mapper接口对应的XML。namespace必须和Mapper接口全限定名一致，方法id必须和接口方法名一致，否则启动就会报绑定错误。

房源搜索是最典型的动态SQL场景，用户可能只填了城市和日期，也可能填了价格、人数、关键词。如果用Java代码拼SQL，条件一多代码会非常难看。XML里的动态SQL清晰得多：

<select id="searchHomestay" resultType="com.example.homestay.vo.HomestayVO"> SELECT h.*, MIN(rs.price) AS min_price FROM homestay h JOIN room r ON h.id = r.homestay_id JOIN room_status rs ON r.id = rs.room_id <where> <if test="city != null and city != ''"> AND h.city = #{city} </if> <if test="keyword != null and keyword != ''"> AND (h.name LIKE CONCAT('%', #{keyword}, '%') OR h.address LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="maxPrice != null"> AND rs.price &lt;= #{maxPrice} </if> AND rs.status = 0 AND rs.date BETWEEN #{startDate} AND #{endDate} </where> GROUP BY h.id ORDER BY min_price ASC </select>

这里有几个容易踩的坑。第一，<符号在XML里必须写成<，不能直接写，否则XML解析直接报错。第二，where标签会自动处理第一个条件前面的AND，省去手写where 1=1的丑陋操作。第三，房价范围筛选要配合GROUP BY和MIN聚合，否则一个民宿多个房型会把重复数据带出来。

联表查询订单列表也一样，订单表关联用户表、民宿表，用ResultMap或者VO的别名映射。建议在SQL里给查询字段起别名，直接映射到VO的属性，减少不必要的实体转换。这套源码在订单列表页做得很完整，搜索条件包含订单状态、日期范围、关键字，全部用动态SQL实现，可读性和执行效率都不错。

3.3 订单超时、事务与并发锁处理

订单超时关闭是这个系统里我个人觉得最值得研究的代码。原理不复杂，就是启动一个定时任务，扫描待支付超过N分钟的订单，然后取消并释放房态。但实现时有几个关键点：

事务边界必须是“查询订单->更新订单状态->释放房态”整个过程。假如订单取消了，但房态没释放，那这个房间就永远卖不出去了，损失很大。所以Service方法要加@Transactional，确保原子性。MySQL默认事务隔离级别下，这样写没问题。

@Transactional失效的几个场景要特别注意。最常见的是同类内部调用：A方法调同类B方法，B上面虽然挂了注解，但不会走代理，事务不生效。我当时就犯过这个错，下单逻辑在Service的public方法里调了另一个事务方法，结果异常时订单回滚了但房态没回滚，排查好久。解决办法是把事务方法单独放到另一个Service，或者自己注入自身代理。

另外，不要在大事务里做RPC、发短信、写日志等外部操作。比如用户支付成功后要发短信通知，短信接口超时会导致事务迟迟不提交，系统整体响应变慢。更好的做法是事务内只做核心状态修改，发送通知放到事务提交之后，用Event或消息队列。

对于并发量更高的场景，这套源码还留了一个扩展点：可以用SELECT ... FOR UPDATE悲观锁锁住房态记录，或者引入Redis分布式锁。单机部署、日订单几千的情况下，使用原子UPDATE加事务已经足够稳定。真正做生产系统，建议把房态扣减和订单表改成消息队列异步处理，但架构复杂度会明显上升，这是后话。

3.4 MyBatis缓存机制与使用建议

看源码的时候经常会碰到MyBatis缓存相关的问题。MyBatis一级缓存是SqlSession级别的缓存，默认开启，同一个SqlSession里执行相同的查询，第二次会直接走缓存。但在Spring整合MyBatis后，每个请求通常对应一个新的SqlSession，所以一级缓存的实际作用比较有限，反而要注意不能在缓存未清空时做修改操作。

二级缓存是mapper级别的，也就是namespace级别，默认关闭，需要手动开启。这套源码里并没有简单粗暴地开启二级缓存，这一点我很认同。订单、房态这类数据更新极其频繁，开启二级缓存后，如果其他节点修改了数据库，本地缓存没有及时刷新，用户就会看到“房间已经订出去了但还显示可订”的脏数据。

如果你非要给某些低变更数据（比如城市列表、民宿设施字典）开启缓存，请注意两点：一是缓存刷新策略，比如flushCache="true"在更新语句中；二是相信数据库性能，MySQL单表几万行，带索引的查询在毫秒级，很多时候优化SQL比加缓存更有用。真正需要缓存的是高频计算型数据，比如房源搜索结果，那也应该用Redis，而不是MyBatis二级缓存。所以这套源码在缓存这块保持了克制，是符合业务场景的正确选择。

4. 前端Vue实现与联调要点

4.1 Vue项目结构与路由配置

前端源码使用的是标准Vue工程结构。组件在src/components，页面在src/views，接口请求在src/api，路由在src/router。这样的目录划分很直观，页面需要复用模块时就抽到components里。

路由配置我建议花点时间看。普通用户端的页面和后台管理端的页面是分开的，通过路由嵌套来区分。比如：

const routes = [ { path: '/', component: Home }, { path: '/detail/:id', component: HomeDetail }, { path: '/login', component: Login }, { path: '/admin', component: AdminLayout, children: [ { path: 'orders', component: OrderManage }, { path: 'homestay', component: HomestayManage } ] } ]

路由懒加载在源码里是标配，通过动态import()加载组件，这样首屏只加载必要的JS，民宿详情页和后台管理页面按需加载，首屏速度快很多。Vue Router的路由守卫也很有用，后台管理页面在beforeEach里判断有无token，如果没有就跳转登录页。这个逻辑别看简单，很多项目都是漏了它，导致未登录用户能直接访问内部页面。

关键词里提到的“动态路由”思路，这套源码也体现了一点。后台用户的权限如果不同，菜单和路由可以根据用户角色动态注册。不过源码里为了保持简单，只是做了静态路由加守卫，以后要升级成RBAC权限管理，可以往动态路由方向扩展。

4.2 核心页面拆解：搜索、预订、支付、管理

民宿搜索页是流量入口，组件拆得很细：顶部城市选择、日期范围选择、价格区间条、房源卡片列表。日期选择器直接用了Element UI的el-date-picker，设置type="daterange"，再配合disabledDate把已过去日期置灰。前端日期格式统一提交为YYYY-MM-DD，避免后端解析时区出问题。

民宿详情页比较关键，因为预订主流程都在这里。页面上方是图片轮播和基本信息，中间是房型列表，每个房型卡片显示可住人数、面积、价格，还有“预订”按钮。选了入住日期后，系统会带上日期参数请求房态接口，能订的房型显示可选择，不能订的置灰。

提交订单页则要计算总价。前端从接口拿到所选日期每天的房价，然后累加。这里有个坑：前端计算总价只能作为用户预览，后端必须根据数据库房价重新计算，绝对不能信任前端传过来的总价。这套源码的做法是订单创建接口只接收房间id和日期区间，后端自行算价格生成订单，前端只展示结果，既安全又不易出错。

后台管理页面使用表格加弹窗表单的组合。订单管理表格支持按状态筛选、关键词搜索、分页，支付状态通过标签颜色区分。整个后台页面的风格统一，用了Element UI主题，没有自己手写昂贵的UI逻辑。这提示我们实战项目能用成熟组件库就不自己造轮子，重点放在业务交互上。

4.3 前后端接口设计与跨域问题

接口设计遵循RESTful风格，统一前缀是/api。比如：

• GET /api/homestay/list房源搜索
• GET /api/homestay/{id}房源详情
• POST /api/order/create创建订单
• POST /api/order/pay订单支付
• PUT /api/order/cancel/{orderNo}取消订单

统一前缀的好处是开发环境好配代理。前端开发服务器默认在8080端口（或8081），后端API在8080（或8082），浏览器跨域报错是家常便饭。最简单的方案是vite或Vue CLI配置proxy代理：

// vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这样前端请求/api/xxx时，开发服务器会把它转发到后端接口，浏览器不感知跨域，后端也不用额外加CORS。如果你不想用代理，后端可以配置一个CorsFilter允许指定域名跨域。但实际经验告诉我，开发用代理最顺手，生产用Nginx反代更稳，后端CORS反而容易暴露得过宽。

还有一个细节：请求拦截器统一在axios里加token。登录成功把token存到localStorage，每次请求前从storage取，放到Authorization头。后端通过拦截器校验token并取出当前用户id。这套机制看源码时很容易忽略，但它是整个权限体系的地基。

4.4 Vue打包放进SpringBoot的细节

很多同学学完前后端分离，不知道怎么部署。这套源码演示了一个很实用的方案：把Vue打包后的静态文件直接放进SpringBoot的src/main/resources/static目录，这样前端页面和后端API都由同一个Tomcat服务，只需要启动一个Java进程。

操作流程如下：

1. 前端执行npm run build，生成dist目录。
2. 把dist目录下的所有文件复制到SpringBoot的src/main/resources/static目录。
3. 重新打包后端mvn clean package，启动后访问http://localhost:8080就是前端页面，/api/xxx就是后端接口。

这里有几个关键细节必须注意。第一，前端路由如果用的是HTML5 History模式（mode: 'history'），刷新二级页面时后端没有相关路由会报404。解决办法要么改回hash模式，要么让后端把非/api请求都转发到index.html。如果只是本地演示或内网系统，直接用hash模式最省事，URL带#/也不影响使用。

第二，打包时静态资源路径要配置成相对路径。Vite或Vue CLI默认publicPath可能是/，这样打包后的JS、CSS路径是/js/app.js，部署到服务器根目录没问题，但如果后端项目带了context-path，就会找不到资源。改成publicPath: './'，资源路径变成相对路径，放到任何目录都能正常加载。这个坑我踩过不止一次，每次都是白屏之后才反应过来。

第三，跨域问题在“前后端合并部署”场景下基本不存在了，因为前端静态页和后端接口同源。如果后续把前端单独独立部署到Nginx，那就需要Nginx把/api反向代理给后端服务，这是生产环境最常见的部署形态，源码里的前后端分离设计也为这个演进留好了路。

5. 部署发布与完整源码使用指南

5.1 环境准备与工具安装

拿到源码第一件事不是看代码，而是把环境跑通。需要准备的工具如下：

• JDK 1.8或11（这套源码基于SpringBoot 2.x，JDK8完全兼容）
• Maven 3.6及以上
• MySQL 5.7或8.0
• Node.js 14及以上
• IDEA或Eclipse（推荐IDEA）
• Vue CLI或Vite

MySQL安装有几个注意事项。Windows上安装MySQL最容易踩的坑是root密码忘记、服务启动失败、字符集不对。安装时记得选择UTF-8字符集，或者安装后在my.ini里配置：

[mysqld] character-set-server=utf8mb4 [client] default-character-set=utf8mb4

如果遇到mysql ssl连接错误，可以先在连接URL暂时关闭SSL验证，排查问题。但生产环境该开的加密还是要开，开发环境方便为主。

Maven构建SpringBoot项目时，首次下载依赖会非常慢，建议在settings.xml里配置阿里云镜像。这是国内开发者的常规操作，不然可能等半小时还没拉完包。

配置好镜像后，IDEA导入项目方式很简单：File -> Open选中后端根目录的pom.xml，IDEA会自动识别为Maven项目并下载依赖。如果IDEA右下角提示导入，点击导入等待完成即可。

前端依赖安装用npm：

npm install

有时候npm安装很慢，可以换成淘宝镜像：

npm config set registry https://registry.npmmirror.com

环境装好后，先跑后端再跑前端，稳步推进。

5.2 初始化数据库并启动后端

启动步骤我按实际操作顺序列出来，跟着做基本不会卡壳：

第一步，用Navicat或命令行创建一个数据库实例，比如homestay_db，字符集选utf8mb4。源码里应该有SQL脚本（大概率叫homestay.sql或db.sql），用source命令或者直接拖进Navicat执行，表结构和初始数据就建好了。

mysql -u root -p homestay_db < homestay.sql

第二步，打开后端项目的application.yml，把账号密码改成你自己的：

spring: datasource: url: jdbc:mysql://localhost:3306/homestay_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver

serverTimezone一定要配置，否则MySQL 8.0连接会报时区错误。useSSL看情况设置，本地开发建议先useSSL=false方便调试。

第三步，启动SpringBoot主类。看到Tomcat started on port(s): 8080说明后端启动成功。此时你可以直接访问/api下的接口测试，比如http://localhost:8080/api/homestay/list?city=杭州。

第四步，启动前端开发服务器。在frontend目录执行：

npm run serve

默认端口是8080的话，和后端冲突，建议在vue.config.js里改掉，比如改成8081，并配置代理到8080。看到编译成功、浏览器打开页面，前后端联调就正式开始了。

生产部署直接把Vue打包放进SpringBoot的static目录，然后mvn clean package打成jar，java -jar xxx.jar启动即可。这样部署最简单，适合演示和小团队自用。

5.3 常见问题排查速查表

我整理了跑这套源码时最常遇到的几个问题，做成速查表，后面你遇到类似情况直接对照：

这些坑基本覆盖了从环境到运行、从开发到部署的各个环节。我特别想说下数据库连接URL的时区问题，简直是最常见的新手杀手。很多人程序跑得起来，一操作数据库就报The server time zone value 'Öйú±ê׼ʱ¼ä'，第一反应是乱码，其实是缺少serverTimezone=Asia/Shanghai导致的。加上的瞬间世界清净了。

6. 从源码到真正可商用的扩展之路

6.1 先保证房态一致，再谈功能扩展

这套源码足够跑通业务闭环，但离“企业级商用”还有几步路。我的建议是，任何扩展都要以不破坏房态一致性为前提。

比如你接入了微信小程序，用户从H5、小程序、App三个端同时下单，原先的单机事务和本地锁就不够了。这时候需要引入Redis分布式锁，把“锁定某房间某区间房态”的操作变为跨进程互斥。或者更进一步，把房态库存在Redis里用Lua脚本原子扣减，MySQL作为最终数据落库。这是分布式库存系统的经典方案，但复杂度会明显上升。在业务量没到一定阶段前，千万不要为了“架构先进”主动加复杂度。

6.2 支付、短信、地图等第三方服务接入

当前源码的支付大概率是模拟支付，真正的商用需要接入微信支付或支付宝。别小看这一步，支付回调的验签、幂等、金额核对才是真正的难点。回调接口一定要做幂等，否则同一个订单的支付结果通知两次，就可能重复发放权益或重复修改状态。支付宝和微信的SDK文档都很长，建议先用沙箱环境跑通。

短信通知是提升体验的功能，用户下单、支付成功、入住提醒都可以触发短信。市场上常见的服务商都提供Java SDK，用起来不复杂，注意把短信模板参数和订单号绑定好。地图这块，民宿详情页可以接入高德或腾讯地图的JavaScript API，展示位置和周边景点，对下单转化率有明显帮助。

这些第三方接入，并不需要改动核心表结构，只需要在业务层增加适配器。源码的分层规范这时候就体现出优势了：controller、service、mapper边界清楚，替换支付实现只需要改service层，不用动SQL和页面。

6.3 从项目源码到生产环境的差距

最后说点实在的。这套源码的核心业务是可用的，但生产环境还需要补几块：

日志要接入统一框架，比如Logback配JSON格式，方便对接ELK或云日志服务；定时任务建议用分布式调度平台，避免多实例重复执行；数据库要定时备份，至少开启binlog；Nginx配置静态资源缓存和API限流；前端加埋点统计，了解用户搜索行为和下单漏斗。

权限管理可以从“用户角色固定字段”升级为RBAC，引入用户-角色-权限三张表，菜单和按钮按权限渲染。这套扩展方向，代码里已经预留了用户角色字段，往RBAC改不算太伤筋动骨。

我个人在实际操作中的体会是，民宿类业务的复杂度不在技术框架，而在房态、订单、支付这三个状态的一致性。源码把这三件事用SpringBoot+MyBatis+MySQL以最直白的方式做了出来，没有过度设计，很适合作为深入学习前后端分离项目的第一套完整代码。你拿到源码后，不要急着加功能，先把“下单锁房态-支付-入住-退房释放房态”这条链路读懂，遇到问题用日志和SQL分析，比任何框架技巧都管用。