每年到这个时间点，都会有学弟学妹找我聊同一个毕设题目：基于SpringBoot的民宿管理系统。这个题看名字平平无奇，可真做起来，在线预订、房态管控、订单状态流转、管理后台统计，每一块都能让人卡上两三天。带过几轮这个题之后，我最大的感受是：它难度不算高，但想做出一个"能讲清楚、能截图、能答辩"的版本，需求边界和核心订单逻辑一定要想透彻。这篇文章就按我自己带项目的顺序，从需求取舍、技术选型、数据模型、预订并发控制、运营统计一直讲到部署和答辩准备，适合正在写这个题目、或者打算把它列为备选毕设的同学参考。

1. 一个毕设选题背后，需求边界到底划到哪

1.1 别急着建表，先回答"这是谁的民宿"

很多同学拿到题目第一件事就是把 SpringBoot 框架跑起来，然后开始建 user、room、order 三张表。这么做前期很快，中期开始反复改表，后期统计对不上数。我习惯先拟一个最小业务场景：这是一家单店经营的民宿，大概 20 间客房、8 个房型，接待散客和线上订单。住客通过网站看房、查空房、下单、支付；前台负责办理入住、退房、换房、处理取消；店长管房价和日常运营；超管管员工账号。

场景一旦定下来，很多问题的答案就自动出来了。比如民宿和酒店最大的区别是：没有那么多标准间，往往每个房间都不一样，所以"房型"和"房间"必须分开建模；再比如房价不是统一价，周末和节假日会上浮，所以"房间-日期-价格"要独立存储，而不能在房间表里写死一个单价。这些细节在需求阶段不明确，后期就会变成不停改表结构的导火索。

我还会让学生把所有角色列一遍，写清楚每个角色最关心的三件事。住客关心的是有没有空房、多少钱、能不能退；前台关心的是今天哪几间入住、哪几间退房、剩下几间能卖；店长关心的是入住率、营业额、哪几个房型卖得好。这样搞完之后，功能边界就清楚了：前台要的是浏览和下单，后台要的是房态和统计，至于评论、优惠券这些都是后话。

1.2 功能清单：分清必须做、可以砍和坚决不做

我通常会让学生把功能分成三层。第一层是必须做的基础闭环：注册登录、房型列表、按日期查房、下订单、模拟支付、订单管理、后台房态日历、入住退房、基础统计。第二层是增强功能：评论、优惠券、价格日历可视化、经营报表、员工权限。第三层是别碰的功能：真实微信支付、小程序端、地图定位、多门店、App。砍掉它们的原因不是难，而是和个人开发者环境不匹配。

真实支付需要商户号、证书和回调域名，很多同学申请不到；小程序需要认证，又牵扯微信登录和审核，容易把选题拉偏。我建议用"模拟支付"替代真实支付：用户下单后跳到收银台页面，点"确认支付"后后台把订单状态推成已支付，同时预留一个 PayService 接口。答辩时老师问起来，你可以说这是为了完整跑通业务流程，同时保留了未来接入第三方支付的结构。这个说法比硬做一个没有完整回调链路的支付页面更站得住脚。

下面是我常用的功能优先级表，做计划时可以直接照这个来排：

很多人容易犯一个错：一边觉得 P0 太少，一边又在 P1 上花掉绝大部分时间。最后纸面功能很多，可核心闭环跑不通。我自己的原则是先把闭环跑通，再谈锦上添花。

2. SpringBoot民宿管理系统的技术栈组合与包结构设计

2.1 模块划分与包结构：单体项目也要有边界

SpringBoot 单体项目不等于把所有代码堆在一起。我推荐的做法是 controller 层按端拆分，service 按业务聚合，这样后面前台接口和后台接口做权限拦截时非常省事。目录结构大概是这样的：

com.example.minstay ├── controller │ ├── app # 前台：登录、房型、下单 │ └── admin # 后台：房态、订单管理、统计 ├── service │ └── impl ├── mapper ├── entity # 数据库实体 ├── dto # 请求参数 ├── vo # 返回视图 ├── config # Redis、Sa-Token、跨域 ├── common │ ├── exception │ ├── result │ └── enums └── task # 定时任务

