基于SpringBoot+Vue+MySQL+MyBatis的民宿预定管理系统全栈开发解析-育师

基于SpringBoot+Vue+MySQL+MyBatis的民宿在线预定平台管理系统——这类题目在毕业设计选题表里出现的频率，基本上和"网上商城"一个级别。我最近完整过了一遍这套项目的设计流程，从数据库建模、后端接口开发到Vue前端联调，中间踩了不少坑，也把业务链路理顺了。这篇把整个项目当成一条完整的开发线来讲，对准备做全栈项目或者期末交课程设计的人来说，应该能省不少时间。这里不讨论花哨的算法，核心就讲明白一件事：一个前后端分离的管理系统，从零到跑通，需要想清楚哪些问题。先提醒一句，这类项目在网上能找到很多源码，但真正决定项目质量的不是代码量，而是你对业务的理解、表结构的设计和关键接口的边界控制。

1. 业务模型拆解：民宿预定平台和普通电商商城的本质区别

1.1 民宿预定和普通电商的差别在哪里

很多人一上来就参考"网上商城"的架构，写一个民宿列表、写一个下单接口，看起来功能都在，但实际上把核心业务搞错了。电商卖的是实物商品，库存是一个数字，下单扣减库存即可；民宿平台卖的是"特定时间段内的房间使用权"，同一间房每一天只能属于一个有效订单。比如6月10日到6月12日这间房被订了，下一个订单就不能选择6月11日入住、6月13日退房。这意味着订单表里必须记录入住日期和退房日期，并且在下单时做一次"日期重叠校验"。

同时，民宿平台的供给端不是平台自己，而是房东。房东需要注册、实名认证、发布房源、设置价格和房态，平台需要对房源进行审核后才能上架。所以在角色设计上，至少有三类用户：普通游客/会员、房东、平台管理员。这是我建议所有做这个题目的同学首先想清楚的一点——这不是一个单角色的系统，权限和业务边界从数据库设计阶段就必须体现出来。

1.2 三类角色的功能清单与页面划分

我习惯先把功能清单拉出来，再设计页面和接口。这里列一个我在实际项目中用过的版本，按角色划分：

前台用户（会员）：注册登录、浏览民宿列表、按城市/关键词搜索、查看民宿详情和评论、下单预订、模拟支付、取消订单、收藏民宿、预订后发表评论
房东：发布民宿、管理自己的房源上下架、设置房间信息（价格、面积、床型、可住人数）、查看自己房源的订单、确认用户入住/退房
管理员：用户管理（禁用/启用）、民宿审核（通过/驳回）、订单监控（查看所有订单和处理异常）、公告发布、基础数据统计

页面划分也随之清晰：前端用户端有首页、搜索列表页、民宿详情页、订单确认页、个人中心（我的订单/收藏/评论）；房东端有一个带侧边栏的管理布局，包含房源管理、订单管理、房间管理；后台管理端独立一套布局，包含审核列表、用户列表、订单列表、统计面板。这个结构放到Vue Router里，就是三套路由：前台主路由、房东路由、管理端路由，权限靠路由守卫控制。

1.3 "管理"这个题眼的落位方式

题目全称是"民宿在线预定平台管理系统设计"，很多人把注意力全放在"预定"上，忽略了"管理"。从评审角度，"预定"只是业务闭环的一部分，"管理"才是系统化的体现。我在实际开发中把"管理"拆成了三块：房态管理（房东对自己房源和订单的掌控）、审核管理（管理员对房源和用户行为的把控）、数据管理（订单统计、入住率、营收概览）。光有一个漂亮的订房页面是不够的，管理后台的完整度往往决定了答辩时老师的第一印象。

2. 技术栈选型的真实理由：为什么这套组合是项目的最优解

2.1 SpringBoot：后端框架的合理默认项

SpringBoot在这个项目里几乎是必选项。原因不是它多先进，而是它把Spring的配置地狱变成了一堆starter依赖，开发效率高，生态成熟，找资料也容易。要注意的是版本选择：网上大量教程和现成代码都是SpringBoot 2.x时代的产物，如果你的项目选了SpringBoot 3.x，会遇到javax.servlet变成jakarta.servlet、JDK要求17等一连串兼容问题。我在这套项目里最终用了SpringBoot 2.7.x + JDK 8，理由非常直接：JDK 8在学校机房和大多数个人电脑上都有，eset到SpringBoot 2.7也不需要改javax包名，MyBatis起步的依赖兼容性也最省心。

