前后端分离的Spring Boot民宿租赁系统最近在Java学习圈子里热度一直不低。原因很简单这套东西技术上不堆砌业务上又能把SpringBoot、Vue、MyBatis和MySQL这几个最常用的技能点全部串起来做完一遍基本等于提前操练了一遍真实企业项目的工作流。这篇文章我会把整个系统从业务设计、数据库建模、后端接口、前端页面到部署上线的完整过程拆开讲透重点讲讲那些文档里不会写、但实际操作中一定会碰到的细节和坑。适合正在学SpringBoot和Vue的开发者也适合课程设计、毕业设计想快速落地一套可演示系统的同学参考。1. 项目整体拆解民宿租赁系统到底要做什么1.1 业务场景与用户角色民宿租赁系统本质上是一个轻量级的“房态管理在线预订”平台。你可以把它理解成缩小版的酒店预订网站但业务流程更加贴合短租场景。系统里的核心角色有三个游客、注册用户和管理员。游客可以浏览民宿列表、按城市和关键词筛选房源注册用户能提交订单、查看订单状态管理员则负责房源上下架、订单审核、用户管理。动手写代码之前先把业务流程盘清楚比啥都重要。民宿预订和普通电商最大的区别在于“库存”是强约束的一个房间在某个日期被预订了这一天就不能再卖出去。这种按日期维度锁库存的模型是整个系统最核心也最容易做错的地方。很多初学者第一次写这类系统直接用订单表去判断房间是否可订结果日期区间一交叉就出问题根源就是没把“库存”这个抽象概念独立出来。1.2 功能模块与需求清单根据上面的业务场景功能模块可以拆成前台和后台两块。这边列一下最常见的需求清单前台用户端用户注册、登录、民宿列表浏览与条件筛选、民宿详情查看图片、设施、价格、按入住日期和离店日期查询可订状态、提交预订订单、个人中心订单管理。后台管理端管理员登录、房源信息管理新增、编辑、上下架、房型与房价管理、订单列表与状态流转处理、用户管理、基础数据统计。这里有一个设计上的取舍要说清楚演示类项目尽量不要去对接真实支付。我做这个系统的时候订单支付用的是“模拟支付”方案也就是用户点击确认支付按钮后端直接把订单状态从待支付改成已确认。这样业务闭环完整又不会让部署和演示卡在第三方支付资质审核上。如果你后续想接触真实支付保留好支付状态字段再接入对应的开放平台SDK就可以了。2. 技术选型解析这套组合为什么经典2.1 前后端分离架构的实际好处前后端分离简单来说就是前端用独立的Vue工程负责页面展示和交互后端用独立的SpringBoot工程只负责提供JSON接口两边通过HTTP协议通信。这样做的直接好处是职责边界清晰前端不用关心Java代码后端不用纠结页面样式只要接口契约定好两边可以并行开发、互不等待。我带过一些同学做这个项目发现很多人有个认知偏差觉得前后端分离就是把前端代码跟后端代码放在两个目录里。其实关键在于“契约”也就是接口定义的规范程度。民宿列表接口返回什么字段、分页参数叫什么名字、状态码怎么约定这些必须在开发前定清楚。不然等项目做到一半前端发现后端返回的字段对不上后端觉得前端传参不规范返工的酸爽经历我猜不少人都体验过。2.2 技术栈选型理由为什么是这四个“SpringBootVueMyBatisMySQL”确实是目前Java Web最主流的新手组合之一我用了很久之后依然觉得它是综合性价比最高的配置。SpringBoot负责解决后端工程的骨架问题内置Tomcat并且自动配置掉大量繁琐的XML配置开发者可以把精力集中在业务代码上。Vue作为前端框架学习曲线相对平缓数据驱动视图的特性让页面状态管理非常直观。MyBatis则是一个半自动的持久层框架SQL由开发者自己把控对于民宿预订这种需要大量动态SQL的业务场景非常合适。MySQL作为开源关系型数据库稳定且免费配合Navicat这类图形化工具设计表结构、调试SQL效率都很高。另外我建议关注一下这套组合的就业匹配度。随手翻一翻招聘网站就会发现SpringBoot和Vue几乎成了Java后端和前端岗位的标配要求。把这个项目完整做一遍相当于把工作中最高频使用的技术栈提前演练了一遍。2.3 工程目录结构与协作分工一个标准的前后端分离民宿租赁系统工程上至少要拆成两个独立目录homestay-backendSpringBoot工程Maven管理按controller、service、mapper、entity、config分层。homestay-frontendVue工程按views、components、router、store、api组织。开发时的协作流程一般是后端先设计数据库和接口输出接口文档前端拿到接口文档后用Mock数据先把页面搭出来后端接口就绪后前端把Mock地址切换成真实接口地址。我习惯在Axios里配置baseURL做环境区分开发环境走http://localhost:8080/api生产环境走Nginx代理后的/api。这个细节看起来不起眼但能避免大量“本地好好的线上全挂了”的部署问题。3. 数据库设计与MyBatis持久层实现3.1 核心数据表结构设计数据库设计是整个项目的地基表结构如果没规划好后面写代码会处处受制。我做民宿租赁系统一般从五张核心表起步user用户表id、username、password、phone、role。homestay民宿/房源表id、title、cover、city、address、price、status。room房间/房型表id、homestay_id、room_name、price、capacity、status。booking订单表id、user_id、room_id、start_date、end_date、total_price、status。room_occupied房态占用表id、room_id、date、status。重点讲一下订单表和房态占用表的设计思路。民宿业务有个特点两个订单如果入住日期重叠那么后一个订单一定不能成功。为了快速判断房间在某段时间内是否可用单独建一张room_occupied表每晚写入一条占用记录是最直观的方案。这样查可用房间时用NOT EXISTS或LEFT JOIN判断目标日期区间内是否存在占用记录即可SQL写起来很清晰远比在订单表上做复杂的日期区间相交判断要容易维护。订单状态我建议用整型字段统一表示0待支付、1已确认、2已入住、3已取消、4已完成。用整型而非字符串一是节省存储空间二是方便状态流转时做数值判断前端需要显示状态文案时再通过字典映射处理即可。3.2 MyBatis动态SQL的实战写法与避坑MyBatis最强大的能力之一就是动态SQL。以民宿列表条件搜索为例用户可能只传城市也可能同时传入价格区间和日期这种“查询条件可选”的场景用where配合if标签能优雅解决select idsearchAvailableHomestays resultTypecom.example.entity.HomestayVO SELECT h.*, (SELECT COUNT(*) FROM room r WHERE r.homestay_id h.id) AS room_count FROM homestay h where if testcity ! null and city ! AND h.city #{city} /if if testmaxPrice ! null AND h.price lt; #{maxPrice} /if if testkeyword ! null and keyword ! AND (h.title LIKE CONCAT(%, #{keyword}, %) OR h.address LIKE CONCAT(%, #{keyword}, %)) /if /where ORDER BY h.id DESC LIMIT #{offset}, #{pageSize} /select这里有几个细节要提醒一下。第一#{...}是预编译参数能够有效防止SQL注入日常开发中能用#{}就别用${}。第二XML文件里的比较运算符需要转义比如小于号要写成lt;很多新手第一次跑SQL报错就是死在这个符号上。第三上例使用的是LIMIT分页数据量不大完全够用等业务量上来再引入PageHelper也不迟。另外MyBatis的驼峰映射一定要记得打开在application.yml里配置一行即可mybatis: configuration: map-underscore-to-camel-case: true开启之后数据库里的create_time字段就能自动映射到实体类的createTime属性。我遇到过不少同学没配这个结果查出来的实体有一半字段是null定位半天才发现是映射问题完全是在浪费时间。4. 后端核心功能实现与接口设计4.1 SpringBoot工程搭建与统一响应封装后端工程推荐直接用Spring Initializr创建选择SpringBoot 2.7.x配合Java 8或Java 11都很稳。这里要特别提醒版本问题网上大量教程基于2.3、2.5如果你图新鲜直接上SpringBoot 3.x很可能发现一堆依赖的API都变了教程里的写法全失效。新手做这个项目老老实实选2.7.x即可等有经验了再折腾升级也不迟。Controller层的返回格式从第一个接口开始就要统一。我习惯定义一个通用的结果类Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }所有接口都返回这个统一结构前端在Axios响应拦截器里只需要判断一次code即可。这个习惯越早养成越好等接口数量多了你才会明白统一的响应契约能省下多少联调时间。4.2 核心业务接口与预订逻辑实现系统里最核心的接口有两个民宿搜索接口和提交预订接口。搜索接口的SQL写法在第3章已经给过示例这里说一下Service层的处理流程前端传入city、startDate、endDate等条件Service层先按条件查出符合条件的民宿再对每家民宿下的房间做可订性判断。判断某个房间在日期段内是否被占用的SQL如下select idcountOccupied resultTypejava.lang.Integer SELECT COUNT(*) FROM room_occupied WHERE room_id #{roomId} AND date BETWEEN #{startDate} AND #{endDate} /select返回值大于0说明该房间在这些日期段内有占用记录前端就应该把房间置灰或提示不可订。这一段是预订业务的核心判断也是最容易出bug的地方。另外我还会在“生成订单”这一步再加一次可订性校验相当于二次确认避免两人同时下单造成超卖。如果追求更强的数据一致性可以借助SELECT ... FOR UPDATE锁行或者依靠数据库唯一索引做兜底。提交预订的完整流程可以拆成五步前端传入房间ID、入住日期、离店日期、入住人数。后端参数校验并计算总价总价等于房间单价乘以入住天数。再次查询该房间在日期段内是否可订不可订直接抛业务异常。插入订单数据状态设为待支付。模拟支付成功后批量写入room_occupied占用记录。第5步一定要在支付成功之后才做否则用户下了单但没付款房态却被占用其他客人就无法预订了。我排查过不少“订单状态和房态数据对不上”的案例根因基本都是这一步的执行顺序放错了。5. 前端Vue实战页面搭建与接口联调5.1 Vue工程初始化与路由设计前端工程我推荐用Vue CLI 4或5配合Vue 2起步教程丰富、上手简单遇到问题搜起来也方便。如果你已经熟悉Vue 3的Composition API也可以直接使用Vite创建项目并引入Element Plus。不管用哪个版本组件库一定要引入民宿这类管理系统最耗时间的其实是表单和表格样式用组件库可以节省至少一半工作量。路由设计建议采用懒加载方式const routes [ { path: /, component: () import(/views/Home.vue) }, { path: /homestays, component: () import(/views/HomestayList.vue) }, { path: /homestay/:id, component: () import(/views/HomestayDetail.vue) }, { path: /login, component: () import(/views/Login.vue) }, { path: /register, component: () import(/views/Register.vue) }, { path: /admin, component: () import(/views/admin/AdminLayout.vue), meta: { requiresAuth: true, role: admin }, children: [ { path: homestays, component: () import(/views/admin/HomestayManage.vue) }, { path: orders, component: () import(/views/admin/OrderManage.vue) }, { path: users, component: () import(/views/admin/UserManage.vue) } ] } ]路由守卫里要做两件事一是未登录用户访问需要登录的页面时直接重定向到登录页二是管理后台只有role为admin的用户才能进入。很多教程只写了前端的路由控制这里我必须强调一句前端路由守卫只是一种用户体验优化真正的权限校验必须由后端接口再做一次验证。前端隐藏菜单只是为了界面整洁绝对不能当作安全边界来依赖。5.2 Axios封装与核心页面实现如果每个页面都直接用axios.get写请求维护起来会非常痛苦。我一般在src/api目录下封装一个统一的request实例import axios from axios const request axios.create({ baseURL: process.env.VUE_APP_BASE_URL, 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( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res }, error { ElMessage.error(网络异常请稍后重试) return Promise.reject(error) } ) export default request有了这个公共封装具体接口模块写起来就很干净export function getHomestayList(params) { return request({ url: /api/homestays, method: get, params }) } export function createBooking(data) { return request({ url: /api/bookings, method: post, data }) }页面层面民宿列表页是最能体现Vue数据驱动特性的地方。用el-table渲染数据、el-pagination处理分页、el-date-picker做日期范围选择再配合搜索条件表单一个可用列表页很快就能完成。这里有一个实操建议搜索表单的查询条件统一绑定到一个queryParams对象每次点击搜索时把整个对象提交给后端不要分散成多个零散变量维护。条件一多你就知道这个习惯有多省心。6. 从零到一完整部署教程6.1 本地开发环境准备部署前先把环境确认一遍这一步被很多人忽略结果应用启动时报错满天飞。我列一个常见的环境版本清单JDK1.8或11后端运行必需。Maven3.6以上用于构建SpringBoot工程。Node.js14以上用于前端安装依赖和打包。MySQL5.7或8.0均可创建数据库后导入init.sql脚本。Navicat或MySQL Workbench连接数据库查看表结构和调试数据。MySQL安装这里多说一句。Windows下安装MySQL 8.0时有一个选择认证方式的步骤建议选“Use Legacy Authentication”老式密码认证否则后续用老版本客户端连接时很容易出现SSL连接错误。如果已经安装完了才碰到SSL相关报错可以在数据库连接URL后面加上?useSSLfalseserverTimezoneAsia/Shanghai临时规避这是最省事的处理方式。6.2 打包构建与两种部署方式前端打包cd homestay-frontend npm install npm run build打包成功后会在dist目录生成静态文件接下来要决定前端静态文件放哪里。我提供两种常用方案第一种是标准的前后端分离部署。把dist目录交给Nginx托管在Nginx配置里做一层反向代理将/api前缀的请求转发到SpringBoot服务地址上。这种方案前后端完全独立扩展性和维护性最好适合正式一点的环境。第二种是前后端合并部署适合课程答辩、个人演示这类场景。操作方法是把dist目录里的index.html和static目录直接复制到SpringBoot工程的src/main/resources/static目录下然后重新打包后端这样启动一个SpringBoot服务浏览器访问http://localhost:8080就能看到整个系统。这个方式省掉了Nginx对新手非常友好。后端打包命令cd homestay-backend mvn clean package -DskipTests java -jar target/homestay-0.0.1-SNAPSHOT.jar启动成功后先用浏览器直接访问后端接口地址确认返回正常的JSON数据再根据你选择的部署方案把前端访问路径调通。按这个顺序排查问题会容易得多。7. 常见问题与避坑实录7.1 高频问题排查表这个项目我反复帮人跑通过很多次把最常见的问题整理成一张速查表问题现象可能原因解决办法后端启动时提示端口被占用8080端口被其他程序占用使用netstat -ano | findstr :8080找到进程并结束或在配置中修改端口前端请求接口全部404接口路径或baseURL配置错误先用浏览器直接访问接口地址确认后端正常再检查Axios的路径配置查询返回的实体字段全是nullMyBatis驼峰映射未开启在配置中设置map-underscore-to-camel-case: true列表查询出现N1次SQL关联数据在循环中逐条查询使用SQL联表查询一次查出或使用MyBatis嵌套结果映射连接MySQL报SSL错误认证方式或SSL配置不匹配在JDBC连接串追加?useSSLfalseserverTimezoneAsia/ShanghaiVue打包后非首页刷新404history模式路由缺少服务端重定向改用hash模式或Nginx配置try_files $uri $uri/ /index.html使用最新版SpringBoot导致教程写法失效版本大版本API变更统一使用2.7.x版本熟悉后再考虑升级7.2 我的实操心得最后分享几点我自己做项目、带项目总结出来的经验。第一做这种完整系统千万不要上来就敲代码。先花半天时间把数据库表结构和接口清单设计清楚后面所有编码都是在为这个设计填肉。表结构设计得好写代码就像做填空题表结构设计得烂后期重构会让你怀疑人生。第二MyBatis的SQL日志在开发阶段一定要打开。在application.yml里加一行logging.level.com.example.mapper: debugSQL语句和参数值都会打印出来排查问题时效率翻倍。否则你对着一个空数据半天不知道是没查出来还是查出来映射失败了。第三前后端联调时接口文档千万不要停留在口头约定。哪怕是建一个在线表格把每个接口的路径、入参、出参、状态码含义记下来都能省下大量沟通成本。我自己踩过最深的坑就是前后端对“已取消订单”的状态值理解不一致前端传的是3后端判断的是4这种低级错误硬是排查了一个下午。第四项目做完之后建议把部署流程从头到尾独立走两遍。第一遍看着文档走第二遍关掉文档直接走能顺利走通才算真正吃透了这套技术栈。很多人写完代码以为万事大吉结果一到演示现场环境变了连前端页面都刷不出来那种尴尬最好在项目交付前就提前规避。