这样拆不是因为强迫症，而是为了权限切面好写。比如给管理端接口统一加/admin前缀，Sa-Token 只需要拦截这个路径段；前台接口走另一套拦截规则。我见过一些项目 controller 不分端，权限判断散落在每个方法里，后面加一个功能就要翻半天代码。毕业设计答辩时，老师未必会细读每一行，但项目结构图一放出来，他一眼能看出你是有意识在做模块化设计。

另外，统一返回结构也要从一开始定好。我用的结构是{ code, message, data }，code 为 200 表示成功，其他为业务错误码。全局异常处理器捕获参数校验异常、业务异常、未知异常，分别转成对应的返回结构。这样前端 axios 就能统一拦截错误提示，不用每个接口单独写 try catch。加上这些，项目代码量会多一些，但清爽程度完全不是一个级别。

2.2 版本选型：别用最新，用"踩坑最少的组合"

我推荐一套相当稳的组合：JDK 1.8 + Spring Boot 2.7.18 + MyBatis-Plus 3.5.3 + MySQL 8.0 + Redis 6.x + Sa-Token 1.37.0 + Vue 3 + Element Plus + ECharts。前端脚手架用 Vite。为什么不用 Spring Boot 3.x？因为它强制 JDK 17，不少实验室电脑、机房环境装的是 JDK8，而且能搜到的报错资料少一截。对毕设来说，可搜索的报错记录数比版本新度重要得多。

MyBatis-Plus 的选择理由很直接：单表 CRUD、分页、LambdaQueryWrapper 都能少写很多代码，把精力留在订单状态机和房态并发这种真正值得写的地方。Redis 在这里不是摆设，验证码、日历价格缓存、订单防重锁都会用到，简历上也能写"使用 Redis 实现分布式锁与缓存"。如果你们学校要求必须用 SSM 或 JSP，别慌，核心设计是一样的，只是把 Controller 换成 Spring MVC 那一套。

2.3 哪些设计是加分项，哪些是给自己挖坑

有过一些同学上来就问要不要拆微服务，用 Nacos 注册中心、OpenFeign 调用。我的意见很明确：如果是 20 间房的民宿，微服务纯粹是给自己加戏。拆服务意味着数据一致性、服务通信、网关鉴权都要重新讲一遍，任何一个细节被追问都很难收场。单体应用把模块边界划清楚，已经足够展示工程能力。

真正值得加的包括：全局异常处理器、参数校验注解、统一返回结构、定时任务扫描超时订单、Redis 缓存房态快照。这些属于"工作量不大但一眼看得出是认真做的"设计。还有一点要提醒：如果时间只剩两周，Spring Security 这种重量级框架别硬上，配置类多、过滤器链复杂，远不如 Sa-Token 这种轻量框架容易讲清楚。毕设评分很少因为"用了某大厂框架"而加分，但会因为"能完整讲清楚自己做了什么"而加分。

3. 房态与房间数据模型：整个系统最值得花时间的地方

3.1 房型和房间为什么要分成两张表

民宿房间里经常出现"同一房型有多间房"的情况，比如阳光大床房有 5 间、山景双床房有 3 间。如果直接建一张 room 表，把面积、床型、朝向、图片都塞进去，那么同房型的每间房都要反复复制这些属性，改一次价格要改好几行，维护起来很痛苦。把房型抽出来作为模板，房间只存房间号和所属房型，就解决了这个问题。

房型表大概字段有：id、房型名、床型描述、面积、最大入住人数、基础价格、封面图、备注。房间表就是 id、房型id、房间号、楼层、当前状态。这里的"当前状态"我建议只作为展示用冗余字段，真正判断某晚能不能卖，看下面的按日房态表，否则两个字段容易打架。比如房间当前状态是可售，但今晚已经有人订了，这不矛盾，因为"今晚"要走日期维度去看。

3.2 按日房态表：价格日历和库存判断的依靠

