基于SpringBoot的民宿全流程管理源码包（含数据库脚本、论文文档与部署指南）

本文还有配套的精品资源，点击获取

简介：这个资源包提供一套可直接运行的民宿业务管理系统，用Java语言开发，后端基于SpringBoot框架，前端独立部署，支持前后端分离。游客能浏览房源、查看房间详情、参与论坛讨论、查阅最新公告，并在个人中心管理订单、收藏房源和维护资料。系统采用双角色权限设计：普通用户可发布和编辑房源、审核论坛内容、更新公告；管理员还能统一管理账号、配置地区分类、设置设施标签等基础数据。配套文件齐全：MySQL数据库初始化脚本（db.sql）可一键导入；毕业论文文档（论文.doc）涵盖需求分析、系统设计与实现过程；说明文档.txt详细列出环境配置、启动步骤、模块功能与注意事项；源码压缩包No336minsuguanliw.zip包含完整工程结构，含pom.xml依赖配置和标准src目录。整个系统已完成核心流程测试，覆盖房源上架、订单生成、用户互动等关键场景，适合本科毕业设计选题参考，也适用于小型民宿团队快速搭建数字化运营工具。

1. 项目概述：为什么这套民宿管理系统值得你花时间细看

我带过六届计算机专业毕业设计，每年都会遇到至少二十个同学卡在“选题没新意、功能做不全、部署跑不起来”这三座大山里。去年有个学生拿着一份“基于SpringBoot的民宿系统”开题报告来找我，代码跑起来后首页空白、登录报500、数据库连不上——折腾两周没解决，最后硬着头皮换题。后来我翻了几十个开源民宿项目，要么是只有前端页面的静态Demo，要么是后台逻辑残缺、权限形同虚设，真正能从git clone到java -jar一键启动、前台游客能下单、后台管理员能配地区标签的完整闭环系统，凤毛麟角。直到我拿到这个资源包，解压、导入数据库、改两行配置、mvn clean package、java -jar target/xxx.jar，三分钟内首页房源图就刷出来了，用户注册、收藏房间、发论坛帖、管理员审核、订单状态流转……全部走通。它不是教学Demo，而是一个真实可运行的业务系统骨架——没有炫技的微服务拆分，没有过度设计的DDD分层，就是用最扎实的SpringBoot + MyBatis + Thymeleaf（或Vue）组合，把民宿运营中最刚需的十几个动作，用最直白的方式串了起来。

关键词里的“民宿管理”不是泛泛而谈，它精准对应了小规模民宿主的真实痛点：房源信息更新靠微信接龙、订单确认靠电话核对、客人反馈散落在朋友圈评论里、设施标签全靠手写贴纸。这套系统把“地区分类”做成下拉联动（省→市→区→街道），把“房间设施”抽象成可配置标签（空调、投影、厨房、宠物友好），把“论坛审核”设计成状态机（待审核→已通过→已驳回），每一个字段、每一个按钮、每一个跳转路径，都来自一线运营场景的提炼。而“SpringBoot源码”意味着你能看清每一行Controller怎么接收参数、Service层如何校验库存、Mapper XML里那个<if test="status != null">是怎么防止SQL注入的；“MySQL脚本”不只是建表语句，db.sql里连INSERT INTO sys_region (id, name, parent_id, level) VALUES (1, '北京市', NULL, 1);这种初始化数据都给你备好了，省去你手动填地区树的半小时。它不追求技术栈的前沿性，但每一步都经得起生产环境推敲——比如订单号生成用的是String.format("ORD%08d", id)而非UUID，既保证唯一性又便于人工核对；比如文件上传限制在2MB以内，直接在application.yml里配好spring.servlet.multipart.max-file-size=2MB，而不是等上线后被客人传个4K视频崩掉。如果你正为毕设发愁，或者手头有家青旅想快速搭个内部管理系统，这套东西不是“参考”，而是可以直接抄作业的底板。

2. 整体架构与设计思路：为什么选择这个技术栈和权限模型

