去年年底帮一位做民宿创业的朋友做了一套在线预订管理系统前后从需求梳理到部署上线花了大约两周时间。技术栈选的是SpringBoot加Vue这套非常经典的前后端分离组合后端走Java生态前端用Vue全家桶这基本是当前Web全栈开发最主流的一条技术路径不管是用来做毕业设计、面试项目还是想系统学一遍前后端配合开发都有很高的参考价值。这篇博客我把整个项目从设计到实现完整复盘一遍包括数据库表结构怎么设计、民宿搜索和订单状态怎么管理、预订流程里的并发扣库存怎么处理、Vue端路由与状态管理怎么组织以及我在开发过程中踩过的各种坑。内容会尽量落到细节能直接抄作业的地方绝不写空话。1. 项目定位与整体设计思路1.1 为什么选SpringBoot加Vue这套组合做民宿预订系统先用大白话解释一下这套架构在做什么。SpringBoot负责跑在服务端处理业务逻辑、操作数据库、提供接口Vue负责跑在浏览器端渲染页面、响应用户操作、调用后端接口。两者通过JSON格式的数据交互这就是典型的前后端分离模式。选择SpringBoot的核心原因在于它的开发效率。SpringBoot最突出的价值是自动装配机制框架根据引入的依赖自动配置好大部分组件比如MyBatis、Redis、Spring MVC这些开发者只需要专注写业务代码不用像早期Spring项目那样写大堆XML配置。很多人面试都会被问SpringBoot自动装配原理简单说就是SpringBoot的启动类上有SpringBootApplication注解这个注解里包含了EnableAutoConfiguration框架启动时会通过SpringFactoriesLoader拿META-INF目录下的工厂配置再配合Conditional条件注解按需加载对应的Bean。理解了这一点再看配置为什么这么简洁就很清楚了。Vue这边我选的是Vue 3加Vite的组合而不是Vue 2加Webpack。Vite启动速度快、热更新即时开发体验明显好一个档次。在组件通信、路由、状态管理上这套组合也有非常成熟的官方解决方案Vue Router负责页面跳转Pinia或Vuex负责全局状态Axios负责HTTP请求Element Plus提供现成的UI组件搭建后台管理页面的效率非常高。1.2 系统功能模块划分与用户场景分析开始写代码前先想清楚这个系统服务哪些人、解决什么问题。我梳理了两类核心角色前台C端用户和后台管理员。C端用户的核心场景是搜索目的地、按日期和人数筛选可预订民宿、查看民宿详情与房型、提交预订订单、在线支付或到店支付、查看个人订单、申请取消。后台管理员的核心场景是管理民宿房源信息、管理房型与库存、设置不同日期的动态价格、查看和处理订单、统计分析销售数据。由此划分出六大功能模块用户认证模块注册、登录、个人资料维护民宿展示模块民宿列表、搜索筛选、详情展示、房型列表预订交易模块创建订单、提交订单、订单状态流转订单管理模块用户查看订单、管理员处理订单房态管理模块管理员维护民宿、房型、每日库存和价格统计报表模块订单量、销售额、热门民宿排行功能边界划分清楚之后前后端的分工自然就出来了后端只做数据校验、业务逻辑和持久化前端只做界面渲染和交互控制。这个设计在后面开发过程中会省掉大量返工成本。2. 数据库设计民宿预订系统最核心的底座2.1 核心表结构设计与关系梳理一个民宿预订系统本质上解决的是谁在什么时间订了哪间房这个问题。围绕这个核心我拆解出五张核心表用户表、民宿表、房型表、房态库存表、订单表。用户表比较简单字段包括id、用户名、密码BCrypt加密存储、手机号、头像、创建时间。密码加密是必须的明文存密码的系统上一秒上线下一秒就能被脱裤别问我怎么知道的。民宿表的核心字段是民宿名称、封面图、所在城市、详细地址、经纬度、简介、设施标签、综合评分、状态。城市和经纬度这两个字段非常关键城市是搜索的一级条件经纬度可以用于前端对接地图组件做位置展示。我一开始做的时候只存了城市名后来发现用户在详情页想看民宿具体在哪个位置还得单独调地图API拿经纬度来回折腾了很久干脆在表里直接加上了。房型表挂在外宿表下代表民宿拥有的具体房间类型房型名称、面积、可住人数、床型信息、配套设施、基础价格、房间数量。注意基础价格只是默认价真正每天的售价放在房态库存表里这样可以支持周末涨价、节假日调价这类动态定价需求这是民宿系统区别于普通商品订单系统的最大特点。订单表是整套系统的核心订单编号、下单用户、房型ID、入住日期、离店日期、入住人数、订单总金额、订单状态、创建时间、支付时间、取消时间。订单编号不要用自增ID直接暴露给用户我用的是时间戳加随机数的组合生成一个唯一字符串格式类似20240115123045001这种方便查询且不容易被遍历。2.2 动态房价与库存的建模方案这里重点讲房态库存表的设计这也是整个系统里最值得提前想清楚的一张表。民宿预订行业的特殊性在于同一个房型不同日期的剩余房间数和价格可能不同。比如十一期间满房工作日可能空着周五周六价格上浮100元周三保持原价。如果只在房型表里放一个总库存和基础价格完全没法支持这种业务。我的方案是单独的room_stock表按房型加日期的维度存储每日库存与价格idroom_id房型IDstock_date日期精确到天total_stock当天总库存booked_stock当天已预订数量remain_stock当天剩余数量price当天售价这张表在民宿创建房型的时候由后端自动批量生成未来90天的记录管理员可以在后台手动修改某几天的价格和库存。生成90天还是180天可以根据业务需要调整但一定要有一个明确的生成策略否则用户搜索未来日期时查不到数据体验会很差。好处很明显查询某日期段是否可预订直接查这张表就行统计未来入住率也直接按日期聚合。有些民宿系统还会把库存设计成按区间段存储比如某一房源7月1日到7月7日全部满房就存一条区间记录。这种方式虽然节省存储但查询和修改的逻辑复杂很多对于中小规模民宿系统完全没有必要按天存储的冗余成本完全可以接受。3. 后端SpringBoot开发实录3.1 项目骨架搭建与分层设计项目我用的是SpringBoot 2.7加MyBatis Plus搭配MySQL 8.0和Redis。Redis在这个项目里主要做两个事情缓存民宿列表和热门外宿详情减少数据库压力存储用户的登录Token。代码分层上采用的是最标准的Controller-Service-Mapper三层结构Controller层只负责接收请求、参数校验、返回结果不写任何业务逻辑Service层业务逻辑的核心处理搜索、下单、取消等业务流程Mapper层数据访问配合MyBatis Plus操作数据库实体类、DTO、VO要分开实体类对应数据库字段DTO负责接收前端传入的参数VO负责返回给前端的数据结构。很多新手图省事一个实体类从头用到尾结果接口返回的JSON里塞了一堆用户不想看到或不需要的字段安全性差还大量传输无用数据。项目刚开始搭建时我习惯把统一返回结果和全局异常处理先配置好。统一返回结果的格式是{code, message, data}这样的包裹结构前端通过code判断请求是否成功再通过data取数据。全局异常处理用RestControllerAdvice注解实现这样Service层抛出业务异常后直接转换为对外的错误提示不会把堆栈信息暴露给前端。3.2 民宿搜索接口的实现细节民宿搜索是这个系统的入口功能也是用户感知最直接的接口。搜索条件包括城市、入住日期、离店日期、入住人数。前两个都比较直接核心难点在于怎么根据日期和人数组装查询条件。先说日期条件。用户选择了入住和离店日期后后端需要判断民宿在这个时间段内是否有可用房间。翻译成数据库操作就是查询room_stock表中stock_date在入住日期和离店日期之间的所有记录过滤掉remain_stock等于0的日期记录再按房型分组统计如果有房型满足每一天都有剩余库存就认为该房型可预订。这个逻辑如果用SQL一次性写完会比较绕我的实现方式分两步第一步拿到用户选择的日期列表比如入住在1月10日、离店在1月13日拆出1月10日、11日、12日三天注意是左闭右开离店当天不占用房间。第二步查询这些日期里有库存的房型ID集合再进行分组统计用SQL的COUNT(DISTINCT stock_date)判断满足的天数是否等于需要预订的天数。这里有个容易踩的坑用户选择入住1月10日、离店1月13日实际占用的是三晚不是四晚。我在前端和后端都做了同样的计算逻辑总天数 (离店日期 - 入住日期) / 86400000同时在SQL里用BETWEEN时也会特意处理边界条件确保数据一致。再说人数条件。这个问题比想象中隐蔽得多。用户搜索3人入住不能只看单个房型的可住人数是否满足还要考虑同一民宿下多个房型合并的情况。比如一个民宿同时有双床房和单人房两个房间各可以住一个人和两个人两个人或者三个人依然可以入住。所以我的做法是先查询符合日期条件的房型按民宿分组判断该民宿下所有可订房型的max_people总和是否大于等于入住人数。如果满足就返回民宿数据。3.3 预订下单与并发控制的关键代码预订下单是整个系统最核心的接口也是最容易出bug的地方。核心逻辑是用户提交入住日期、离店日期、房型ID、入住人数后端计算总价格、扣减库存、创建订单。这里的难点在于并发控制。想象这样一个场景某个民宿某天只剩下最后一间房两个用户同时点了预订如果按照先查询库存是否充足再扣减库存的顺序处理两个请求都可能查到库存充足然后同时创建订单超卖问题就出现了。这在民宿预订里是绝对不允许发生的事用户付了钱到了发现没房投诉能打到平台倒闭。解决思路是使用数据库层面的条件更新把检查库存和扣减库存合并成一个原子操作UPDATE room_stock SET booked_stock booked_stock 1, remain_stock remain_stock - 1 WHERE room_id ? AND stock_date ? AND stock_date ? AND remain_stock 0如果受影响行数等于需要预订的天数说明所有日期都扣减成功如果有任何一天受影响行数为0说明当天已经满房整体回滚返回该日期已无房源。这种写法简单可靠利用了MySQL行锁的原子性不会出现超卖。等到业务量真的大到需要引入消息队列的异步扣减时这套系统的架构也已经不适合继续扩展了需要换一套思路。另外每个下单接口都建议加分布式锁做二次防护。这里我直接用Redis的SETNX key value EX seconds命令模拟了分布式锁以订单号加房型ID作为锁的key防止极端情况下同一用户重复提交。4. 前端Vue开发实录4.1 Vue项目初始化与路由规划前端项目我用Vite创建执行npm create vitelatest选择Vue模板然后安装Vue Router、Pinia、Axios、Element Plus等依赖。这里建议创建项目时直接选Vue 3加JavaScript或TypeScript模板避免后期待构建工具配置的麻烦。路由规划上前台和后台做了拆分设计。前台页面/首页展示推荐民宿/search搜索结果页带筛选条件/hotel/:id民宿详情页展示民宿信息、房型列表、地图位置/booking/:roomId预订页选择日期和人数后生成订单/orders我的订单列表/login、/register登录注册页后台管理页我单独挂在/admin路由下用meta字段里的角色信息加上路由守卫做访问控制。.vue文件里的beforeEach全局守卫会在路由跳转前检查Token和用户角色没有权限直接重定向到登录页。这里提一下Vite的项目结构src/api目录单独放接口请求封装src/views放页面级组件src/router放路由配置src/store放Pinia状态。模块划分清楚之后每个人负责一个模块开发互不干扰这也是团队协作的基本要求。4.2 民宿列表和详情页的关键实现搜索页是用户使用频率最高的页面我用了Element Plus的el-date-picker组件做日期范围选择类型设置为daterange配上el-input-number做人数选择。提交搜索参数后通过Vue Router的query参数把搜索条件带进结果页URL这样用户刷新页面后搜索条件依然可以保持分享链接别人也能直接看到对应的搜索结果。这里用到了Vue Router的路由传参方法router.push({ path: /search, query: { city: 杭州, checkIn: 2024-01-10, checkOut: 2024-01-13 } })在结果页通过route.query读取。民宿列表的数据建议使用Computed属性做前端二次筛选。比如城市切换、价格范围拖动条、排序方式切换这些逻辑如果每次都在后端重新查一遍交互延迟体验很差。我的做法是后端先返回当前城市符合条件的民宿全量列表前端用computed配合filter和sorter方法实现即时筛选与排序响应速度可以做到毫秒级洗刷。真正需要提交给后端的分页筛选只在用户主动点击搜索时才触发。详情页要做的第一个事就是调接口拿到民宿详情数据然后在页面顶部用图片轮播展示民宿照片下面分模块展示设施标签、房型列表、位置地图、用户评价。Vue 3的computed在这里还可以用来派生价格区间、设施标签数量这类展示数据。地图模块我接的是腾讯地图JavaScript SDK拿到民宿经纬度坐标后初始化地图实例再挂一个AMap.Marker标记点基本十几行代码就能搞定。4.3 预订流程与总价计算的坑预订流程是整个前端开发里最容易出错的地方因为涉及到日期处理和时间计算。用户点击立即预订后进入预订页。预订页要展示房型信息、入住日期选择、离店日期选择、入住人数填写、订单明细。订单明细里最关键的是总价计算。我踩过的坑是后端在计算价格时使用的日期边界规则和前端不一致。举个例子用户选择1月10日入住、1月13日离店这表示住10号、11号、12号三晚。但有些情况下前端Date对象在new的时候如果直接传2024-01-13会生成一个UTC时间的凌晨部分时区下会出现日期偏移一天的情况。这种问题极其隐蔽不是必现但有用户反馈订单价格不对就很难排查。我的最终方案是统一用时间戳计算前端和后端都把日期转换成UTC零点的时间戳按(离店时间戳 - 入住时间戳) / 86400000计算总天数再把每天的价格从room_stock接口数据里拿累加起来。每天的价格可能不同所以不能简单地用基础价乘以天数。另一个坑是订单提交前的二次确认。用户填写完信息点击提交后前端先把订单数据POST到后端但期间库存可能已经发生变化。所以后端在创建订单前一定要重新校验库存并计算价格以前端计算金额为准还是以后端计算为准这一点必须明确。我的规则是前端展示的价格仅供参考后端重新计算的结果才是最终结算价格前端展示的金额会被后端的返回结果覆盖。5. 前后端联调跨域、鉴权与部署5.1 跨域问题的处理方案前后端分离开发第一个遇到的问题就是跨域。前端跑在localhost:5173后端跑在localhost:8080浏览器默认禁止跨域请求直接调用接口会报CORS错误。解决方案有几种后端配置CrossOrigin注解、前端配置Vite代理、再加一层Nginx反向代理。我在开发环境用的是Vite代理方案在vite.config.js里配置export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/hotelsVite会自动转发到后端的http://localhost:8080/api/hotels浏览器和Vite开发服务器是同源的跨域问题直接化解。生产环境部署时Nginx配置里同样把/api前缀的请求代理到Java服务进程的端口这是最靠谱的方式。不建议在代码里写死http://localhost:8080这种硬编码地址因为上线后域名和端口都会变会导致所有接口请求失败。统一用相对路径加代理是前后端分离项目的标准做法。5.2 登录鉴权与接口安全民宿预订系统有用户信息登录鉴权是必须做的。我选用的是JWT方案流程很简单用户登录成功后后端生成一个JWT Token返回给前端前端存储在localStorage里之后每次请求在Authorization请求头带上这个Token后端通过拦截器验证Token有效性和有效期。SpringBoot里实现拦截器先实现HandlerInterceptor接口重写preHandle方法然后注册到WebMvcConfigurer里去。白名单路径包括登录、注册、民宿搜索等公开接口需要登录的接口包括创建订单、查看订单、个人中心等。如果Token缺失或过期拦截器直接返回401状态码前端Axios拦截到401后跳转登录页。这个环节有一个细节很值得重视用户的密码一定要加密存储。我用的是Spring Security自带的BCryptPasswordEncoder注册时加密、登录时校验。就算数据库被拖出来短时间内也无法逆推出明文密码这是最基本的行业底线。5.3 打包部署的实战经验前端打包执行npm run build产物在dist目录里面就是一堆静态文件。我部署的时候把静态文件放到Nginx的html目录下Nginx配置里把/api开头的请求反向代理到Java服务。后端打成Jar包后直接用java -jar启动也可以用Docker封装成一个镜像部署到云服务器或者Kubernetes集群。这里分享一个我早期踩过的坑前后端分离部署时前端路由用的History模式访问/hotel/1这样的路径时Nginx直接返回404因为Nginx在html目录下找不到这个文件。解决办法是在Nginx配置里加上location / { try_files $uri $uri/ /index.html; }这样访问任何路径时Nginx都会把请求回退到index.html再由前端路由接管渲染对应页面。这个配置是Vue项目部署几乎必配的一项不配的话刷新页面就404体验极差。6. 开发中踩过的坑与排查技巧6.1 五个典型的坑整理了这次开发过程中比较典型的五个问题每一个都是真实遇到并排查了半天的写出来给大家避避坑。第一个坑是MySQL时区问题。连接数据库的URL里如果没有加serverTimezoneAsia/Shanghai默认用的是服务器时区一般和本地差8小时导致日期数据错乱。排查思路是看数据库连接串必须显式指定时区不能依赖默认值。第二个坑是MyBatis Plus的字段映射。实体类里用了checkInDate这种驼峰命名字段数据库字段是check_in_date如果MyBatis Plus没有开启驼峰映射查询出来的字段全部为null。MyBatis Plus默认配置下问题不大但如果是自己搭的MyBatis框架要检查mapUnderscoreToCamelCase配置是否开启。第三个坑是前端路由的懒加载。一开始项目小所有路由都同步加载没发现问题。到后期页面多了打包出来的JS文件三四兆首屏加载特别慢。后来把路由全部改成懒加载用动态import()方式引入组件首屏体积减小了一大半。这个优化建议项目一开始就做。第四个坑是Element Plus的日期选择器默认值。组件el-date-picker在没选日期时的value是null如果直接把这个null传给后端接口做日期计算后端会报空指针。我统一在前端参数校验里加了判断同时后端接口也做非空校验双保险。第五个坑是民宿列表的图片加载。民宿图片用的是图床URL有时候加载慢或者防盗链页面大片空白。后来加了loadinglazy属性做懒加载配合一个默认占位图用户体验好了很多。图片这块如果数据量再大还可以考虑接对象存储服务CDN加速但小型系统完全没必要。6.2 排查工具与调试心得开发中排查问题的效率很大程度上取决于工具链是否顺手。我在这个项目里用到的调试手段主要有三类。第一类后端调试。SpringBoot项目启动时开启调试模式配合IDE的断点调试可以逐步跟踪每次请求的处理流程。对于接口返回的数据结构和字段问题这个方法非常有效。我还习惯在Service层写日志用Slf4j注解注入Logger在关键业务流程处打日志比如下单时打印参数和扣库存结果出问题一查日志就能定位不需要每次都在数据库里翻记录。第二类前端调试。Vue项目的调试核心是浏览器开发者工具和Vue Devtools插件。Vue Devtools可以看到组件树、Props、Computed、Pinia状态排查页面数据不更新的问题特别有用。我在页面里添加了console.log输出关键变量包括接口返回的数据、搜索参数等出现问题先在浏览器控制台看请求和响应再决定排查方向。第三类接口调试。前后端分离项目接口调试我直接用Postman可以保存请求历史、管理环境变量、快速测试各种边界场景。尤其是下单接口这种有状态、有并发风险的接口我习惯用Postman的Runner功能一次跑多个并发请求验证库存扣减的原子性或超卖问题。等后面项目再大一些可以接一套接口自动化测试平台但当前阶段Postman已经足够。还有一个排查心得很重要遇到bug先看请求和响应再查代码最后才查数据库。很多人一上来就在数据库里翻数据但前端报错往往只反映了表象真正的原因要么在接口层要么在参数传递所以先把请求链路走一遍基本能解决七成以上的问题。7. 这个系统还能怎么扩展项目做完以后其实还有不少可以扩展的方向这个取决于实际业务量和个人学习目标。如果是想往分布式方向深入学习可以把Redis的缓存策略做得更细比如民宿详情缓存加过期时间、热点民宿做缓存预热给库存扣减接上消息队列做异步削峰把订单服务改造成独立的微服务模块。这些方向可以逐一拆开做性能优化和架构演进练习。如果是面向真实业务场景可以考虑接入主流地图服务的路线规划API让用户搜索某地铁站附近的民宿接入第三方登录比如微信扫码登录做一套运营后台的优惠券和会员积分体系提升用户留存率。管理员端还可以增加数据可视化大屏把热门民宿、满房率、实时销售额做成大屏图表运营人员每天打开就能看到经营状况。我个人在实际操作中最大的体会是这类全栈项目真正的难点不在单个技术栈而在于把前后端的数据流和业务规则对齐。日期计算规则、状态流转规则、价格计算规则这些业务逻辑里只要有一个前后端理解不一致功能就一定会出bug。所以开发前先把需求点逐条列出来明确这个数据由谁产生、由谁消费、什么规则变更后面写代码的时候会顺畅很多。最后再分享一个习惯每完成一个模块不只是功能跑通我还会顺手把关键业务场景的测试用例写好。不是那种代码级的单元测试而是把核心场景的操作步骤和预期结果写下来作为验收依据。这个习惯帮助我在后续页面增加功能时能快速判断哪些原有逻辑受到了影响个人非常推荐。
SpringBoot+Vue民宿预订系统全栈开发实战：从数据库设计到并发控制
去年年底帮一位做民宿创业的朋友做了一套在线预订管理系统前后从需求梳理到部署上线花了大约两周时间。技术栈选的是SpringBoot加Vue这套非常经典的前后端分离组合后端走Java生态前端用Vue全家桶这基本是当前Web全栈开发最主流的一条技术路径不管是用来做毕业设计、面试项目还是想系统学一遍前后端配合开发都有很高的参考价值。这篇博客我把整个项目从设计到实现完整复盘一遍包括数据库表结构怎么设计、民宿搜索和订单状态怎么管理、预订流程里的并发扣库存怎么处理、Vue端路由与状态管理怎么组织以及我在开发过程中踩过的各种坑。内容会尽量落到细节能直接抄作业的地方绝不写空话。1. 项目定位与整体设计思路1.1 为什么选SpringBoot加Vue这套组合做民宿预订系统先用大白话解释一下这套架构在做什么。SpringBoot负责跑在服务端处理业务逻辑、操作数据库、提供接口Vue负责跑在浏览器端渲染页面、响应用户操作、调用后端接口。两者通过JSON格式的数据交互这就是典型的前后端分离模式。选择SpringBoot的核心原因在于它的开发效率。SpringBoot最突出的价值是自动装配机制框架根据引入的依赖自动配置好大部分组件比如MyBatis、Redis、Spring MVC这些开发者只需要专注写业务代码不用像早期Spring项目那样写大堆XML配置。很多人面试都会被问SpringBoot自动装配原理简单说就是SpringBoot的启动类上有SpringBootApplication注解这个注解里包含了EnableAutoConfiguration框架启动时会通过SpringFactoriesLoader拿META-INF目录下的工厂配置再配合Conditional条件注解按需加载对应的Bean。理解了这一点再看配置为什么这么简洁就很清楚了。Vue这边我选的是Vue 3加Vite的组合而不是Vue 2加Webpack。Vite启动速度快、热更新即时开发体验明显好一个档次。在组件通信、路由、状态管理上这套组合也有非常成熟的官方解决方案Vue Router负责页面跳转Pinia或Vuex负责全局状态Axios负责HTTP请求Element Plus提供现成的UI组件搭建后台管理页面的效率非常高。1.2 系统功能模块划分与用户场景分析开始写代码前先想清楚这个系统服务哪些人、解决什么问题。我梳理了两类核心角色前台C端用户和后台管理员。C端用户的核心场景是搜索目的地、按日期和人数筛选可预订民宿、查看民宿详情与房型、提交预订订单、在线支付或到店支付、查看个人订单、申请取消。后台管理员的核心场景是管理民宿房源信息、管理房型与库存、设置不同日期的动态价格、查看和处理订单、统计分析销售数据。由此划分出六大功能模块用户认证模块注册、登录、个人资料维护民宿展示模块民宿列表、搜索筛选、详情展示、房型列表预订交易模块创建订单、提交订单、订单状态流转订单管理模块用户查看订单、管理员处理订单房态管理模块管理员维护民宿、房型、每日库存和价格统计报表模块订单量、销售额、热门民宿排行功能边界划分清楚之后前后端的分工自然就出来了后端只做数据校验、业务逻辑和持久化前端只做界面渲染和交互控制。这个设计在后面开发过程中会省掉大量返工成本。2. 数据库设计民宿预订系统最核心的底座2.1 核心表结构设计与关系梳理一个民宿预订系统本质上解决的是谁在什么时间订了哪间房这个问题。围绕这个核心我拆解出五张核心表用户表、民宿表、房型表、房态库存表、订单表。用户表比较简单字段包括id、用户名、密码BCrypt加密存储、手机号、头像、创建时间。密码加密是必须的明文存密码的系统上一秒上线下一秒就能被脱裤别问我怎么知道的。民宿表的核心字段是民宿名称、封面图、所在城市、详细地址、经纬度、简介、设施标签、综合评分、状态。城市和经纬度这两个字段非常关键城市是搜索的一级条件经纬度可以用于前端对接地图组件做位置展示。我一开始做的时候只存了城市名后来发现用户在详情页想看民宿具体在哪个位置还得单独调地图API拿经纬度来回折腾了很久干脆在表里直接加上了。房型表挂在外宿表下代表民宿拥有的具体房间类型房型名称、面积、可住人数、床型信息、配套设施、基础价格、房间数量。注意基础价格只是默认价真正每天的售价放在房态库存表里这样可以支持周末涨价、节假日调价这类动态定价需求这是民宿系统区别于普通商品订单系统的最大特点。订单表是整套系统的核心订单编号、下单用户、房型ID、入住日期、离店日期、入住人数、订单总金额、订单状态、创建时间、支付时间、取消时间。订单编号不要用自增ID直接暴露给用户我用的是时间戳加随机数的组合生成一个唯一字符串格式类似20240115123045001这种方便查询且不容易被遍历。2.2 动态房价与库存的建模方案这里重点讲房态库存表的设计这也是整个系统里最值得提前想清楚的一张表。民宿预订行业的特殊性在于同一个房型不同日期的剩余房间数和价格可能不同。比如十一期间满房工作日可能空着周五周六价格上浮100元周三保持原价。如果只在房型表里放一个总库存和基础价格完全没法支持这种业务。我的方案是单独的room_stock表按房型加日期的维度存储每日库存与价格idroom_id房型IDstock_date日期精确到天total_stock当天总库存booked_stock当天已预订数量remain_stock当天剩余数量price当天售价这张表在民宿创建房型的时候由后端自动批量生成未来90天的记录管理员可以在后台手动修改某几天的价格和库存。生成90天还是180天可以根据业务需要调整但一定要有一个明确的生成策略否则用户搜索未来日期时查不到数据体验会很差。好处很明显查询某日期段是否可预订直接查这张表就行统计未来入住率也直接按日期聚合。有些民宿系统还会把库存设计成按区间段存储比如某一房源7月1日到7月7日全部满房就存一条区间记录。这种方式虽然节省存储但查询和修改的逻辑复杂很多对于中小规模民宿系统完全没有必要按天存储的冗余成本完全可以接受。3. 后端SpringBoot开发实录3.1 项目骨架搭建与分层设计项目我用的是SpringBoot 2.7加MyBatis Plus搭配MySQL 8.0和Redis。Redis在这个项目里主要做两个事情缓存民宿列表和热门外宿详情减少数据库压力存储用户的登录Token。代码分层上采用的是最标准的Controller-Service-Mapper三层结构Controller层只负责接收请求、参数校验、返回结果不写任何业务逻辑Service层业务逻辑的核心处理搜索、下单、取消等业务流程Mapper层数据访问配合MyBatis Plus操作数据库实体类、DTO、VO要分开实体类对应数据库字段DTO负责接收前端传入的参数VO负责返回给前端的数据结构。很多新手图省事一个实体类从头用到尾结果接口返回的JSON里塞了一堆用户不想看到或不需要的字段安全性差还大量传输无用数据。项目刚开始搭建时我习惯把统一返回结果和全局异常处理先配置好。统一返回结果的格式是{code, message, data}这样的包裹结构前端通过code判断请求是否成功再通过data取数据。全局异常处理用RestControllerAdvice注解实现这样Service层抛出业务异常后直接转换为对外的错误提示不会把堆栈信息暴露给前端。3.2 民宿搜索接口的实现细节民宿搜索是这个系统的入口功能也是用户感知最直接的接口。搜索条件包括城市、入住日期、离店日期、入住人数。前两个都比较直接核心难点在于怎么根据日期和人数组装查询条件。先说日期条件。用户选择了入住和离店日期后后端需要判断民宿在这个时间段内是否有可用房间。翻译成数据库操作就是查询room_stock表中stock_date在入住日期和离店日期之间的所有记录过滤掉remain_stock等于0的日期记录再按房型分组统计如果有房型满足每一天都有剩余库存就认为该房型可预订。这个逻辑如果用SQL一次性写完会比较绕我的实现方式分两步第一步拿到用户选择的日期列表比如入住在1月10日、离店在1月13日拆出1月10日、11日、12日三天注意是左闭右开离店当天不占用房间。第二步查询这些日期里有库存的房型ID集合再进行分组统计用SQL的COUNT(DISTINCT stock_date)判断满足的天数是否等于需要预订的天数。这里有个容易踩的坑用户选择入住1月10日、离店1月13日实际占用的是三晚不是四晚。我在前端和后端都做了同样的计算逻辑总天数 (离店日期 - 入住日期) / 86400000同时在SQL里用BETWEEN时也会特意处理边界条件确保数据一致。再说人数条件。这个问题比想象中隐蔽得多。用户搜索3人入住不能只看单个房型的可住人数是否满足还要考虑同一民宿下多个房型合并的情况。比如一个民宿同时有双床房和单人房两个房间各可以住一个人和两个人两个人或者三个人依然可以入住。所以我的做法是先查询符合日期条件的房型按民宿分组判断该民宿下所有可订房型的max_people总和是否大于等于入住人数。如果满足就返回民宿数据。3.3 预订下单与并发控制的关键代码预订下单是整个系统最核心的接口也是最容易出bug的地方。核心逻辑是用户提交入住日期、离店日期、房型ID、入住人数后端计算总价格、扣减库存、创建订单。这里的难点在于并发控制。想象这样一个场景某个民宿某天只剩下最后一间房两个用户同时点了预订如果按照先查询库存是否充足再扣减库存的顺序处理两个请求都可能查到库存充足然后同时创建订单超卖问题就出现了。这在民宿预订里是绝对不允许发生的事用户付了钱到了发现没房投诉能打到平台倒闭。解决思路是使用数据库层面的条件更新把检查库存和扣减库存合并成一个原子操作UPDATE room_stock SET booked_stock booked_stock 1, remain_stock remain_stock - 1 WHERE room_id ? AND stock_date ? AND stock_date ? AND remain_stock 0如果受影响行数等于需要预订的天数说明所有日期都扣减成功如果有任何一天受影响行数为0说明当天已经满房整体回滚返回该日期已无房源。这种写法简单可靠利用了MySQL行锁的原子性不会出现超卖。等到业务量真的大到需要引入消息队列的异步扣减时这套系统的架构也已经不适合继续扩展了需要换一套思路。另外每个下单接口都建议加分布式锁做二次防护。这里我直接用Redis的SETNX key value EX seconds命令模拟了分布式锁以订单号加房型ID作为锁的key防止极端情况下同一用户重复提交。4. 前端Vue开发实录4.1 Vue项目初始化与路由规划前端项目我用Vite创建执行npm create vitelatest选择Vue模板然后安装Vue Router、Pinia、Axios、Element Plus等依赖。这里建议创建项目时直接选Vue 3加JavaScript或TypeScript模板避免后期待构建工具配置的麻烦。路由规划上前台和后台做了拆分设计。前台页面/首页展示推荐民宿/search搜索结果页带筛选条件/hotel/:id民宿详情页展示民宿信息、房型列表、地图位置/booking/:roomId预订页选择日期和人数后生成订单/orders我的订单列表/login、/register登录注册页后台管理页我单独挂在/admin路由下用meta字段里的角色信息加上路由守卫做访问控制。.vue文件里的beforeEach全局守卫会在路由跳转前检查Token和用户角色没有权限直接重定向到登录页。这里提一下Vite的项目结构src/api目录单独放接口请求封装src/views放页面级组件src/router放路由配置src/store放Pinia状态。模块划分清楚之后每个人负责一个模块开发互不干扰这也是团队协作的基本要求。4.2 民宿列表和详情页的关键实现搜索页是用户使用频率最高的页面我用了Element Plus的el-date-picker组件做日期范围选择类型设置为daterange配上el-input-number做人数选择。提交搜索参数后通过Vue Router的query参数把搜索条件带进结果页URL这样用户刷新页面后搜索条件依然可以保持分享链接别人也能直接看到对应的搜索结果。这里用到了Vue Router的路由传参方法router.push({ path: /search, query: { city: 杭州, checkIn: 2024-01-10, checkOut: 2024-01-13 } })在结果页通过route.query读取。民宿列表的数据建议使用Computed属性做前端二次筛选。比如城市切换、价格范围拖动条、排序方式切换这些逻辑如果每次都在后端重新查一遍交互延迟体验很差。我的做法是后端先返回当前城市符合条件的民宿全量列表前端用computed配合filter和sorter方法实现即时筛选与排序响应速度可以做到毫秒级洗刷。真正需要提交给后端的分页筛选只在用户主动点击搜索时才触发。详情页要做的第一个事就是调接口拿到民宿详情数据然后在页面顶部用图片轮播展示民宿照片下面分模块展示设施标签、房型列表、位置地图、用户评价。Vue 3的computed在这里还可以用来派生价格区间、设施标签数量这类展示数据。地图模块我接的是腾讯地图JavaScript SDK拿到民宿经纬度坐标后初始化地图实例再挂一个AMap.Marker标记点基本十几行代码就能搞定。4.3 预订流程与总价计算的坑预订流程是整个前端开发里最容易出错的地方因为涉及到日期处理和时间计算。用户点击立即预订后进入预订页。预订页要展示房型信息、入住日期选择、离店日期选择、入住人数填写、订单明细。订单明细里最关键的是总价计算。我踩过的坑是后端在计算价格时使用的日期边界规则和前端不一致。举个例子用户选择1月10日入住、1月13日离店这表示住10号、11号、12号三晚。但有些情况下前端Date对象在new的时候如果直接传2024-01-13会生成一个UTC时间的凌晨部分时区下会出现日期偏移一天的情况。这种问题极其隐蔽不是必现但有用户反馈订单价格不对就很难排查。我的最终方案是统一用时间戳计算前端和后端都把日期转换成UTC零点的时间戳按(离店时间戳 - 入住时间戳) / 86400000计算总天数再把每天的价格从room_stock接口数据里拿累加起来。每天的价格可能不同所以不能简单地用基础价乘以天数。另一个坑是订单提交前的二次确认。用户填写完信息点击提交后前端先把订单数据POST到后端但期间库存可能已经发生变化。所以后端在创建订单前一定要重新校验库存并计算价格以前端计算金额为准还是以后端计算为准这一点必须明确。我的规则是前端展示的价格仅供参考后端重新计算的结果才是最终结算价格前端展示的金额会被后端的返回结果覆盖。5. 前后端联调跨域、鉴权与部署5.1 跨域问题的处理方案前后端分离开发第一个遇到的问题就是跨域。前端跑在localhost:5173后端跑在localhost:8080浏览器默认禁止跨域请求直接调用接口会报CORS错误。解决方案有几种后端配置CrossOrigin注解、前端配置Vite代理、再加一层Nginx反向代理。我在开发环境用的是Vite代理方案在vite.config.js里配置export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/hotelsVite会自动转发到后端的http://localhost:8080/api/hotels浏览器和Vite开发服务器是同源的跨域问题直接化解。生产环境部署时Nginx配置里同样把/api前缀的请求代理到Java服务进程的端口这是最靠谱的方式。不建议在代码里写死http://localhost:8080这种硬编码地址因为上线后域名和端口都会变会导致所有接口请求失败。统一用相对路径加代理是前后端分离项目的标准做法。5.2 登录鉴权与接口安全民宿预订系统有用户信息登录鉴权是必须做的。我选用的是JWT方案流程很简单用户登录成功后后端生成一个JWT Token返回给前端前端存储在localStorage里之后每次请求在Authorization请求头带上这个Token后端通过拦截器验证Token有效性和有效期。SpringBoot里实现拦截器先实现HandlerInterceptor接口重写preHandle方法然后注册到WebMvcConfigurer里去。白名单路径包括登录、注册、民宿搜索等公开接口需要登录的接口包括创建订单、查看订单、个人中心等。如果Token缺失或过期拦截器直接返回401状态码前端Axios拦截到401后跳转登录页。这个环节有一个细节很值得重视用户的密码一定要加密存储。我用的是Spring Security自带的BCryptPasswordEncoder注册时加密、登录时校验。就算数据库被拖出来短时间内也无法逆推出明文密码这是最基本的行业底线。5.3 打包部署的实战经验前端打包执行npm run build产物在dist目录里面就是一堆静态文件。我部署的时候把静态文件放到Nginx的html目录下Nginx配置里把/api开头的请求反向代理到Java服务。后端打成Jar包后直接用java -jar启动也可以用Docker封装成一个镜像部署到云服务器或者Kubernetes集群。这里分享一个我早期踩过的坑前后端分离部署时前端路由用的History模式访问/hotel/1这样的路径时Nginx直接返回404因为Nginx在html目录下找不到这个文件。解决办法是在Nginx配置里加上location / { try_files $uri $uri/ /index.html; }这样访问任何路径时Nginx都会把请求回退到index.html再由前端路由接管渲染对应页面。这个配置是Vue项目部署几乎必配的一项不配的话刷新页面就404体验极差。6. 开发中踩过的坑与排查技巧6.1 五个典型的坑整理了这次开发过程中比较典型的五个问题每一个都是真实遇到并排查了半天的写出来给大家避避坑。第一个坑是MySQL时区问题。连接数据库的URL里如果没有加serverTimezoneAsia/Shanghai默认用的是服务器时区一般和本地差8小时导致日期数据错乱。排查思路是看数据库连接串必须显式指定时区不能依赖默认值。第二个坑是MyBatis Plus的字段映射。实体类里用了checkInDate这种驼峰命名字段数据库字段是check_in_date如果MyBatis Plus没有开启驼峰映射查询出来的字段全部为null。MyBatis Plus默认配置下问题不大但如果是自己搭的MyBatis框架要检查mapUnderscoreToCamelCase配置是否开启。第三个坑是前端路由的懒加载。一开始项目小所有路由都同步加载没发现问题。到后期页面多了打包出来的JS文件三四兆首屏加载特别慢。后来把路由全部改成懒加载用动态import()方式引入组件首屏体积减小了一大半。这个优化建议项目一开始就做。第四个坑是Element Plus的日期选择器默认值。组件el-date-picker在没选日期时的value是null如果直接把这个null传给后端接口做日期计算后端会报空指针。我统一在前端参数校验里加了判断同时后端接口也做非空校验双保险。第五个坑是民宿列表的图片加载。民宿图片用的是图床URL有时候加载慢或者防盗链页面大片空白。后来加了loadinglazy属性做懒加载配合一个默认占位图用户体验好了很多。图片这块如果数据量再大还可以考虑接对象存储服务CDN加速但小型系统完全没必要。6.2 排查工具与调试心得开发中排查问题的效率很大程度上取决于工具链是否顺手。我在这个项目里用到的调试手段主要有三类。第一类后端调试。SpringBoot项目启动时开启调试模式配合IDE的断点调试可以逐步跟踪每次请求的处理流程。对于接口返回的数据结构和字段问题这个方法非常有效。我还习惯在Service层写日志用Slf4j注解注入Logger在关键业务流程处打日志比如下单时打印参数和扣库存结果出问题一查日志就能定位不需要每次都在数据库里翻记录。第二类前端调试。Vue项目的调试核心是浏览器开发者工具和Vue Devtools插件。Vue Devtools可以看到组件树、Props、Computed、Pinia状态排查页面数据不更新的问题特别有用。我在页面里添加了console.log输出关键变量包括接口返回的数据、搜索参数等出现问题先在浏览器控制台看请求和响应再决定排查方向。第三类接口调试。前后端分离项目接口调试我直接用Postman可以保存请求历史、管理环境变量、快速测试各种边界场景。尤其是下单接口这种有状态、有并发风险的接口我习惯用Postman的Runner功能一次跑多个并发请求验证库存扣减的原子性或超卖问题。等后面项目再大一些可以接一套接口自动化测试平台但当前阶段Postman已经足够。还有一个排查心得很重要遇到bug先看请求和响应再查代码最后才查数据库。很多人一上来就在数据库里翻数据但前端报错往往只反映了表象真正的原因要么在接口层要么在参数传递所以先把请求链路走一遍基本能解决七成以上的问题。7. 这个系统还能怎么扩展项目做完以后其实还有不少可以扩展的方向这个取决于实际业务量和个人学习目标。如果是想往分布式方向深入学习可以把Redis的缓存策略做得更细比如民宿详情缓存加过期时间、热点民宿做缓存预热给库存扣减接上消息队列做异步削峰把订单服务改造成独立的微服务模块。这些方向可以逐一拆开做性能优化和架构演进练习。如果是面向真实业务场景可以考虑接入主流地图服务的路线规划API让用户搜索某地铁站附近的民宿接入第三方登录比如微信扫码登录做一套运营后台的优惠券和会员积分体系提升用户留存率。管理员端还可以增加数据可视化大屏把热门民宿、满房率、实时销售额做成大屏图表运营人员每天打开就能看到经营状况。我个人在实际操作中最大的体会是这类全栈项目真正的难点不在单个技术栈而在于把前后端的数据流和业务规则对齐。日期计算规则、状态流转规则、价格计算规则这些业务逻辑里只要有一个前后端理解不一致功能就一定会出bug。所以开发前先把需求点逐条列出来明确这个数据由谁产生、由谁消费、什么规则变更后面写代码的时候会顺畅很多。最后再分享一个习惯每完成一个模块不只是功能跑通我还会顺手把关键业务场景的测试用例写好。不是那种代码级的单元测试而是把核心场景的操作步骤和预期结果写下来作为验收依据。这个习惯帮助我在后续页面增加功能时能快速判断哪些原有逻辑受到了影响个人非常推荐。