这是整个系统里我最强调的一张表，叫 room_calendar 或者 tb_room_day。核心字段是：id、room_id、biz_date、price、status、更新时间，唯一索引建在 room_id + biz_date 上。status 用枚举，建议设计成可售、已预订、已入住、打扫中、维修中、锁定这几种。为什么不是房间表上一个状态字段就够？因为一间房今天可售、明天被订、后天要打扫，状态必须按日期去存。

如果只有订单表，判断某天是否可售就得查区间订单，遇到跨多天订单还会出现日期重叠判断，查询条件复杂不说，价格日历也做不出来。用按日房态表之后，查"国庆假期哪几天有空房"就变成一次普通的 between 查询，再按房间分组统计日期数是否等于区间长度，刚好等于说明连续有房。这个设计在答辩时讲出来，老师会觉得你真的理解数据建模，而不是只会复制 CRUD。

数据量可以顺手估算一下：20 间房，每天产生 20 条日历记录，一年约 7300 条。哪怕预留三年的历史数据，也不算大。所以完全不用考虑分区表、分库分表那些方案，毕设场景里一张清清爽爽的日历表就够了。如果要删历史数据，直接按月清理也不会影响订单表，因为订单表里保留的是快照信息和起止日期。

3.3 订单和房态的联动关系

订单表的主记录保存订单号、用户、联系人、入住起止日期、人数、总金额、状态；订单明细表保存每一间房的房型名、房间号、对应晚数和单价。这里有一个关键取舍：下单成功后，到底是先锁房态，还是等人工确认。我的答案是先锁，而且必须在同一事务里。

为什么？民宿在线预订的核心是"看到有房就能订"，如果下单后房态不变，两个用户订同一间房，到店才发现会非常尴尬。正确的流程是：订单状态为待支付时，先把对应日期的房态置为已预订；支付成功后继续保持已预订；超时未支付订单被取消，房态释放为可售。这样用户查到的可用性始终是真实可用性。如果民宿想保留人工确认环节，可以增加一个"待确认"状态，但这样一来在线预订的即时性就被削弱了，不太适合毕设展示。

4. 在线预订流程：并发防重与订单状态机的实现细节

4.1 订单状态机的完整流转

我建议在项目里把订单状态做成枚举类，不要把状态写成散落的字符串。全套状态至少包括：待支付、已支付、已入住、已完成、已取消、超时取消、退款中。状态迁移要受约束：待支付可以取消或超时取消；已支付可以办理入住；入住后只能正常退房完成；退款只能出现在取消之后，并且有对应退款单。

接口设计上，前台只需要暴露"创建订单、查询订单、模拟支付、取消订单"，其他状态变化都由后台或定时任务推动。每个 service 方法开头先判断当前状态是否允许该操作，非法流转直接抛业务异常。这个模式很简单，但能把很多隐藏 bug 挡在门外。比如一个订单已经被定时任务超时取消了，用户又跑来点取消，这时直接抛"订单已超时取消"即可，而不是傻傻地再改一次状态。

4.2 如何防止同一间房被重复预订

并发场景是评审老师最喜欢问的。最朴素的做法是每次下单前先查房态，可如果两个请求同时查，查询结果都可售，后面就都下单了。我采用的方案是两级保护：先用 Redis 分布式锁拦住同一房间、同一日期段的并发预订，再用数据库乐观更新兜底。

Redis 锁的 key 设计成房间维度，value 用 UUID，防止误删别人持有的锁。代码示意如下：