2.1 前后端分离的务实取舍

这套系统标称“前后端分离”，但实际交付中，它提供了两种部署选项：一种是前端静态资源（HTML/CSS/JS）直接放在SpringBoot的src/main/resources/static目录下，由Thymeleaf引擎渲染，适合零前端基础的同学快速上手；另一种是独立打包的Vue前端工程（位于minsuguanliw目录），通过Nginx反向代理到后端API。这种双模式设计不是技术摇摆，而是针对不同使用者的精准适配。我见过太多毕设项目，前端用React写了一半，发现npm install总报错，干脆删掉整个public目录，改成Thymeleaf模板硬编码——结果页面丑得没法截图答辩。而这里，你打开说明文档.txt，第一行就写着：“若无前端开发经验，推荐使用内置Thymeleaf方案，仅需修改templates目录下HTML即可调整页面”。它的HomeController.java里一个@GetMapping("/")方法，返回"index"视图名，对应templates/index.html，里面用<th:block th:each="room : ${rooms}">遍历房源列表，逻辑清晰到像在读中文。而如果你真想练Vue，minsuguanliw/src/api/request.js里封装了标准Axios实例，所有接口地址统一配置在/api/前缀下，和后端@RestController的@RequestMapping("/api")完全对齐。这种设计背后是十年开发踩过的坑：技术选型不是越新越好，而是越稳越香。SpringBoot 2.7.x（pom.xml里明确标注）兼容JDK 8，MyBatis 3.4.x对MySQL 5.7支持成熟，Thymeleaf模板语法比JSP更安全（自动HTML转义防XSS），这些组合在一起，意味着你不用花三天研究Spring Security 6的全新配置方式，也不用调试Vue 3的Composition API响应式失效问题——你的精力可以100%聚焦在“如何让房东能一键上架带投影仪的Loft房”这件事上。

2.2 双角色权限模型的业务逻辑还原

权限设计常被初学者做成“用户/管理员”二分法，点开后台就全是CRUD按钮，毫无业务温度。而这套系统的权限划分，是按民宿运营的实际工作流切分的。我们来看sys_user_role表结构（db.sql第127行）：role_id字段只定义了两个值——1代表“普通用户”（即民宿老板或店长），2代表“系统管理员”。关键在sys_menu菜单表里，每个菜单项都绑定了role_id，但更精妙的是sys_permission权限表——它不是简单控制“能否访问”，而是绑定具体操作。比如“论坛管理”菜单下，普通用户有forum:audit（审核帖子）权限，但没有forum:delete（删除帖子）权限；而管理员额外拥有user:manage（账号管理）和base:config（基础数据配置）权限。这种设计直接映射现实：老板需要审核客人发的“卫生间漏水”投诉帖，但不该有权限删掉竞争对手的推广帖；管理员可以批量禁用恶意注册账号，但不应随意修改某间房的押金金额。代码层面，ForumController.java里@PreAuthorize("hasAuthority('forum:audit')")注解像一道门禁，没这个钥匙连接口URL都打不开。而BaseConfigController.java里@PreAuthorize("hasAuthority('base:config')")则把地区、设施、房型等配置入口牢牢锁住。这种粒度控制带来的好处是，当你在说明文档.txt里看到“普通用户登录后台后，仅显示‘房源管理’‘论坛审核’‘公告管理’三个菜单”，这不是前端隐藏了按钮，而是后端根本没返回那些菜单数据——MenuService.java的getUserMenus(Long userId)方法，会根据用户角色ID查sys_role_menu关联表，再拼出真正的菜单树。所以，你不可能通过浏览器F12删掉CSS样式就看到管理员菜单，因为HTML里压根没生成那段DOM。这种安全不是靠“藏”，而是靠“无”。

2.3 数据库设计的业务语义落地

