这种基于SpringBoot+Vue的民宿管理系统源码项目，这几年一直特别多，到2025年依然有不少人拿着类似标题的代码来找我帮忙跑通、改需求。原因不复杂：民宿短租业务贴近实际、模块边界清晰、技术栈覆盖面够广，作为课程设计、毕业设计或者练手项目都很合适。但大多数人下载源码之后，第一反应是打开IDE直接点运行，然后被配置问题、数据库问题、版本问题淹没了。这篇文章我不谈怎么“一键运行打包好的源码”，而是站在把项目真正吃透的角度，把这种系统从需求拆解、表结构设计、后端核心逻辑到前端联调的完整链路讲清楚，同时把最容易翻车的几个坑单独拿出来说。

1. 项目拆解：民宿管理系统到底要管哪些事

拿到一个源码项目，第一件事不是看代码，而是把它的业务边界理清楚。民宿管理系统和酒店管理系统最大的区别在于规模。酒店有标准化的PMS流程、多级房态、复杂的账务，而民宿往往只有几十间房，甚至就是几个独立房源，运营角色也少。所以系统的核心不是把酒店系统做小，而是把“预订—入住—退房”这条主链路做得顺畅、直观。

1.1 三类角色，三条业务线

我把这类系统通常涉及的角色归纳为三类：管理员、前台操作员（或者叫管家）、住客。很多源码在权限上做得过度复杂，角色表、权限表、菜单表、用户角色关联表全套上阵，实际打开界面之后发现管理员和前台能做的事情差异极小。这是最典型的过度设计。

真正合理的划分是：管理员负责基础数据维护和统计，比如房型定价、房态调整、查看营收；前台操作员承接订单处理，比如登记入住、办理退房、处理取消；住客端的功能更单纯，就是查询房态、提交预订、查看自己的订单记录。如果源码里客户端和管理端都齐全，认证逻辑就要区分清楚。

• 后端权限：用一张简单的用户表加一个角色字段就够了，不推荐在这类小系统里引入重量级安全框架。
• API权限：写一个拦截器，用户未登录不能访问管理端接口，住客只能操作自己的订单。
• 前端权限：路由守卫判断登录状态和当前角色，普通用户进了管理页直接踢回首页。

1.2 订单状态机是整个系统的灵魂

民宿订单不是一条躺着的记录，它是有生命的。最基础的状态流转是：

待确认/待支付 -> 已确认/已支付 -> 已入住 -> 已退房 \-> 已取消

很多源码最大的问题就是订单状态不建模，用一个“状态”字段到处改，什么值都能往里塞。订单显示“已入住”但房间状态还是“空闲”，然后第二天查统计报表数据对不上，这种问题基本都源于状态没有统一管理。

我在自己的落地方案里，会把状态定义成枚举，而不是到处写字符串：

public enum OrderStatus { PENDING("待支付"), PAID("已支付"), CHECKED_IN("已入住"), CHECKED_OUT("已退房"), CANCELLED("已取消"); private final String desc; OrderStatus(String desc) { this.desc = desc; } }

不止是“存一个值”，每次状态变更同时触发对应动作才是状态机存在的意义。比如订单从“已支付”变成“已入住”时，房间状态要同步改为“入住中”；从“已入住”变成“已退房”时，房间恢复为“空闲”并顺手做一次卫生标记。如果状态机不统一，后面所有统计都是烂账。

1.3 需求膨胀控制法：第一版只做这些

我给这类项目定需求时有个“第一版清单”，超出清单的内容都会明确说不做：

支付对接第一版不做，是因为它会引入回调、签名、退款校验等大量外围逻辑，把核心业务淹没。房价日历不做，是因为一旦上线多日期价格，订单金额计算和库存校验都会复杂一个数量级。第一版只要订单金额能算对、房态不冲突，就已经超过市面上大部分毕设代码的水平了。

2. 技术选型的取舍：为什么是SpringBoot 2.7 + Vue 3 + MyBatis + MySQL

标题写了“2025最新”，但这种项目在2025年最值得注意的反而是“版本别乱追”。很多人在选型上喜欢动辄最新版，结果卡在依赖兼容性上一整天。我系统梳理一下这套组合里每个环节的选择理由。