String lockKey = "room:book:" + roomId + ":" + checkInDate; String requestId = UUID.randomUUID().toString(); boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(10)); if (!locked) { throw new BizException("该日期房源刚刚被预订，请刷新后重试"); } try { // 锁内重新查询按日房态，确认每夜都可售 // 生成订单并更新房态 } finally { String current = redisTemplate.opsForValue().get(lockKey); if (requestId.equals(current)) { redisTemplate.delete(lockKey); } }

Redis 锁不能保证 100% 可靠，所以数据库层还要有兜底。更新房态 SQL 写成条件更新，只有当前状态还是可售时才允许改：

UPDATE room_calendar SET status = 'BOOKED' WHERE room_id = #{roomId} AND biz_date IN (...) AND status = 'AVAILABLE'

如果更新行数不等于需要锁定的晚数，说明区间内有房间已被占用，整个事务回滚。同时因为 room_id + biz_date 有唯一索引，不可能出现同一房间同一天有两行状态记录。这套组合在毕设场景里已经足够稳妥。有一点要提醒：锁内不要做太耗时的操作，比如远程调用、大量计算，否则锁持有时间过长反而成了性能瓶颈。

4.3 超时未支付订单的定时清理

待支付订单不能一直占着房，需要有超时释放机制。我用 SpringBoot 自带的 @Scheduled 实现一个订单扫描任务：每 30 秒查一次待支付且过期时间小于当前时间的订单，拿到后逐单执行取消。任务时间间隔用 fixedDelay 而不要用 fixedRate，避免上一次还没执行完下一次又开始了。

取消订单的 service 方法必须做状态校验，只能由待支付改为已取消，这样即使定时任务和管理员手动取消同时触发，也只有一次能成功。这里尤其不建议用 Redis 的 key 过期事件来做订单超时，因为过期事件并不可靠，存在延迟和丢失的可能，做成定时轮询反而更容易解释。扫描时记得加 limit，每次只处理一批，避免高峰期大量订单积压导致事务过长。释放房态时，直接用条件更新把已预订改回可售即可，不需要判断订单明细里的每间房。

5. 运营管理端与统计报表：让"管理系统"名副其实

5.1 后台权限模型：从两个字段升级到RBAC

如果后台只有管理员和普通用户两个角色，权限字段确实够用，但做民宿管理系统，前台接待和店长的职责明显不同。前台只能操作入住、退房、当天房态；店长可以改房价、看报表；超管管员工账号。这个场景很适合用 RBAC 模型：用户、角色、菜单三张核心表，再加上用户角色关联和角色菜单关联。

权限设计上，我用 Sa-Token 的注解，在接口上标@SaCheckPermission("order:checkin")，拦截器统一校验。答辩时老师问"如果新来一个实习生只给开房权限怎么办"，你就可以顺着 RBAC 的思路回答：给它分配一个只包含开房权限的角色即可。这句话往往比一堆代码更能证明你考虑过真实业务。如果学校要求必须用 Spring Security，也可以，只是配置过滤器链和自定义 UserDetailsService 要多花一点时间。

5.2 换房、改期与退款：最容易写错的后台操作

后台最容易出错的功能是换房和改期。换房的核心原则是：先锁定新房间，再释放旧房间。如果顺序反过来，旧房先释放，新房被抢，客人就无房可住。实现时先查新房在入住日期段的房态是否全部可售，可售则更新房态为已预订，再释放旧房，最后更新订单明细里的房间号。

退款也一样，民宿的取消策略通常分梯度：入住三天前免费取消，当天取消扣一晚房费。我建议把这些规则抽到配置表里，而不是写死在 if 里。退款操作生成 refund_record，把金额、订单号、操作人、时间都留下来。虽然毕设不一定要求财务严谨，但留下这个结构会让项目完整度上升一个档次。还有一个小细节：改期时，如果新日期价格比原来贵，需要生成一笔补差金额；如果便宜，要不要退差价也要写清楚，否则演示时数字对不上会很尴尬。

5.3 统计报表：别等数据多了才后悔没做聚合

运营端报表至少要包含几个指标：订单量、营业额、入住率、平均房价。入住率的计算方式是"某天已预订和已入住的房间数之和除以总房间数"，按日统计后自然能画出趋势图。数据量小的时候，直接查按日房态表 group by 日期就能算出来，不必预先聚合。

SELECT biz_date, COUNT(*) AS sold_rooms, ROUND(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM room), 2) AS occupancy_rate FROM room_calendar WHERE status IN ('CHECKED_IN', 'BOOKED') GROUP BY biz_date ORDER BY biz_date;