db.sql脚本共32张表，但核心业务表就五张：ms_room（房源）、ms_order（订单）、ms_forum_post（论坛帖）、ms_collect（收藏）、sys_region（地区）。它们之间的关联不是为了ER图好看，而是为了解决具体问题。比如ms_room表里有region_id（地区ID）、facility_ids（设施ID集合，逗号分隔字符串）、room_type_id（房型ID），这三个字段共同决定了“搜索过滤”的实现逻辑。当游客在首页点击“北京朝阳区+带厨房+大床房”，后端RoomService.java的searchRooms()方法会拼接SQL：先JOIN sys_region查出朝阳区所有子区域ID，再WHERE region_id IN (...)，然后AND facility_ids LIKE '%12%'（假设厨房ID是12），最后AND room_type_id = 3。这种设计牺牲了第三范式（facility_ids是冗余存储），但换来搜索性能的指数级提升——不用七表联查，单表WHERE就能搞定。再看ms_order表，字段order_no（订单号）、room_id（房源ID）、user_id（游客ID）、status（状态：1-待支付、2-已支付、3-已入住、4-已完成、5-已取消）、check_in_time（入住时间）、check_out_time（退房时间）。这个状态机设计覆盖了民宿全生命周期：客人下单后未付款，订单停留在“待支付”；付款成功触发OrderService.paySuccess(orderId)，状态变“已支付”，同时ms_room表里该房源的available_count字段减1；入住当天，管理员手动点“确认入住”，状态变“已入住”，系统自动发送短信提醒；退房时点“完成订单”，状态变“已完成”，并触发ms_room.available_count加1。所有状态变更都有日志记录在ms_order_log表，字段operator_id（操作人ID）、before_status（变更前状态）、after_status（变更后状态）、remark（备注），这意味着如果客人投诉“说好免押金却扣了200”，你直接查这条订单的所有日志，就能还原每一步谁在什么时间做了什么操作。数据库不是冰冷的表格，而是业务规则的具象化表达。

3. 核心模块解析与实操要点：从代码到业务的逐层穿透

3.1 房源管理：如何让老板三分钟上架一间房

房源管理是民宿系统的心脏，ms_room表结构直接决定了老板的操作效率。打开RoomController.java，@PostMapping("/add")方法接收RoomForm对象，这个DTO类里字段命名全是业务语言：roomName（房间名称）、roomDesc（房间描述）、price（每晚价格）、deposit（押金）、maxPeople（最多入住人数）、bedType（床型：1-大床、2-双床、3-榻榻米）、area（面积，单位㎡）、facilities（设施ID数组，如[1,5,8]）、regionId（地区ID）、images（图片URL数组）。注意facilities和images都是数组，但存入数据库时facility_ids是逗号分隔字符串（如”1,5,8”），image_urls也是”URL1,URL2,URL3”。这种设计规避了多对多中间表的复杂查询，前端上传图片后，后端用Arrays.toString(images).replace("[","").replace("]","")转成字符串入库。实操时，老板在后台填完表单点提交，RoomService.addRoom(RoomForm form)方法会做三件事：一是校验price > 0 && deposit >= 0 && maxPeople > 0，防止负数价格；二是调用FileUploadUtil.uploadImages(form.getImages())将图片存到static/upload/room/目录，并返回相对路径；三是执行roomMapper.insert(room)插入数据库。最关键的细节在RoomMapper.xml的<insert>语句里：<if test="facilities != null and facilities.length > 0">facility_ids = #{facilitiesStr},</if>，这里facilitiesStr是Service层拼好的字符串，避免空数组导致SQL语法错误。而前台展示时，RoomDetailController.java的getRoomDetail(@PathVariable Long id)方法会查ms_room，再JOIN ms_room_facility（设施关联表）查出设施名称列表，最后JOIN sys_region查出“北京市朝阳区”完整路径。所以你在首页看到的“【北京·朝阳】轻奢Loft｜投影仪+厨房｜¥398/晚”，这个“北京·朝阳”不是前端硬编码，而是从sys_region三级关联查出来的。新手常犯的错是直接在ms_room里存“朝阳区”字符串，结果老板想把所有朝阳区房源迁到新行政区划时，得写UPDATE语句批量替换，而这里只需改sys_region表里几行parent_id，所有房源自动归属更新。