2.1 后端版本：Spring Boot 2.7 让项目立即可跑

Spring Boot 3.x 出来也几年了，但说实话，在民宿管理系统这类中小型项目里，Spring Boot 2.7 依然是综合成本最低的选择。

• 首先，JDK 8 或 11 都能跑，学校机器、云服务器、老电脑都不挑。
• 其次，Spring Boot 3.x 把javax.*迁移到了jakarta.*，很多旧教程、旧依赖、网上的报错方案全都失效。你搜一个错误，答案大概率是老版本写法，改了还是错。
• 最后，MyBatis、PageHelper、Druid 这些常用组件对 2.7 的支持已经磨合到最稳的状态。

有人会问“2025年了还用2.7，是不是落后了？”我的判断是：项目的技术选型要看团队上手成本和稳定性，不是看版本号。如果这是一个新项目、开发者对 Spring Boot 3 很熟、依赖全部能找到对应版本，那完全可以用 3.x。但对拿源码来自学或者做毕设的场景，2.7 能把“跑起来”这个过程的风险降到最低。我会在源码的 pom 里固定 2.7.x 版本，不写不带版本号的依赖，避免几年后spring-boot-starter-parent解析到不兼容的版本。

2.2 持久层：MyBatis 的 SQL 可控性，在这个项目里是刚需

民宿管理系统的统计报表和订单查询，绕不开多表关联和复杂条件查询。用 JPA 当然也能写，但调试 SQL 时你会多一层“还要看自动生成的语句”的心智负担。MyBatis 把 SQL 明明白白摆在你面前，出问题一眼能看出来，改分页、加条件都是原地修改，这种可控性对中小项目非常重要。

源码里我的习惯是“注解 + XML 混合”。简单的单表增删改查，用注解就够了，比如用户登录查询、房间列表查询。订单列表、统计报表这种超过三行、有动态条件的 SQL，全部进 XML 文件统一管理。

@Mapper public interface OrderMapper { List<Order> selectOrderPage(@Param("query") OrderQuery query); }

对应的 XML 里写动态查询，这样后期维护的人不需要翻 Java 代码里的字符串拼 SQL，结构清楚很多。

2.3 前端：Vue 3 + Vite + Element Plus

标题只写了 Vue，具体用 Vue 2 还是 Vue 3 是个关键选择。2025年还写全新代码，我建议直接 Vue 3。Element Plus 是 Element UI 的 Vue 3 版，组件库成熟度已经很高，管理端界面需要的表格、表单、日期选择器、弹窗全都有现成组件，一套组合下来开发效率极高。

构建工具用 Vite 而不用 Vue CLI，核心原因是本地启动速度。Vite 冷启动基本在毫秒到百毫秒级，改代码热更新也是瞬时响应，开发体验比 Webpack 时代的 Vue CLI 舒服太多。如果你拿到的源码还是 Vue 2 + Element UI，也不是不能用，只是新增代码时要注意两套生态的写法差异，比如 Vue 3 的v-model和 Options API / Composition API 的区别。

2.4 MySQL 8.0 的初始化细节必须在开头就处理

MySQL 8.0 是当前主流，但很多源码运行失败不是代码问题，是数据库环境配置问题。最典型的是时区：MySQL 8.0 默认时区设置导致 JDBC 连接报The server time zone value '�й���׼ʱ��' is unrecognized，解决方案是 JDBC URL 显式指定：

spring.datasource.url=jdbc:mysql://localhost:3306/minisu?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

另外字符集要建库时就固定为utf8mb4，不要用老旧的utf8，否则遇到生僻字或表情符号（比如住客备注里有个emoji）写入报错时，排查起来特别难受。建库语句我通常给成：

CREATE DATABASE IF NOT EXISTS minisu DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

3. 数据库设计实录：房间、订单、价格这三块的核心细节

表结构设计决定这个系统的上限。我的经验是：房间表、订单表、价格表这三块是民宿系统最核心的资产，设计时多花十分钟，后面写代码能省掉三天。

3.1 房型拆房间，价格挂在房型上而不是房间上