如果想展示更复杂的统计，比如"各房型本月贡献收入占比"，SQL 里 join 订单明细和房型表，按房型分组求和即可。前端用 ECharts 展示折线图和柱状图，后端只需要提供 JSON。这里有一个小提醒：统计接口不要嵌套太深的 SQL，先把指标定义说清楚，再写 SQL，不然答辩时算数对不上会很尴尬。演示前最好用固定日期的演示数据，让图表呈现出几条漂亮的曲线。

6. 部署、演示与答辩：细节决定项目能不能"收得漂亮"

6.1 本地启动清单与最容易翻车的环境问题

给同学排查启动问题时，遇到最多的就是：MySQL 时区报错、Redis 没启动、数据库字符集不是 utf8mb4、端口被占用。JDBC 连接串里记得加 serverTimezone=Asia/Shanghai，否则 MySQL 8 会报 CST 时区错误；Redis 没启动时后端启动不会直接报错，直到第一次存验证码才抛异常，所以演示前一定要确认 redis-cli ping 是通的。

数据库初始化我建议直接用 SQL 脚本，带上演示数据。前端用 Vite 代理解决跨域：在 vite.config.js 里把 /api 请求代理到 localhost:8080，这样不用在 SpringBoot 里开全局跨域，生产环境更干净。启动顺序固定为 MySQL、Redis、后端、前端，写成 README，答辩前照着走一遍。如果后端启动报端口冲突，就用netstat -ano | findstr 8080先查一下谁占了端口，实在不行改application.yml里的 server.port。

6.2 演示数据与演示脚本：提前把它走成肌肉记忆

做毕设项目最怕的是现场演示时手忙脚乱。我的建议是准备一个"演示剧本"，按固定顺序操作：先在首页看房型列表，选一个真实的未来日期区间下单，模拟支付，然后切到后台看房态日历被锁定，再办理入住、退房，刷新统计报表看到数据变化。用的日期最好选一个年内的真实日期，不要选已经过去的日子，否则校验直接拦住演示。

演示数据要有覆盖性：一部分房间是已预订状态，一部分是打扫中，一部分是维修中。这样房态日历一眼看上去是彩色的、有信息量的。账号信息提前写在演示文档上：管理员、店长、前台各一个账号。演示权限时，可以登录前台账号试试访问统计页面，证明拦截器生效。我甚至建议录一版操作视频，万一现场环境出问题，视频也能兜底，而且很多学校答辩时确实允许看视频演示。

6.3 答辩高频问题与怎么答得大方

我整理过几个几乎必问的问题。第一个是"为什么用 SpringBoot 而不是 SSM"：SpringBoot 简化配置、内嵌容器，但底层还是 Spring MVC + MyBatis，本质没有脱节。第二个是"两个人同时订同一间房怎么办"：讲清楚 Redis 分布式锁加数据库条件更新的双层保障。第三个是"按日房态表会不会数据量很大"：单店 20 间房，一年也才 7300 条记录，MySQL 完全可以接受，还可以按月清理历史数据。

第四个问题是"为什么不做真实支付"：核心是个人开发者没有商户资质，模拟支付已经保证业务闭环，接口预留了扩展。第五个问题是"系统能不能直接商用"：诚实回答核心功能可以支撑小微民宿日常运营，但商用还要考虑支付、短信通知、OTA 渠道同步、日志审计等工程问题。回答时态度要坦诚，把系统定位成"可演进的毕设原型"，这个说法比硬吹更让老师信任。

项目做完之后我自己最大的体会是，民宿管理系统真正难的其实不是框架，而是把"房态、订单、日期"这个小闭环想明白。只要这张数据模型是稳的，后面的接口、页面、统计都只是顺着业务逻辑往下走。最后再分享一个我自己的习惯：代码全部写完不是终点，把 README、数据库脚本、演示账号、答辩提纲放在同一个目录下，反复走三遍演示流程。很多被答辩问题问懵的同学，不是技术差，而是没提前把"为什么这样做"准备成自己的话。