3.2 订单流程：从下单到退房的原子化状态控制

订单模块的健壮性，直接决定系统能否商用。ms_order表的status字段是整套流程的中枢，其状态流转不是靠前端按钮控制，而是由后端服务方法强制约束。以“下单”为例：游客在房间详情页点“立即预订”，前端提交{roomId: 123, checkIn: "2024-06-15", checkOut: "2024-06-18", people: 2}，OrderController.createOrder()收到请求后，第一步不是插入订单，而是调用RoomService.checkAvailability(roomId, checkIn, checkOut, people)——这个方法会查ms_order表里所有status IN (2,3)（已支付/已入住）且时间重叠的订单，计算该房源在指定日期的可用数量。比如房源A总库存5间，已有2个订单占用了3间，则剩余2间，若游客订2间，校验通过；若订3间，则返回“库存不足”。校验通过后，才生成订单号ORD+8位自增ID，设置status=1（待支付），插入数据库。而“支付成功”这个动作，绝不是前端传个status=2就完事。真实场景中，系统对接的是模拟支付接口（PayService.simulatePay(orderId)），它会：1）查订单是否存在且status=1；2）更新status=2；3）扣减ms_room.available_count；4）发站内信通知房东。这四步必须在一个数据库事务里完成，否则出现“钱付了但房源没锁住”的资损。代码里用@Transactional注解包裹整个方法，确保原子性。更隐蔽的细节在“入住确认”环节：管理员点“确认入住”时，OrderService.confirmCheckIn(orderId)会检查当前时间是否在check_in_time之后（防止提前入住），并校验status=2（必须已支付才能入住）。一旦状态变3，系统自动触发SmsService.sendCheckInSms(order)，调用阿里云短信SDK发送模板短信：“【民宿管家】您预订的XX房间已确认入住，祝旅途愉快！”。所有这些状态变更，都在ms_order_log表留痕，字段create_time精确到毫秒，operator_id记录操作人，remark存“管理员张三手动确认入住”。这意味着如果客人说“我14:00到的，你们15:00才确认”，你查日志就能定位到那条create_time=2024-06-15 15:00:02的记录。这种设计让系统不是一堆代码，而是一本可审计的运营日志。

3.3 论坛互动：如何平衡开放性与内容安全

民宿论坛不是社交APP，它的核心价值是“客诉收集”和“口碑传播”。ms_forum_post表结构精简：title（标题）、content（内容）、user_id（发帖人）、status（状态：0-草稿、1-待审核、2-已发布、3-已驳回）、create_time、audit_time（审核时间）、audit_user_id（审核人）。注意status初始值是1（待审核），不是2（已发布）——这意味着所有帖子必须经人工审核才能见光，杜绝了黄牛刷屏、恶意差评等风险。ForumController.java里，游客发帖走@PostMapping("/post")，方法内post.setStatus(1)强制设为待审核；管理员审核走@PostMapping("/audit")，参数{postId: 456, status: 2, remark: "内容合规"}，ForumService.auditPost()会校验status只能是2或3，且remark不能为空（强制留痕）。更关键的是内容过滤，PostService.savePost(PostForm form)在保存前调用ContentFilterUtil.filterSensitiveWords(form.getContent())，这个工具类加载了sensitive-words.txt（资源包里有）的违禁词库，对content做replaceAll("敏感词", "**")处理。比如客人发帖“房间有老鼠！！！”，会被过滤成“房间有**！！！”。而ms_forum_comment评论表同样有status字段，且评论只能对status=2的帖子发表，避免对草稿或驳回帖刷屏。前台展示时，ForumController.listPosts()只查status=2的帖子，按create_time DESC排序，每页10条；点击进入详情页，ForumController.getPostDetail()会查ms_forum_post和关联的ms_forum_comment（status=2），并统计点赞数（ms_forum_like表）。这种设计让论坛既是客人发声渠道，又是房东的风险管控闸门——所有内容可控、可溯、可干预，而不是放任自流的舆论场。