新手容易做成一张room表，把房间号、楼层、床型、价格、面积全都塞进去，看起来表少、简单，但实际维护起来很痛苦。假设一个民宿有“大床房”这个房型共5间，其中3间朝南2间朝北，价格相同。如果你把价格字段放在每个房间里，哪天统一调价就要写5条 UPDATE；如果有一个房间临时作为“无窗特价房”，你得单独改那一行的价格，而房型分类也乱了。

所以拆成两张表：

CREATE TABLE `room_type` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '房型名称', `price` decimal(10,2) NOT NULL COMMENT '当前标准房价（元/晚）', `area` int DEFAULT NULL COMMENT '面积（㎡）', `bed_info` varchar(100) DEFAULT NULL COMMENT '床型描述', `status` tinyint DEFAULT '1' COMMENT '1上架 0下架', PRIMARY KEY (`id`) ); CREATE TABLE `room` ( `id` bigint NOT NULL AUTO_INCREMENT, `type_id` bigint NOT NULL COMMENT '所属房型ID', `room_no` varchar(20) NOT NULL COMMENT '房间号', `floor` varchar(20) DEFAULT NULL COMMENT '楼层', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0空闲 1入住 2清洁中 3维修', PRIMARY KEY (`id`), KEY `idx_type_id` (`type_id`) );

这样房型调价只改一条记录，所有房间跟着变；单个房间的特殊情况（比如临时维修改为维修状态）也有独立字段可以表达。这是典型的“维度分离”，成本极低但收益很大。

3.2 订单表必须有“快照字段”

民宿订单有一个很微妙的需求：今天下单的价格，可能在入住当天已经涨了；下单时填的入住人姓名，也可能后来改了。如果订单表只是关联房型表去取价格，那历史订单金额会随着房价调整而失真。所以订单表必须保存下单时刻的关键信息快照。

我的订单表设计里，除了必有的room_id外，还会冗余保存这些字段：

CREATE TABLE `orders` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `room_id` bigint NOT NULL, `room_type_id` bigint NOT NULL COMMENT '下单时房型ID', `room_type_name` varchar(50) DEFAULT NULL COMMENT '下单时房型名称快照', `room_no` varchar(20) DEFAULT NULL COMMENT '下单时房间号快照', `guest_name` varchar(50) NOT NULL COMMENT '入住人姓名', `guest_phone` varchar(20) NOT NULL COMMENT '入住人手机号', `check_in` date NOT NULL COMMENT '入住日期', `check_out` date NOT NULL COMMENT '退房日期', `night_count` int NOT NULL COMMENT '入住晚数', `total_price` decimal(10,2) NOT NULL COMMENT '订单总价快照', `status` varchar(20) NOT NULL DEFAULT 'PENDING', `remark` varchar(500) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_room_date` (`room_id`, `check_in`, `check_out`) );

room_type_name和room_no这种字段看起来是冗余，但它们是审计和客服场景下的救命稻草。客人打电话说“我上次住的印象中是什么什么房”，你查订单表直接看快照就行，不用反查房型当时叫什么名字。金额快照更是必须的，否则改价就会改动历史数据，财务对不上账。

3.3 预订冲突检测：日期区间重叠判断

这算是整个系统里最有技术含量的一块。民宿房间预订，核心约束是：同一个房间的已预订时间区间，不能和新的预订请求重叠。很多人写“防重复预订”直接用check_in > 已退房日之类的判断，其实漏掉了跨区间的场景，这要画个图就清楚了。

正确写法是区间重叠判断：查询目标房间在[checkIn, checkOut)这个区间内是否已经有有效订单。两个日期区间重叠的判定条件为：

已订订单的开始日期 < 新订单的结束日期 且 已订订单的结束日期 > 新订单的开始日期

对应 SQL 就是：

SELECT COUNT(*) FROM orders WHERE room_id = #{roomId} AND status NOT IN ('CANCELLED') AND check_in < #{checkOut} AND check_out > #{checkIn}

这里的边界定义很关键：退房日当天不占用房间，所以判断用<和>，而不是<=和>=。比如订单 A 是 3月10日入住、3月11日退房，它占用的是 3月10日晚上，3月11日该房间可以接新订单。新订单 3月11日入住、3月12日退房，判断条件变成3月10日 < 3月12日且3月11日 > 3月11日，第二个条件不成立，所以不冲突，正确。这也是我反复强调“退房日当天可再售卖”这个业务规则的落地方式。

3.4 房价日历表：第一版不做，但数据结构要有预留

之前说的房价日历，比如节假日涨价、淡季折扣，第一版我可以不做。但不代表连表结构都不留。我会在room_type表上保留price字段作为默认价，再留一个扩展的room_price_calendar表的注释位置，把room_type_id + date + price的复合字段结构想好，后续要做时只加表不动现有逻辑。这样既控制住第一版复杂度，又不把路堵死。

4. 后端核心实现：登录鉴权、状态流转、统计报表

后端代码里的三大支柱，我一般按登录鉴权、订单状态流转、统计查询来组织。这三个点做好，系统的骨架就稳定了。

4.1 登录认证：拦截器 + JWT 够用，不必引入 Spring Security

Spring Security 很强大，但对于民宿管理系统这类只需要一种登录态校验的项目，引入它反而会带来巨大的配置成本，过滤器链、密码加密器、认证管理器全是黑盒，出问题很难排查。我在这里的选择是：拦截器 + JWT，用最少代码解决“是否已登录、能否访问”的问题。

JWT 工具类的核心就两个方法：

@Component public class JwtUtils { private final String secret = "mini-su-project-secret"; public String generateToken(Long userId, String username) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000L * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); } }

拦截器注册时，放行登录接口和静态资源，其他接口必须带 token：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns("/**") .excludePathPatterns( "/auth/login", "/auth/register", "/front/**", "/error" ); } }

这个方案最大的优势是透明。每个接口是否被保护、哪些路径不需要保护，看配置一眼就知道，调 Bug 不需要跳进 Spring Security 的过滤器链里层层找原因。

4.2 订单状态流转：Service 里做合法性校验

状态机落到代码里，不是简单写 setter。每次状态变更都要校验“当前状态是否允许发生这个变更”。比如已取消的订单不能办入住，已退房的订单不能取消。把校验逻辑收拢到一个 Service 方法里，所有入口都走它，就不会出现数据被改乱的情况。

@Service public class OrderService { public void checkIn(Long orderId) { Orders order = orderMapper.selectById(orderId); if (order == null) { throw new ServiceException("订单不存在"); } if (!OrderStatus.PAID.name().equals(order.getStatus())) { throw new ServiceException("只有已支付订单才能办理入住，当前状态：" + order.getStatus()); } order.setStatus(OrderStatus.CHECKED_IN.name()); orderMapper.updateById(order); // 同步房间状态为“入住中” roomMapper.updateStatus(order.getRoomId(), RoomStatus.OCCUPIED.getCode()); } }

这个方法的重点有两个。第一，状态比对用枚举名而不是直接写字符串，避免魔法值。第二，订单状态更新和房间状态同步放在同一个事务方法里，中间任何一个失败都会回滚，不会出现“人入住了但房间还显示空闲”这种脏数据。

4.3 入住率统计：SQL 比你想的更需要边界条件

统计报表最常见的两个指标是入住率和营业额。营业额好做，直接按月份 SUM 有效订单金额即可。入住率则复杂一点，因为要在“没有订单的房间”上也做考虑。

我的思路是：某个月的入住率 = 当月有效订单占用的“房间晚数” / （总房间数 × 当月天数）。核心 SQL 是查出所有有效订单在该月内的占用晚数：

SELECT IFNULL(SUM(DATEDIFF( LEAST(check_out, DATE_ADD(#{month}, INTERVAL 1 DAY)), GREATEST(check_in, #{month}) )), 0) FROM orders WHERE status IN ('PAID', 'CHECKED_IN', 'CHECKED_OUT') AND check_in < DATE_ADD(#{month}, INTERVAL 1 DAY) AND check_out > #{month}

这里故意用LEAST和GREATEST把跨月订单截断到当月区间内。比如订单是 1月31日入住、2月2日退房，统计 2 月时只算 2 月 1 日这一晚，1 月那晚归 1 月统计。这样每个月加起来才是准确的，不会重复计也不会漏计。这也是统计报表模块最容易写错的地方，很多人直接DATEDIFF(check_out, check_in)，结果跨月订单全算到了结束月头上。

4.4 MyBatis 的 SQL 片段复用

订单查询的筛选条件很多，比如按状态查、按日期范围查、按手机号后四位查。如果每个 SQL 都复制一遍条件，后期改一个字段就要改 N 处。在 XML 里用<sql>片段可以很好解决：

<sql id="orderQueryCondition"> <where> <if test="status != null and status != ''"> AND status = #{status} </if> <if test="checkInStart != null"> AND check_in &gt;= #{checkInStart} </if> <if test="checkInEnd != null"> AND check_in &lt;= #{checkInEnd} </if> <if test="keyword != null and keyword != ''"> AND (guest_name LIKE CONCAT('%', #{keyword}, '%') OR guest_phone LIKE CONCAT('%', #{keyword}, '%')) </if> </where> </sql>

列表分页查询、导出统计、后台订单筛选都能引用同一个片段，条件永远保持一致。别小看这个细节，写小型系统时一开始感觉无所谓，等加了五六个查询接口后，这就是救命的。

5. 前端页面实现与接口联调：跨域代理、路由守卫、请求封装

后端接口写得再规范，前端联调团队不顺畅，整个系统依然跑不起来。这一节说几个 Vue 3 前端项目里最容易踩的落地细节。

5.1 Vite 代理解决本地跨域，而不是到处开 CORS

本地开发时，前端跑在 3000 端口，后端跑在 8080 端口，直接发请求必然跨域。很多源码的做法是在后端加 CORS 全局配置，能用但属于治标不治本，生产环境真正同源部署时那套配置反而多余。

更干净的方式：本地开发全走 Vite 代理，让浏览器以为请求是同源的。

// vite.config.js import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

这样 axios 写baseURL: '/api'就行，开发环境走 Vite 代理转发到 8080，生产环境把前端打包后的静态文件交给后端一起部署，接口路径保持一致，不需要改任何代码。

5.2 路由守卫：用最直接的办法控制页面访问

民宿管理系统的前端页面不多，登录页、管理首页、房间管理、订单管理、客户管理、统计页、个人中心。路由守卫的核心任务就两个：未登录不允许进管理页；不是管理员不允许进系统管理页。

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

这个方案虽然“不够动态”，对一个固定模块的小系统来说完全够用，而且逻辑清楚，接手的人一行行读都能看懂。我见到很多项目在这上面非要搞“动态菜单 + 后端返回路由表”，结果菜单加载慢、刷新页面路由崩，复杂度上去了体验却更差。

5.3 Axios 封装：请求拦截统一带 Token，响应拦截统一处理 401

每天都要跟接口打交道，如果你在每一个页面里都手动取 token、手动加 header，那是给自己找麻烦。用 axios 拦截器统一处理一次，后面所有接口都不用操心这些。

import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) service.interceptors.response.use( response => { // 和后端约定：统一返回体 { code, data, msg } return response.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') window.location.href = '/login' } return Promise.reject(error) } ) export default service

统一返回体这个习惯要在项目一开始就定下来。前端所有接口都用{ code, data, msg }的结构包裹，前端判断code === 200再取 data，这样后端加个异常提示、加个业务状态码都很顺手，不会出现“接口到底返回数组还是对象还得猜”的情况。

5.4 日期范围选择组件：注意提交格式和后端解析

订房业务离不开入住日期和退房日期的选择。Element Plus 的el-date-picker类型设为daterange后，拿到的是一个数组，必须注意格式转换。

我的习惯是日期范围传给后端时统一转成check_in=2025-06-01&check_out=2025-06-03这种字符串，后端用@RequestParam加@DateTimeFormat(pattern = "yyyy-MM-dd")来接收。如果你直接传 Date 对象，还得处理时区偏移，很容易早 8 小时、晚 8 小时地出错。这个细节看起来简单，但我在帮人排查代码时见到的频率非常高。

6. 源码从 0 到 1 跑通的顺序与排错清单

最后说点接地气的：拿到一份源码之后，正确的启动顺序和常见的故障判断。很多人卡了一天的问题，其实只是启动顺序不对或者缺了某个前置步骤。

6.1 拿到项目后的三步标准化检查

第一步也是最重要的一步，看清数据库脚本建库语句和表前缀。导出的 SQL 文件名、脚本里的 CREATE DATABASE、后端的spring.datasource.url三个地方的库名必须完全一致，差一个字符或字母大小写不一致都连不上。

第二步检查 JDK 版本和 Maven 配置。Spring Boot 2.7 要求 JDK 8 或更高，如果本机是 JDK 17，部分依赖版本可能报反射访问警告，但通常不影响运行；真正容易崩的是 Maven 仓库里缺私服依赖，换源之后重新mvn clean install。

第三步修改后端配置里的本地环境差异。需要改的通常只有三项：数据库密码（spring.datasource.password）、Redis 地址（如果系统依赖 Redis）、文件上传本地存储路径（file.upload-dir）。配置全部集中在一个application.yml文件里，不要散落多处。

6.2 初始化数据库：不是双击导入就完事

用 Navicat 或命令行导入 SQL 时，要选择对应数据库再执行，不是双击 SQL 文件就自动进入目标库。有外键时脚本里的建表顺序也很重要，先建父表（room_type、sys_user）再建子表（room、orders），否则会报Cannot add foreign key constraint。

导入完成后做一个极简验证：打开 orders 表看一眼有没有示例数据。很多源码脚本会附带几条演示数据，这说明导入成功；如果没有数据也不代表失败，但最好手动插入一条房间记录再往下走，空数据库很容易让前端页面一片空白，你还没法判断是后端问题还是数据问题。

6.3 启动顺序与验证清单

后端先启动，观察控制台打印。日志出现Started Application in x.xxx seconds之前，不要动前端。

后端启动成功后不要急着启动前端，先用接口测试工具验证几个关键接口。登录接口、房间列表接口、订单列表接口各调一次，确认返回数据正常。这一步能把前后端问题切成两段：前端启动后发现页面报错，至少能确定后端是好的。

验证没问题再启动前端，访问页面，走一遍完整流程：登录 → 看房态 → 提交订单 → 办理入住 → 退房 → 看统计。全过程走完，系统才算真正跑通。很多人在这一步只是打开了个首页，看一眼没报错就关了，真正的问题是订单流程根本走不通，到答辩前一天才发现。

6.4 两个高频运行期故障：8小时差和 MyBatis 数字条件失效

第一个故障，数据时间少了 8 小时或者多了 8 小时。这是时区问题，通常出现在两个地方：JDBC 连接没指定serverTimezone=Asia/Shanghai，或者后端接收前端日期时没指定@DateTimeFormat的 pattern。处理方式很简单，统一在配置和注解上强制指定上海时区即可。

第二个故障非常隐蔽，也是 MyBatis 新手高频踩坑。写动态 SQL 时经常有人写：

<if test="status != ''">

status是 Integer 类型时，这个条件在 status 为 0 的情况下会被当成 false，导致“查询状态为0的记录”时条件被忽略，结果全表都查出来了。正确写法是用!= null判断：

<if test="status != null">

这个坑的本质问题是：MyBatis 的 OGNL 表达式里，Integer 0可以被!= ''判定为 false，字符串和数字的类型比较不是你想当然的规则。凡是遇到查询结果莫名缺失、条件像被吞了一样，优先排查if test的条件写法。

最后说两句大实话

我每次带着别人跑通这类民宿管理系统源码，最大的感受是：大部分项目失败的根因都不在代码本身，而是“没有按顺序验证”。数据库没通就看页面、后端没起就改前端、订单流程没走就写论文，这种顺序早晚要出大事。这个系统其实不算难，难的是把每一层都扎扎实实验证过去。如果你正在折腾这个项目，不妨按我上面说的顺序一步一步来，中间碰到问题时优先看控制台给出的第一行错误，而不是盯着页面上的报错提示瞎猜。跑通一遍之后，你会对整个前后端项目结构有完全不一样的理解。