做酒店预订系统的时候很多人上来就打开携程、美团看一眼然后说“就照这个风格做一套”。这个想法本身没有错但等你真正拿到一套基于SpringBoot和Vue的酒店预订系统源码开始往本地跑、准备二次开发的时候才会发现页面好看是最不重要的数据库脚本能不能一次跑通、订单状态能不能闭环、并发下会不会出现两单抢一间房才是这套系统值不值得用的关键。我这阵子正好帮人完整整理了一套酒店预订系统源码、数据库脚本、开发文档都齐这里把我从拿到项目到跑通、再到现在准备二次开发的心得完整写一写给正在做同类项目的朋友一个参考。1. 拿到源码先别兴奋你的第一步是读文档而不是开IDE很多人拿到源码的第一反应是直接双击IDEA然后跑起来看效果。但酒店预订系统这种业务型项目前台、后台、数据库脚本、说明文档混在一起直接开跑大概率会卡在数据库连接上。我的习惯是先花半小时把目录结构和说明文档过一遍搞清楚项目的整体组织方式再决定先启动前端还是后端。1.1 项目目录里到底藏了什么这套系统通常分为三个部分SpringBoot后端工程、Vue前端工程、以及数据库脚本和文档。后端工程一般是标准的Maven目录结构src/main/java下面按模块分包常见的有controller、service、mapper、entity、config、common、utils等。建议你先看application.yml或application.properties里面包含了端口号、数据库连接信息、Redis配置等关键参数。前端工程如果是Vue 2 Element UI目录下会有src/views、src/router、src/api这些常规目录如果是Vue 3 Element Plus结构也类似只不过组合式API的写法会让你多花一点时间习惯。数据库脚本通常是一个或者多个.sql文件有的项目用一个init.sql全部搞定也有的会拆成schema.sql和data.sql甚至按模块拆成多个脚本。文档一般包括需求文档、接口文档、部署文档、数据库设计文档。我的建议是优先看部署文档因为部署文档会写清楚项目使用的JDK版本、MySQL版本、Node版本以及各种环境变量的要求。1.2 数据库初始化顺序为什么重要很多新手拿着脚本执行时报错报错信息千奇百怪其实多半是执行顺序错了。比如先执行了包含外键的data.sql但schema.sql还没跑表都不存在自然插入失败。正确的顺序是创建一个独立的数据库比如hotel_booking注意字符集设置成utf8mb4。先执行建库建表脚本确认所有表都创建成功。再执行初始化数据脚本这一步会把管理员账号、房型数据、房间数据、价格日历等都插入进去。最后执行可选的测试数据脚本如果带了演示数据那就顺便生成一批订单和客户记录。如果你遇到外键约束报错可以用SET FOREIGN_KEY_CHECKS0;临时关闭外键检查但用完记得改回来否则后面业务代码里数据错乱了你都察觉不到。提示数据库初始化不是“跑一次就行”。如果你要反复测试最好能写一个重置脚本把删除库、建库、导入数据三步串起来这样每次测试完一键恢复初始状态效率会高很多。2. 酒店预订系统的数据库底座拆开表结构看业务闭环酒店预订系统里表与表之间的关系特别典型客人、房型、房间、订单、价格、支付、评论、权限……每一张表都不是凭空造出来的背后都是一条业务规则。我拿到系统后都会先画一张简单的关系图不是用工具生成而是在脑子里理清楚用户下单时系统到底需要读哪些表、写哪些表。2.1 房间、房型、价格日历三张最容易搞混的关联表先说房型与房间。房型是标准化的产品比如“高级大床房”“豪华双床房”房型表一般包含房型名称、面积、床型、可住人数、设施描述、图片等。房间是具体可售的物理房间比如“3号楼502”每间房都属于某个房型包含房间编号、楼层、朝向、状态空闲、打扫、维护、已入住。很多初学者会把“价格”直接挂在房型上加上一个每晚多少钱的字段这样看似简单但一到节假日就麻烦了。酒店价格是动态的同一种房型平时500一晚五一可能800一晚周末也可能上浮。所以成熟项目里一定会有一张价格日历表以“房型日期”为唯一键来存每日价格。这套系统里这三张表的关联逻辑是客人查询可订房间时先按日期和房型筛选出符合条件的房间。然后根据入住日期到退房日期在价格日历表中查出每晚价格累加出总价。订单提交后系统要再次校验价格防止前端篡改后提交过来的价格和后台计算不一致。我见过不少项目图省事价格只放一张表结果上线后每逢节假日都要临时改数据改完还要手动通知前端特别痛苦。2.2 订单表为什么需要冗余快照字段订单表是整套系统里最复杂的表因为它既要记录“这笔交易发生了什么”又要在后续查询订单详情时能快速展示。订单表除了常规的订单号、用户ID、房型ID、房间ID、入住日期、退房日期、下单时间、订单金额、支付状态之外一定要有冗余快照字段。所谓快照就是下单那一刻把房间名、房型名、价格、图片、酒店地址等用户看到的信息原样存一份到订单表里。为什么因为房间信息后续可能被运营人员修改比如房型名称改成了“豪华精品房”图片换了价格调整了。如果订单表不存快照用户查询历史订单时就得去关联房型表和价格日历表万一数据已经被删除订单详情页面就出现一片空白这肯定是不能接受的。此外订单状态字段建议单独用一个小型字典表维护比如“待支付、已支付、已确认、已入住、已退房、已取消、已退款”。不要直接散落在订单表里用字符串硬编码因为后面你要做统计报表时状态一多各种奇怪的组合会把SQL写得无比痛苦。2.3 状态变更日志审计痕迹比想象中的更重要很多酒店预订系统的源码里会忽略订单状态变更日志表但我在实际交付时一定会补上。这张表记录每一笔订单从创建到取消的每一次状态变更包括变更前的状态、变更后的状态、操作人ID、变更时间、备注。为什么要加这张表因为线上总会遇到客人投诉“我明明没取消订单怎么变成已取消了”这时候你需要有据可查。虽然听起来是小事但酒店前台每天处理几十个订单一旦纠纷升级到平台层面日志表就是最好的证据。我通常会把这张表和订单主表分开用订单ID建索引查询单个订单的变更记录时加上时间排序这样既不影响订单主表的写入性能又方便排查问题。3. SpringBoot后端接口里的硬骨头鉴权、并发、状态机数据库准备好了后端接口才是重头戏。酒店预订系统虽说不算大型项目但涉及的角色不少客人、前台工作人员、管理员有时候还有酒店自己的店长角色。每个角色能做的事不一样所以鉴权必须做扎实。3.1 JWT登录与角色权限控制这套系统里登录用的是JWT令牌方案用户登录成功后后端签发一个token返回给前端前端每次请求在请求头里带上Authorization: Bearer token后端通过拦截器统一校验token再解析出用户身份。权限控制这里有个容易踩的坑不要只在前端做菜单隐藏后端接口也要校验。比如普通客人直接请求/admin/order/list如果没有权限认证接口数据就裸奔了。SpringBoot实现起来其实简单用拦截器配合自定义注解或者在SpringSecurity里配置接口角色即可。如果是自己写的拦截器建议把“不需登录就能访问”的接口比如登录、注册、首页轮播图单独放进白名单。另外JWT有一个很现实的问题token过期了怎么办。单纯设置过期时间会让用户频繁掉线但如果token永久有效也不安全。项目里比较常见的做法是双token方案登录时同时返回一个短期accessToken和一个长期refreshToken。当然如果只是毕业设计或内部系统单token也够用把过期时间设置成2小时左右就差不多了。3.2 预订接口的防并发超卖处理最核心的接口就是“提交预订”。这里有并发问题两个客人同时看中同一间房同一秒内同时下单如果后端不做控制就可能把同一间房分别生成两个订单最终导致超卖。解决思路通常有三种数据库乐观锁在房间表加一个version字段下单之前先查房间状态执行更新时带上version条件如果影响行数为0说明已经被别人改了就提示“客房已被预订”。状态机约束房间表字段里记录当前房间状态下单时执行UPDATE room SET status维护中 WHERE id? AND status空闲这类语句利用数据库行锁保证同一瞬间只有一个请求能成功。Redis分布式锁用SETNX加锁锁的key用room:book:{roomId}拿到锁才继续下单流程。这种方式在高并发下表现最好但需要引入Redis。我在这套系统里实际采用的做法是先加Redis锁再在更新房间状态的SQL上做状态判断两层保险。Redis锁能挡住绝大多数并发请求数据库状态判断兜底防止缓存失效或锁过期造成的极端情况。下单接口的完整流程大致是校验用户登录状态获取userId。校验房型、房间、日期是否有效。加锁锁的key带房间ID和入住日期。生成唯一订单号。再次读取房间状态确认为空闲。计算总价写入订单表状态待支付。更新房间状态为“锁定”或生成一条入住锁定记录。释放锁返回订单号。这里要注意房间状态不能一上来就改成“已入住”因为客人可能只是下了单还没支付。比较合理的是引入“锁定”状态配合支付超时自动取消的定时任务比如超过15分钟未支付就把房间释放回空闲。3.3 订单状态机的统一流转状态机听起来高大上其实就是一个规则订单只能从A状态流转到B状态不能从A直接跳到C。比如“待支付”可以变成“已支付”也可以变成“已取消”“已支付”可以变成“已确认”但绝对不能变成“待支付”。后端实现时最好把订单状态转换的逻辑集中在一个方法或一个Service里不要到处散落if (order.getStatus() 2)这样的判断。我就见过一个项目里取消订单的逻辑在Controller里也写了一遍在Service里又写了一遍后来两个地方的判断条件不一致导致一个订单在特殊状态下出现了“已取消”和“已完成”同时存在的幻觉数据。状态流转统一之后还有一件事值得一提订单取消之后要不要释放房间如果用户只是待支付状态取消房间自然要释放如果已经支付取消就涉及退款房间也要释放但如果是“已入住”状态那就不能叫取消只能算“提前退房”这笔订单的钱怎么算、押金怎么退又是另一种规则了。所以状态机里每条边都要标清楚操作人是谁、需要执行什么副作用动作。4. Vue前端不只是在写页面路由、状态、组件的三层联动后端接口做得再严谨前端如果一塌糊涂系统给人的感觉依然是个半成品。酒店预订系统的前端分两块客人端和管理后台。客人端偏展示和交互管理后台偏数据表格和表单。这两块的代码组织思路有差异不能混在一起写。4.1 动态路由和菜单权限如何跟后端角色对齐Vue前端里最影响开发效率的是路由权限设计。如果只有管理员和普通用户两种角色直接在router.beforeEach里判断一下就行但酒店系统通常有管理员、前台、店长三种以上角色每个角色看到的菜单不同这就得做动态路由。动态路由的思路是前端在登录成功后拿到当前用户的角色和权限码列表再动态把对应的路由模块用router.addRoute添加进去。比如管理员能看到“房型管理”“订单管理”“用户管理”前台只能看到“订单管理”“房态管理”客人端则只能访问预订相关的页面。这套系统里我建议把菜单信息也做成后端接口返回的一组数据前端根据菜单数据直接渲染侧边栏菜单中的path和前端路由的name保持一致。这样当你未来要加一个新页面时只需要在后端菜单表里插入一条记录不需要改前端硬编码二次开发会省很多力。4.2 从房间列表到支付结果一个订单的完整前端链路客人端预订流程大致是首页/列表页选择入住日期和退房日期选择城市或酒店。系统根据日期筛选出可预订的房间列表。点击“立即预订”弹出订单确认页显示房型、价格明细、入住人信息。提交订单后进入支付页面模拟支付或跳转第三方支付。支付完成跳转订单成功页展示订单号和入住提醒。这里有个容易忽略的点房间列表页的“最近可订”状态要实时反映后端数据。尤其是价格前端不能只显示一个静态数字要在进入列表页时根据当前选择的日期去请求价格日历接口同时后端要校验请求的日期是否符合预订规则比如不允许预订今天之前的时间。另一个体验细节是日期选择。酒店预订一定要避免“当天入住当天退房”这种无效区间前端日期组件要配置disabledDate限制退房日期至少要晚于入住日期一天。后端同样要校验因为接口可以被绕过。4.3 管理后台的表格与统计页面怎么做到不崩管理后台的核心页面是订单管理、房间管理、房态日历、报表统计。这些页面最大的通病是一次加载所有数据导致接口响应慢表格渲染卡顿。我在这套系统里的做法是严格使用分页查询前端表格用分页组件后端接口接收pageNum和pageSize。房态日历这种特殊页面则按月份查询只加载当月的房间状态数据避免动辄几千条记录一次性返回。统计报表页面比如近30天订单量、营收趋势、入住率不要尝试在前端用表格数据现算直接让后端写SQL统计好再返回前端只负责把数组渲染成折线图或柱状图。这样既减少前端代码量又避免因数据量增长导致计算错误。注意前端请求接口时的统一异常处理一定要做。如果后端返回401就跳转登录页返回403就提示无权限返回500就弹出统一错误提示。不要每个页面都写一遍catch用axios响应拦截器统一处理能省掉大量重复代码。5. 跑通系统后我踩到的三个高频部署坑项目在本地IDE里跑得飞起一部署到服务器就各种问题。这不是个例。我从这套酒店预订系统的部署过程中挑出了三个最容易耽误时间的坑你大概率也会遇到。5.1 跨域配置前端请求后端为什么被浏览器拦本地开发时前端是localhost:8080后端是localhost:9090端口不一样浏览器就会拦截跨域请求。最简单的解决办法是在SpringBoot里配置一个CorsConfig允许指定的前端地址跨域访问。但部署到服务器后情况不一样了。如果后端接口地址和前端页面域名不同依然会跨域。更标准的做法是用Nginx把前端和后端反向代理到同一个域名下前端请求相对路径/apiNginx把/api转发到后端服务。这样浏览器里看到的所有请求都指向同一个域名和端口就不会有跨域问题。我在配置这套系统时前端是/hotel路径后端接口是/hotel/apiNginx配置如下server { listen 80; server_name your-domain.com; location /hotel/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /hotel/api/ { proxy_pass http://127.0.0.1:9090/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里要注意proxy_pass后面的路径后面带不带/可能导致转发路径完全不一样我因为多写了一个/吃过亏调试了半天才发现接口404。5.2 Java版本和数据库编码导致的中文乱码SpringBoot项目的JDK版本问题最常见。源码如果是用JDK 8写的你非要用JDK 17跑大概率会遇到各种反射相关报错。解决办法很简单看文档里要求的版本装对应的JDKIDEA里Project Structure和Maven的Java版本都设置一致。数据库方面中文乱码十有八九是字符集配置不对。MySQL8默认字符集一般是utf8mb4但如果建库时选错了或者表里字段是latin1导入数据就乱。最好在建库时就固定CREATE DATABASE hotel_booking DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;同时后端application.yml里的连接串也要带上characterEncodingutf8useSSLfalse。我建议在连接串里顺便加上serverTimezoneAsia/Shanghai否则日期字段会出现时间差8小时的诡异问题。另外Linux服务器上的MySQL如果校验规则比较严格比如sql_mode包含了ONLY_FULL_GROUP_BY某些统计SQL可能跑出我们根本没想到的错误建议部署时检查一下MySQL配置。5.3 Nginx反向代理下的前端路由history模式Vue项目默认是history模式路由路径像/hotel/order/detail/123如果刷新页面Nginx会直接找这个路径对应的文件结果是404。解决办法是在Nginx配置里加上location /hotel/ { try_files $uri $uri/ /hotel/index.html; }这样当前端路径没有对应的真实文件时Nginx会回退到入口index.htmlVue路由再自行解析路径页面就不会刷新就白屏了。这一步没有配置的话很多人会误以为是后端接口挂了其实只是前端路由重定向没做。6. 拿到源码二次开发我会优先改这五个地方一套能跑起来的源码只是起点真正让它有商业价值的是二次开发。以我个人的习惯如果接下来要在这个酒店预订系统上扩展我会优先动这五个地方。6.1 把房间图片存储迁移到对象存储很多源码的图片是用本地目录存储的上传到服务器后路径存在数据库里用Tomcat映射出来访问。这种方式在单机部署下没问题但以后要扩容、要加CDN就麻烦了。我会把图片存储迁到MinIO这类对象存储服务后端只负责生成上传链接和读取链接图片访问不占用应用服务器带宽。SpringBoot集成MinIO也不难引入minio依赖配置endpoint、accessKey、secretKey再写一个上传Service就行。6.2 对接真实支付网关而不是后台模拟支付源码里多半是点击“支付”直接跳转到“支付成功”页面模拟逻辑写得很简单。真要上线需要对接微信支付或支付宝支付下单后返回一个支付二维码前端轮询订单支付状态。这里有几个细节回调验签必须做好防止伪造回调订单号要做幂等防止回调重复通知导致重复发货回调处理时千万不能用同步逻辑卡IO否则支付平台会超时重试。6.3 加入短信或邮件通知酒店预订不是电商下单客人越临近入住越需要消息提醒。我打算在下单成功、确认入住、退房提醒三个节点加入短信通知或者至少加入站内信和邮件通知。如果用阿里云短信会用模板变量传递订单号和酒店名称库存担心渠道审核问题可以先做成开关控制部署在测试环境时用日志打印代替真实发送。6.4 价格策略与促销管理原系统的价格日历是手动维护的运营成本高。二次开发时我会加入促销规则表比如“连住2晚9折”“提前3天预订减50”“节假日统一加价50元”在计算价格时通过一个优先级规则引擎计算出最终金额。这样前端依然调价格计算接口但逻辑会灵活很多。6.5 数据字典和操作日志系统里像订单来源、支付方式、证件类型、客人来源渠道这些字段直接用下拉框枚举也行但后续要增加选项就得改代码。我会把这些统一收拢到数据字典表用字典类型加字典项的方式维护。操作日志前面提过但我强调一下不只是订单状态变更后台人员的所有关键写操作都应该记录日志像“修改房间价格”“删除某条房态记录”这种操作一旦出现问题复盘非常有用。我在实际使用这套SpringBoot Vue酒店预订系统的过程中最大的体会是跑通一套完整项目不难但真正理解每个模块为什么要这样设计然后敢去改它才是做项目该有的状态。数据库脚本不要一次性导入就完事多备份几个版本接口文档不要写完后丢进文件夹不管等你要接小程序端或者App端时你就知道文档写清楚有多省事了。后面我还会把支付对接、房态日历优化这些模块单独拿出来分享有在酒店预订系统这条路上摸石头过河的朋友可以先收藏起来慢慢看。