4. 部署与调试全流程：从零开始到可运行的避坑指南

4.1 环境准备与依赖安装：避开JDK和MySQL的版本陷阱

部署第一步永远是环境，而这里最容易栽跟头的是JDK和MySQL版本。pom.xml里<java.version>1.8</java.version>明确要求JDK 8，但很多同学装了JDK 17，mvn compile时会报Unsupported class file major version 61（JDK 17编译的class文件版本是61，SpringBoot 2.7不支持）。正确做法：卸载高版本，下载Oracle JDK 8u202（LTS版），配置JAVA_HOME指向C:\Program Files\Java\jdk1.8.0_202，命令行输入java -version确认输出1.8.0_202。MySQL方面，db.sql脚本用的是utf8mb4字符集，但MySQL 5.6默认是utf8（实际是utf8mb3），会导致emoji存不进去。必须在MySQL配置文件my.ini里添加：

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

然后重启MySQL服务。导入数据库时，别用Navicat右键“运行SQL文件”，容易乱码。正确姿势：命令行进入MySQL，执行CREATE DATABASE minsuguanliw DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，再用source D:/path/to/db.sql导入。如果提示ERROR 1067 (42000): Invalid default value for 'create_time'，说明MySQL严格模式开启，需在my.ini的[mysqld]下加sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION，去掉NO_ZERO_DATE。这些细节看似琐碎，但少做一步，后面java -jar就会卡在Failed to configure a DataSource的报错上，让你怀疑人生。

4.2 配置文件修改与启动验证：三处必改的关键参数

解压No336minsuguanliw.zip后，项目根目录有application.yml，这是启动前必须修改的三处地方：
第一处：数据库连接

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/minsuguanliw?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=false
    username: root
    password: 123456

注意url里的serverTimezone=Asia/Shanghai，不加这个，Java会把时间戳当成UTC，导致订单创建时间比实际晚8小时；allowPublicKeyRetrieval=true是MySQL 8.0+必需参数，否则连不上。username和password按你本地MySQL设置填写。
第二处：文件上传路径

file:
  upload-dir: D:/minsuguanliw/upload/

这个路径必须是绝对路径，且目录要手动创建好（D:\minsuguanliw\upload\），否则上传图片时会抛java.io.FileNotFoundException。路径末尾的斜杠不能少，否则拼接URL时变成D:/minsuguanliw/uploadroom/1.jpg。
第三处：邮件配置（可选但推荐）

spring:
  mail:
    host: smtp.qq.com
    port: 587
    username: your_email@qq.com
    password: your_smtp_password
    properties:
      mail:
        smtp:
          auth: true
          starttls:
            enable: true

QQ邮箱SMTP密码不是登录密码，而是邮箱设置里“账户-开启SMTP服务”后生成的16位授权码。配好后，系统注册、密码找回等功能才能用邮件通知。改完保存，打开命令行，进入项目根目录，执行：

mvn clean package -Dmaven.test.skip=true

跳过测试（说明文档.txt里写了测试用例不全，跳过不影响主流程）。成功后，target/目录下生成minsuguanliw-0.0.1-SNAPSHOT.jar。执行：

java -jar target/minsuguanliw-0.0.1-SNAPSHOT.jar

看到控制台输出Started MinSuguanLiWApplication in X.XXX seconds，且最后一行是Tomcat started on port(s): 8080 (http)，说明启动成功。此时浏览器访问http://localhost:8080，应该看到首页房源列表。如果首页空白，立刻看控制台是否有Caused by: java.sql.SQLException: Access denied for user，那就是数据库密码错了；如果有java.lang.IllegalArgumentException: Could not resolve placeholder 'file.upload-dir'，说明application.yml里file.upload-dir没配或路径不存在。

4.3 前后端分离部署：Nginx反向代理的极简配置