2.2 为什么保留手写MyBatis而不是换成MyBatis-Plus

这个问题讨论过太多次。MyBatis-Plus确实效率高，单表CRUD能少写大量代码，但在"毕业设计+面试准备"这个场景下，我反而建议用手写MyBatis。原因有三：第一，项目里最核心的检索、日期重叠校验、多表联查统计，本质上还是要写SQL，任何ORM都绕不开；第二，手写SQL的过程是真本事，面试官问MyBatis动态SQL和关联查询时你能答得出来；第三，源码的含金量恰恰在这部分——把Mapper XML里那些if、where、foreach标签用明白，比把所有查询都封装成LambdaQueryWrapper更有说服力。这不是反对MyBatis-Plus，而是说这套项目里，手写MyBatis的正确性收益更高。

2.3 Vue 2还是Vue 3，以及配套组件库

前端我建议按Vue 3 + Vite + Element Plus来配。Vue 2已经进入维护末期，现在从零学Vue 2有点逆势而为。Element Plus相比Element UI设计语言更现代，表单验证、表格组件、弹窗这些后台常用组件都很成熟，配合Vue 3的组合式API，写起来比选项式API更清爽。需要留意的是Node版本：Vite要求Node.js 14.18以上，建议直接上Node 16或18，太低会启动失败，太高（比如Node 20）时需要关注sass等呼声较重的依赖是否兼容。前端状态管理用Pinia就够了，比Vuex的API更简洁，一个userStore存登录信息和角色即可。

3. 数据库设计：从ER关系到枚举状态，每个决定都有原因

3.1 核心表清单与字段说明

这套项目的表我最终收敛到8张，足够支撑业务闭环，又不会因为过度设计导致代码繁琐：

表名	用途	关键字段
user	用户表	id, username, password, nickname, phone, avatar, role
admin	管理员表	id, username, password, real_name, create_time
hotel	民宿表	id, user_id, name, city, address, images, description, price, status
room	房间表	id, hotel_id, name, price, stock, area, bed_info, max_people
orders	订单表	id, order_no, user_id, hotel_id, room_id, check_in_date, check_out_date, nights, total_price, status
comment	评论表	id, user_id, hotel_id, order_id, score, content, create_time
favorite	收藏表	id, user_id, hotel_id, create_time
notice	公告表	id, title, content, create_time

这里有一个设计决策值得说：房东没有单独开表。民宿的"房东"本质上也是注册用户，我用user表里的role字段区分，0是普通用户，1是房东。这样房东注册后既可以作为消费者订房，也可以切到房东身份去上架民宿，比拆成三张用户表更贴近真实产品的用户模型。管理员则单独一张admin表，因为管理员不走前台注册流程，是后台手动创建的账号，混在user表里反而让登录逻辑变复杂。

3.2 订单状态字段和金额字段的细节

订单表是整张库的灵魂。状态字段status我用TINYINT整型存储，不直接存字符串，原因很简单：整型占用空间小、检索快，而且业务状态在Java侧用一个枚举类管理，代码可读性不下降。枚举我定的是：0待支付、1已支付、2已入住、3已退房、4已取消、5已退款。有人可能会问，已退款和已取消区别在哪？我的理解是：待支付状态下取消是"已取消"，已支付后因为不可住原因退款是"已退款"，两个状态对应着不同的操作权限和金额处理逻辑，分开在统计时更清晰。

金额字段必须用DECIMAL(10,2)，这是老生常谈但每次都有人踩坑。float/double在计算0.1+0.2这种场景会出精度问题，订房金额是真金白银，不容商量。total_price在插入时可以直接用房间单价乘以nights计算出来，不需要前端传，避免前端篡改价格。nights字段同理，由后端根据check_in_date和check_out_date计算，前端只负责选日期。

3.3 索引设计：检索效率和联表查询的先后顺序

索引不是越多越好，但对这套系统的查询热点，四个索引能立竿见影：hotel表上的city和status组合索引，支撑前台民宿筛选；orders表上的hotel_id和user_id索引，分别支撑房东看单和用户看单；orders表上的status索引，支撑管理员后台的状态筛选和定时任务扫单。还有个容易忽略的点：orders.order_no要加唯一索引，因为它是用户在支付流程里最常查询的字段，同时也是防止重复下单的一个兜底手段。

在实际建表时，我建议逻辑外键即可，不需要在MySQL层面声明物理外键约束。原因有二：Delete/Update时的约束检查会影响写入性能，而且项目里MyBatis已经保证了关联数据的一致性。答辩时如果老师问外键为什么不用，这个答案比"怕麻烦"高级得多。