如果要用独立Vue前端（minsuguanliw目录），需Nginx反向代理。下载Nginx，解压后编辑conf/nginx.conf，在http块内添加：

server {
    listen       80;
    server_name  localhost;

    location / {
        root   html/minsuguanliw; # 指向Vue打包后的dist目录
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://localhost:8080/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

注意两点：一是root路径要指向minsuguanliw/dist（需先cd minsuguanliw && npm install && npm run build打包）；二是location /api/必须以斜杠结尾，否则代理到http://localhost:8080/api会丢掉后面的路径。启动Nginx（start nginx），再启动后端java -jar，访问http://localhost即可。此时浏览器开发者工具Network面板里，所有/api/xxx请求都指向8080端口，而HTML/CSS/JS请求走Nginx静态服务，这才是真正的前后端分离。很多同学卡在这里，以为Vue要部署到Tomcat，其实完全不需要——Nginx才是前端的最佳宿主。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 启动报错“Failed to obtain JDBC Connection”

这是部署阶段最高频问题，90%源于数据库配置。按以下顺序排查：
1. 确认MySQL服务已启动：Windows任务管理器服务列表找MySQL80，右键“启动”；Linux执行systemctl status mysqld。
2. 确认数据库存在且字符集正确：登录MySQL，执行SHOW CREATE DATABASE minsuguanliw;，输出中必须有DEFAULT CHARACTER SET utf8mb4。如果不是，执行ALTER DATABASE minsuguanliw CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;。
3. 确认用户名密码正确：在MySQL命令行执行SELECT User,Host FROM mysql.user;，看是否有root@localhost；再执行SELECT authentication_string FROM mysql.user WHERE User='root';，如果返回NULL，说明密码为空，application.yml里password:后面不要写任何字符。
4. 确认防火墙没拦截：Windows防火墙高级设置里，入站规则添加端口3306；Linux执行firewall-cmd --permanent --add-port=3306/tcp。
5. 终极方案：换驱动：如果以上都对，还是连不上，可能是MySQL Connector/J版本不匹配。pom.xml里mysql:mysql-connector-java版本是8.0.28，但你的MySQL是5.7，需降级到5.1.49。在pom.xml里找到该依赖，改为：

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <scope>runtime</scope>
    <version>5.1.49</version>
</dependency>

然后mvn clean package重打包。这个操作我帮三个学生解决过，他们MySQL是5.7.32，用8.0驱动死活连不上。

5.2 前台无法注册/登录，控制台报“Invalid bound statement”

这个错通常出现在修改了Mapper XML后。比如你手贱把RoomMapper.xml里<select id="selectById" ...>的id改成"getRoomById"，但RoomMapper.java接口里还是Room selectById(Long id);，MyBatis找不到对应的方法，就报这个错。排查步骤：
1. 打开target/classes/mapper/RoomMapper.xml（编译后的XML），确认<select>标签的id属性和接口方法名完全一致（大小写敏感）。
2. 确认RoomMapper.java接口上有@Mapper注解，或MinSuguanLiWApplication.java上有@MapperScan("com.example.mapper")。
3. 如果用了@MapperScan，确认包路径com.example.mapper和实际src/main/java/com/example/mapper/一致。
4. 最狠一招：删掉target目录，重新mvn clean package，因为旧的class文件可能缓存了错误映射。

5.3 图片上传失败，控制台报“java.io.FileNotFoundException”

根源几乎全是file.upload-dir配置问题。按此清单核对：
- application.yml里file.upload-dir: D:/minsuguanliw/upload/，路径末尾有斜杠；
- Windows资源管理器里，D:\minsuguanliw\upload\这个目录必须真实存在（右键新建文件夹）；
- 目录权限：右键该文件夹→属性→安全→编辑→添加Users组→勾选“完全控制”；
- 如果用IDEA启动，确认Working directory设置为项目根目录，否则相对路径会错乱；
- 终极验证：在FileUploadUtil.java的uploadImages()方法里，加一行System.out.println("Upload path: " + uploadDir.getAbsolutePath());，看打印的路径是不是你预期的。

5.4 订单状态不更新，“已支付”后房源库存没减少

这是事务失效的经典表现。检查OrderService.java里paySuccess()方法：

@Transactional
public void paySuccess(Long orderId) {
    // 1. 更新订单状态
    Order order = orderMapper.selectById(orderId);
    order.setStatus(2);
    orderMapper.updateById(order);

    // 2. 扣减房源库存
    Room room = roomMapper.selectById(order.getRoomId());
    room.setAvailableCount(room.getAvailableCount() - 1);
    roomMapper.updateById(room);
}

如果@Transactional注解没生效，第二步失败时第一步不会回滚，导致“钱收了但房没锁”。原因通常是：
- 方法不是public（@Transactional对private/protected无效）；
- 方法在同一个类里被其他方法调用（如A.method1()调用A.paySuccess()），Spring AOP代理失效；
- pom.xml里漏了spring-boot-starter-jdbc依赖（事务管理需要）。
解决方案：把paySuccess()提到独立的OrderTransactionService.java里，确保它是public且被Spring容器管理。

6. 毕设扩展与业务深化：从可运行到可商用的进阶路径

这套系统作为毕设基线足够扎实，但若你想让它真正支撑一家民宿运营，还有几个低成本高回报的扩展点。第一个是多房东隔离：现在所有房源都在一张ms_room表，A房东上架的房，B房东也能编辑。扩展只需三步：1）在ms_room表加owner_id字段（关联sys_user.id）；2）RoomService.addRoom()时自动设room.setOwnerId(currentUserId)；3）RoomController.listRooms()的SQL加AND owner_id = #{currentUserId}。这样每个房东只能看到自己的房，后台管理员用role_id=2绕过限制。第二个是微信支付接入：替换PayService.java里的模拟支付，调用微信官方SDK。关键在UnifiedOrderRequest对象里，out_trade_no用订单号，total_fee是order.getPrice()*100（单位分），notify_url设为https://yourdomain.com/api/pay/notify，这个回调地址必须能被微信服务器访问（需备案域名+HTTPS）。第三个是数据看板：新增ReportController.java，提供/report/revenue接口，SQL聚合ms_order表按月统计SUM(price)，返回JSON给ECharts绘图。这些扩展都不需要重构框架，只是在现有模块上叠加，符合毕设“工作量饱满但风险可控”的要求。我自己指导的学生里，有个把“民宿+共享洗衣机”结合，扩展了ms_machine表和预约模块，答辩时演示了客人扫码租洗衣机、自动扣费、超时提醒全流程，拿了优秀毕设。所以别纠结“技术够不够炫”，想清楚“民宿老板明天最想解决什么问题”，然后用这套代码把它做出来——这才是这套源码包给你最硬核的价值：它不是终点，而是你动手改变现实的起点。

本文还有配套的精品资源，点击获取

简介：这个资源包提供一套可直接运行的民宿业务管理系统，用Java语言开发，后端基于SpringBoot框架，前端独立部署，支持前后端分离。游客能浏览房源、查看房间详情、参与论坛讨论、查阅最新公告，并在个人中心管理订单、收藏房源和维护资料。系统采用双角色权限设计：普通用户可发布和编辑房源、审核论坛内容、更新公告；管理员还能统一管理账号、配置地区分类、设置设施标签等基础数据。配套文件齐全：MySQL数据库初始化脚本（db.sql）可一键导入；毕业论文文档（论文.doc）涵盖需求分析、系统设计与实现过程；说明文档.txt详细列出环境配置、启动步骤、模块功能与注意事项；源码压缩包No336minsuguanliw.zip包含完整工程结构，含pom.xml依赖配置和标准src目录。整个系统已完成核心流程测试，覆盖房源上架、订单生成、用户互动等关键场景，适合本科毕业设计选题参考，也适用于小型民宿团队快速搭建数字化运营工具。

本文还有配套的精品资源，点击获取