4. 后端核心链路：用户登录、房源检索与下单时发生了什么

4.1 认证方案选型：JWT + 拦截器

用户登录这块，我没有引入Shiro或Spring Security。不是说它们不好，而是这套项目的权限粒度用JWT + 拦截器已经完全够用，而且代码透明、容易讲清楚。密码存储用BCrypt加密，不使用MD5——MD5需要在密码里加盐才能防彩虹表，BCrypt天然自带盐，安全性和易用性都更好。登录成功后签发一个JWT，把userId和role塞进token里，过期时间设成24小时。后端注册一个拦截器，拦截需要登录态的接口，从请求头Authorization中取出token并解析，解析失败就返回401。

这里有个实际的细节：后台管理端的接口和用户端的接口建议分两个拦截器路径前缀，比如/admin/** 的接口除了校验登录态，还要校验role是否为管理员。这样避免了一个普通用户登录后直接调用管理员接口的越权风险。

4.2 下单接口的完整时序

下单这个接口是整个后端最需要打磨的地方。先看参数：roomId、checkInDate、checkOutDate。前端提交到POST /api/order/create，后端处理顺序不能乱：

第一步，校验参数合法性。入住日期不能早于今天，退房日期必须晚于入住日期。
第二步，查询房间信息，确认房间存在且未下架。
第三步，执行日期重叠校验，查orders表里该房间是否存在状态为0/1/2且日期区间的重叠订单。这个SQL是关键，后面第五章单独讲。
第四步，计算nights和total_price。
第五步，生成订单号。我用的格式是yyyyMMddHHmmss + 4位随机数，加上唯一索引兜底。UUID也行，但太长了，用户在支付页面核对订单号时不友好。
第六步，插入订单记录，初始状态0待支付。同时可以预扣库存，但更稳的做法是等支付成功再扣，待支付订单的超时清理也简单。

这里容易掉坑的是并发：两个用户同时下单同一房间同一日期，都通过了重叠校验，就会产生两个有效订单。解决思路分两档，毕设级别可以接受在重叠校验的SQL里加for update做行级锁，或者在后面对房态做唯一约束；再激进一点，可以把"插入订单"和"校验重叠"放进同一个事务，并保证两次校验之间不会穿插其他事务。答辩时能把这个并发安全问题讲明白，是非常突出的加分项。

4.3 订单状态机与超时释放

订单状态不能随便跳。我从一开始就约束了流转方向：待支付可以到已支付或已取消；已支付可以到已入住或已退款；已入住可以到已退房；已退房就是终态。注意，待支付订单不能直接变已入住，必须经过支付动作。这个状态机在后端代码里可以用一个枚举类+一个流转校验方法实现，不需要引入状态机框架，但逻辑必须明确。

超时订单的处理我用了Spring的@Scheduled定时任务，每5分钟扫一次orders表，把创建时间超过15分钟且状态仍为0的订单批量改成4已取消。定时任务要加@EnableScheduling启动类注解，扫描SQL按照 create_time < NOW() - 15分钟来写。这个功能虽然不起眼，但能体现你对"真实业务流程"的思考——线上产品不可能让待支付订单占用房源一整晚。

5. MyBatis实战：动态SQL、多表关联与日期重叠判断

5.1 XML配置与注解的取舍

MyBatis有两种写SQL的方式：注解和XML。这套项目里，简单的单表查询我用注解，涉及动态条件、多表联查的一律用XML。原因很实际：动态SQL标签在注解里写起来极其痛苦，<script>前缀把可读性毁得很彻底；而XML文件结构清晰，改SQL后不用重新编译就能生效。在application.yml里要配置mapper-locations指向xml目录，并且开启mapUnderscoreToCamelCase，这样数据库的create_time字段能自动映射成createTime，不用写一堆resultMap。

5.2 动态SQL：房源多条件检索的写法

前台民宿列表是个典型的多条件检索：城市、关键词、价格区间、排序方式都可能为空，纯靠拼接字符串容易出错。用MyBatis的<where>搭配<if>是最优雅的解法：

<select id="queryHotelList" resultType="com.example.entity.Hotel"> select id, name, city, address, cover_img, price, score, description from hotel <where> <if test="city != null and city != ''"> and city = #{city} </if> <if test="keyword != null and keyword != ''"> and (name like concat('%', #{keyword}, '%') or description like concat('%', #{keyword}, '%')) </if> <if test="minPrice != null"> and price &gt;= #{minPrice} </if> <if test="maxPrice != null"> and price &lt;= #{maxPrice} </if> and status = 1 </where> order by create_time desc limit #{offset}, #{pageSize} </select>

<where>标签会自动去掉第一个条件前面的and，不用写where 1=1这种丑代码。limit后面的偏移量在Service层计算：offset = (pageNum - 1) * pageSize。价格比较符号要转义，>写成>，<写成<。所有参数通过@Param注解传入Mapper方法，避免参数名对不上报错。

5.3 日期重叠判断：最容易写错的一段SQL

下单时的日期重叠校验，我第一次写的时候用了一堆between and，结果边界条件全是问题。正确写法是区间交叉判断：

select count(*) from orders where room_id = #{roomId} and status in (0, 1, 2) and check_in_date &lt; #{checkOutDate} and check_out_date &gt; #{checkInDate}

理解方式很简单：两个时间段只要满足"已有订单的入住日期早于新订单的退房日期，并且已有订单的退房日期晚于新订单的入住日期"，就必定重叠。边界处理：如果已有订单是6月10日入住、6月12日退房，新订单是6月12日入住，那么check_out_date > '2025-06-12'为假，不冲突——因为6月12日中午退房后，下午新客人可以入住。这种区间交叉的判断逻辑不光是民宿，会议室预定、车辆调度、课程排期全都能用，弄懂一次受益很久。

5.4 多表联查：订单列表要关联用户和民宿

后台订单列表需要显示订单号、用户昵称、民宿名称、房间名、金额、状态，这些信息分散在三张表里。MyBatis里写一个多表联查的XML，结果用resultType直接映射到VO类：

<select id="queryOrderVOList" resultType="com.example.vo.OrderVO"> select o.id, o.order_no, o.total_price, o.check_in_date, o.check_out_date, o.nights, o.status, o.create_time, u.nickname as userName, u.phone as userPhone, h.name as hotelName, r.name as roomName from orders o left join user u on o.user_id = u.id left join hotel h on o.hotel_id = h.id left join room r on o.room_id = r.id <where> <if test="status != null"> and o.status = #{status} </if> <if test="hotelName != null and hotelName != ''"> and h.name like concat('%', #{hotelName}, '%') </if> </where> order by o.create_time desc </select>

用left join的原因很直白：左侧的orders是主表，即使某个关联记录被删除，订单本身仍要展示。alias别名搭配属性映射，可以让VO层直接拿到展示字段，Controller不需要再逐个组装。这个接口是后台页面使用频率最高的接口之一，联查逻辑写好后基本不用改。

5.5 分页与统计SQL的补充

分页我用的是手动limit，没有引入PageHelper。手动分页多写两行代码，但能让你清楚地知道分页参数从哪来到哪去，也便于在分页的同时携带筛选条件。统计类SQL也是MyBatis的高频场景，例如管理员后台要展示"近7天订单量"：

select DATE_FORMAT(create_time, '%Y-%m-%d') as day, count(*) as orderCount from orders where create_time &gt;= #{startDate} group by DATE_FORMAT(create_time, '%Y-%m-%d') order by day

这类统计语句在MyBatis里写在XML中，结合resultType映射到一个Map或专门的StatVO，前端拿到数据后直接用ECharts画折线图。统计功能是管理后台的加分项，不需要很复杂，近7天订单趋势和民宿成交量Top5两张图就足够让系统显得完整。

6. Vue前端实战：路由守卫、状态管理与接口封装

6.1 前端目录结构与页面划分

Vue前端我按功能域拆目录，而不是按技术类型堆在一起。大概结构是：

src/ api/ # 接口定义模块，按业务拆分 user.js、hotel.js、order.js router/ # 路由配置，含三套布局路由 store/ # Pinia，主要存用户信息与权限 views/ front/ # 用户端页面 landlord/ # 房东端页面 admin/ # 管理端页面 components/ # 通用组件，如分页、搜索栏、民宿卡片 layout/ # 三种布局外壳：前台、房东、后台

用户端路由挂在FrontLayout下，有首页、列表页、详情页、订单确认页、个人中心；房东端和管理端各自挂在带侧边栏的Layout下。每个角色访问的布局不同，这比在同一个布局里做条件渲染要清晰得多，也方便后续扩展。

6.2 axios封装与登录状态注入

axios必须封装一层，不然每个页面都要重复设置token和错误处理。我在request.js里做了三件事：创建axios实例并设置baseURL为/api；在请求拦截器里从localStorage取出token，拼到Authorization头；在响应拦截器里统一处理业务错误码，code为200时直接返回data，code为401时清token并跳转登录页，其他错误用Element Plus的ElMessage弹出后端返回的msg。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use(res => { const data = res.data if (data.code === 200) { return data.data } if (data.code === 401) { localStorage.removeItem('token') localStorage.removeItem('userInfo') router.push('/login') return Promise.reject(new Error(data.msg)) } ElMessage.error(data.msg || '请求失败') return Promise.reject(new Error(data.msg)) }, err => { ElMessage.error('网络异常，请稍后重试') return Promise.reject(err) }) export default request

接口模块里全部用这个request实例，比如hotel.js里的列表接口：

import request from '@/utils/request' export function getHotelList(params) { return request({ url: '/hotel/list', method: 'get', params }) }

页面里调用后拿到的直接就是data数据，不需要每一层都解包，代码干净很多。

6.3 路由守卫与角色控制

路由守卫是权限控制的前端防线。我对三种路由分别打上meta：login和register是公开页；用户端的personalCenter等需要登录；房东端所有页面要求role为1；管理端所有页面要求role为2。在全局前置守卫里判断：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const userInfo = JSON.parse(localStorage.getItem('userInfo') || '{}') if (to.meta.requiresAuth && !token) { next('/login') return } if (to.meta.role && userInfo.role !== to.meta.role) { next('/') return } next() })

这里面有个细节：用户角色信息在登录成功后就已经存进localStorage，刷新页面后store里的用户信息会丢失，所以在store初始化时先读localStorage。这个逻辑如果不写，刷新后所有需要权限的页面都会因拿不到角色而跳走，属于前后端联调时非常典型的坑。

6.4 前后端联调与开发代理

开发阶段最难缠的是跨域问题。前端页面跑在5173端口，后端接口在8080端口，浏览器会拦截跨域请求。解决方案是在Vite配置里加devServer的proxy，把/api开头的请求转发到后端：

export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: path => path.replace(/^\/api/, '') } } } })

这样一个开发环境下前后端彻底解耦，后端不需要专门写CORS配置，生产环境再按Nginx反代来组合。如果你同时开着后端和前端，这个配置能让联调体验顺滑很多。

7. 环境配置与部署踩坑：先把"跑起来"这个坎迈过去

7.1 MySQL版本选择与安装记录

MySQL的版本选择，就这套项目而言我推荐5.7，而不是最新的8.x。原因之一是网上大量项目源代码在连接数据库时用的驱动和方言是按5.7写的，8.0的认证插槽 caching_sha2_password 有时会引发连接报错；原因之二是5.7在Windows下的安装资料极其丰富，遇到问题搜起来效率更高。当然，装8.0完全可行，但要把pom.xml里的mysql-connector-java版本换成8.x，同时在连接URL上加上useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true，否则大概率会踩连接超时或时区报错。

Windows下安装MySQL 5.7的省心路径是下载zip解压版：解压后配置my.ini，设置basedir和datadir，输入mysqld --initialize-insecure初始化（生成空密码root账号），再用net start mysql启动服务。注意my.ini里要指定字符集为utf8mb4，否则存入的中文在部分客户端会显示乱码。这个坑我印象很深——表里数据是好的，navicat里看着乱码，最后发现是连接字符集的问题。

7.2 SpringBoot版本墙：javax还是jakarta

SpringBoot版本太高是目前做这套项目最常踩的坑。SpringBoot 3.x发布后，很多人新建项目直接选了最新稳定版，结果发现从前人项目里拿来的登录工具类、分页插件、文件上传代码全部编译不过，原因就是3.x把Java EE的命名空间从javax迁移到了jakarta。更麻烦的是MyBatis-Spring-Boot-Starter也要升到3.x配套版本，很多老教程的配置写法已经不再适用。

我的建议非常明确：这套项目直接定SpringBoot 2.7.x + JDK 1.8。SpringBoot 2.7是2.x的最后一个维护版本，支持期限很长，而且市面上绝大多数与SpringBoot+MyBatis相关的源码和教程都兼容这个组合。如果你已经建了3.x的项目，并把依赖和import改成jakarta后跑通了，那也没问题，但答辩时你要清楚解释这套升级路径，否则老师问一句"为什么用这么新的版本"，反而不好回答。

7.3 前端依赖与跨域联调的常规问题

Vue前端最容易出问题的两个环节是依赖安装和网络代理。npm install失败经常出在node-sass这类需要本地编译的包上，Node版本过高时node-sass很容易编译失败，解决方案是换成dart-sass（sass包），或者在package.json里去锁Node版本。npm源在国内直连慢的问题也很好解决，npm config set registry https://registry.npmmirror.com换到国内镜像仓库就能把下载速度提上来。

还有一个前端细节：Element Plus组件库按需自动导入和全量引入，我建议项目里全量引入。全量引入虽然打包体积大一点，但省去了一大堆自动导入插件的配置，对于这套体量的项目完全够用，能少踩一个配置坑。如果你导入方式出了问题，常常表现为页面组件不显示但不报错，排查起来反而浪费时间。

7.4 生产环境部署的最小方案

开发完之后的部署，我给一个最小可用的流程：后端打成jar包，java -jar xxx.jar运行在8080端口；前端执行npm run build生成静态文件，放到Nginx的html目录；Nginx配置里对/api路径做反向代理到后端地址，其他资源直接指向静态文件。这一步做完，前端静态页面和后台接口就统一在同一个域名下，不再有跨域问题。很多同学到这个环节才开始后悔前面没有好好设计接口前缀，如果你从一开始就把所有业务接口挂到/api下，部署配置会顺利很多。

8. 后续提升方向与答辩准备：这套系统还差最后一块拼图

8.1 几个能直接落地的加分扩展

整体的核心功能跑通后，这套系统还有至少三个方向可以在答辩前快速提升。第一个是Redis缓存：把首页热门民宿列表和城市列表缓存起来，接口响应时间能从几百毫秒降到几十毫秒，起一个Redis容器、在Service层加两步判断缓存逻辑，代码量不大但谈起性能优化有真实数据支撑。第二个是展示层增强：管理后台用ECharts接入订单趋势图、民宿成交量Top5，统计SQL见前面5.5小节，这块东西视觉冲击力很强，评委扫一眼就知道你做了数据可视化。第三个是支付回调的抽象设计，把"模拟支付"按钮的对账逻辑抽象成一个RabbitMQ消息或者一个回调接口，为将来对接真实支付网关留下扩展位，这个设计思路比功能本身更能说明你对系统的理解。

8.2 答辩和面试最常被问到的三个问题

我总结了这套项目在答辩和面试环节最容易被问到的三个问题，以及我推荐的回答思路：

问：订单状态是怎么管理的？答：用一个字节字段存储，后端定义了枚举类和状态流转校验方法，待支付只能流转到已支付或已取消，已支付才能流转到已入住或已退款，不允许绕过中间态直接跳转。
问：如何防止同一房间同一时间段被重复预定的超卖问题？答：下单流程里加入了日期重叠校验和事务控制，同时订单表对order_no有唯一索引兜底；更严格的方案是在重叠校验SQL中使用悲观锁或对房间行加锁，但需要结合并发量来做取舍。
问：为什么用MyBatis而不用MyBatis-Plus/JPA？答：项目中的核心查询包含动态条件、多表关联和区间日期判断，手写SQL提供了最高的可控性和优化空间，也能确保对查询逻辑完全理解；MyBatis-Plus提升的是生产力，但在这种特定业务场景下手写SQL的收益更明显。

这三个问题是围绕该项目的最典型问题，提前组织好语言，比临时组织满嘴跑火车强得多。

8.3 我对这套项目的整体评价

这类全栈管理系统做的难度不在某个单个技术，而在于把十几张表、几十个接口、三套角色权限串成一条完整的业务流。民宿预定平台之所以是好的毕设和生产练习素材，就在于它的表间关系足够复杂、状态流转足够真实、角色权限足够分得开。如果你拿到的是某套现成源码，建议不要直接跑起来就完事，先打开数据库看看表结构，再在接口文档里从头捋一遍下单流程，然后自己动手改两个地方——比如给民宿列表加一个价格排序、给订单加上一个导出功能。凡是能独立改动功能、修复隐藏Bug的项目，才是真正变成你自己东西的项目。

最后再分享一个实际体会：这类项目的错误率高峰期集中在"照着别人的报告抄步骤"，而不是自己动手敲代码。表名自己建、SQL自己写、接口自己联，哪怕一开始慢一点，每一个坑都会变成答辩时的素材。这套民宿预定系统做完之后，返回头再看SpringBoot和MyBatis的那些面试题，理解会完全不一样。