1. 为什么我选择Spring Boot来做酒店预订系统这个项目其实是我在服务某小型连锁酒店时接到的需求。他们原来的预订方式还是电话和表格登记前台每天要花大量时间核对房态、手写订单、月底对账更是灾难。最开始我想过要不要用现成的SaaS平台但对方有几个硬性要求——数据要存在自己服务器上、要能和已有的会员系统打通、后期还可能对接门禁和发票系统这几条下来基本就排除了第三方方案。最终敲定用Spring Boot自己开发一套酒店预订系统顺便也把完整的源码、数据库脚本和文档整理出来方便后续二次开发和维护。先说结论选Spring Boot不是因为它最潮而是因为它最适合这类业务系统的落地节奏。酒店预订这种领域核心不是算法多牛逼而是业务状态多、流程链条长、并发场景集中比如节假日抢房、支付回调、订单状态流转这些东西需要一套成熟稳定的框架来兜底。Spring Boot自带自动配置和起步依赖能让我把精力放在业务代码而不是XML配置上再加上Spring全家桶的生态MyBatis、Redis、Spring Security这些都是现成的团队接手成本也低。这个系统当时规划的功能面不算小前台可以管理房型和房态用户端能注册登录、搜索房间、提交订单、在线支付模拟、查看订单历史后台还能统计入住率和营收报表。整个项目做下来源码加数据库脚本加文档一共不到几万行但覆盖了一个真实预订系统应该有的绝大部分核心节点。我觉得这个项目的价值不只是“能跑”而是它把酒店业务的特殊逻辑——比如房态冲突、连住拆单、超卖防护——都落到了代码里这部分恰恰是很多CRUD Demo缺失的。如果你正在学Spring Boot或者准备做毕业设计又或者公司需要一套轻量级的酒店管理原型这套东西都很适合拿来解剖。读代码的时候不要只看Controller写了啥重点看订单状态怎么流转、库存怎么扣减、事务怎么控制这些才是真正决定系统能不能扛住真实业务的地方。2. 数据库设计酒店业务的核心在“房态”和“状态机”2.1 表结构设计上的几个关键决策酒店预订系统和普通电商比数据库设计上有几个不太一样的点。普通商品库存是一个数字但酒店的“库存”是日期房型房间号的三维组合。同一个房间今天可售明天可能就订出去了所以不能简单在一张表里维护一个库存字段。我最终设计了这么几张核心表酒店表hotel管理分店信息虽然系统里一般只有一家店但预留多店扩展能力房型表room_type定义大床房、双床房、套房等分类记录门市价、床型、面积、可住人数房间表room关联房型具体到房间号比如“501大床房”客户表customer注册用户信息包括手机号、密码摘要、会员等级订单表orders订单主表记录用户、房间、入住离店日期、订单状态、支付状态、金额订单明细表order_item订单里每间房每晚的价格快照方便处理连住多晚分拆计价房态计划表room_status_plan核心表记录每个房间在某个日期段的状态可售/锁定/已入住/脏房这个设计有一个细节值得展开为什么不直接用订单反查房态而要多建一张房态计划表因为订单是业务操作的日志结果不适合做高并发的可用性判断。房态计划表相当于一个预占状态模型用户在搜索房间时系统只查这张表就能快速算出某房型在某日期段剩几间不需要join订单表做一堆日期重叠判断。虽然多了一张表维护成本高了但查询速度和逻辑清晰度都提升了一个档次。2.2 状态管理订单和房态必须有独立的状态机做酒店系统最容易翻车的地方是把订单状态和房态混在一起管理。我的做法是拆成两条状态线订单状态order_status待支付pending下单但没付款房态处于锁定状态一般锁15分钟已支付paid付款成功房态从锁定转为已预订已入住checked_in用户到店办理入住房态变为占用已退房checked_out退房后房间变成脏房等待打扫已取消cancelled用户取消或超时取消释放房态房态状态room_status可售available锁定locked订单待支付期间临时占住预占booked订单已支付但还没入住占用occupied实际入住脏房dirty退房未打扫维修maintenance人工设置的房间维修状态这两条线靠订单号和房间号关联但状态各自演进互不干扰。我用一个枚举类把它们统一管起来并在代码里禁止跨状态直接跳转比如订单状态不能从“待支付”直接跳到“已入住”必须经过“已支付”或后台强制操作。这种约束让系统在多人协作时不容易产生脏数据。2.3 索引与查询性能的实测调优初期跑测试数据的时候发现按日期范围搜索房间特别慢。explain一看问题出在房态计划表的查询没法有效利用索引。原因是我把“开始日期”和“结束日期”分开存搜索“1月10日到1月12日可用的房型”时要写类似start_date end AND end_date start的重叠判断这个条件天然不适合B树索引。后来我调整了策略加了一个冗余字段date_single把每晚的房态拆成独立的行记录每行就是“某房间在某一天的状态”。查可用房间时就变成了WHERE date_single BETWEEN ? AND ? AND status available GROUP BY room_id HAVING COUNT(*) 天数这样索引就能正常走了。这套“拆分日期明细”的方案是以空间换时间一张表行数变多了但单次查询从几百毫秒降到十几毫秒。如果你的预订系统也遇到日期搜索慢的问题可以考虑这个思路。3. 核心业务模块实现不只是增删改查3.1 搜索可用房间的完整逻辑搜索模块是整个预订流程的入口也是最容易让用户放弃的环节。一个小白用户进来输入城市、入住日期、离店日期、人数系统必须快速返回有哪些房型可选。这个接口的实现我拆成了几步校验日期参数入住不能早于今天离店必须晚于入住连住不能超过30天这是业务规则根据城市关联酒店再关联房型查询房态计划表统计每个房型在日期区间内“每天都可售”的房间数量排除维修状态的房间排除已经被锁定或预占的房间返回每个房型的可用房间数、门市价、会员折扣价这里有一个比较隐蔽的业务点可用房间数是“每天都有”的数量而不是“区间内合计出现次数”。比如某房型一共5间区间内每天能查出5间不代表全程可用因为中间某天可能被订走。所以SQL里必须有COUNT(DISTINCT date_single) 区间天数的限定这个条件写不对查出来的库存就是虚高的。我见过不少初版系统栽在这个细节上用户下完单才发现根本没房只能手工退款。前端页面上搜索结果的卡片需要展示房型图片、价格、床型、面积、剩余房数。剩余房数我做了分类展示大于3间显示“充足”1-3间显示“仅剩x间”0间直接置灰。这种细节对提升预订转化率挺管用的用户会产生紧迫感。3.2 下单、支付与超时释放的并发控制下单接口是并发压力最大的地方。想象一下周五晚上某网红酒店放出少量特价房几十个人同时点“预订”这时候绝对不能出现两个人都下单成功的情况。我的方案是乐观锁数据库唯一约束双保险。在房态计划表上维护一个version字段下单时先执行条件更新UPDATE room_status_plan SET status locked, version version 1 WHERE room_id ? AND date_single ? AND status available AND version ?如果受影响行数为0说明这间房已经被别人抢先锁定了直接返回“房源紧张”。如果全部日期都更新成功再创建订单。这种方式比直接用SELECT FOR UPDATE的悲观锁性能好也避免长事务持锁导致连接池被耗尽。支付回调的幂等处理也值得重点说说。我在订单表上加了transaction_no唯一索引支付回调每一次都先检查这个流水号有没有处理过。如果处理过直接返回成功不再重复修改订单状态。不然万一回调重试了两次订单金额或者状态就可能被改错。超时释放用了一个简单的定时任务每两分钟扫一次“待支付且锁定时间超过15分钟”的订单把对应房态计划恢复到可售同时把订单标记为超时取消。3.3 订单状态扭转与事务边界划分订单从“待支付”到“已支付”再到“已入住”每个环节都涉及多张表的联动修改。比如确认支付后需要做三件事修改订单状态为已支付把对应日期段的房态计划从“锁定”改为“预占”给会员累计积分这三件事必须在一个事务里完成任何一步失败都要回滚。我在Service层用Transactional注解控制传播级别用默认的 REQUIRED内部方法之间调用要特别注意自调用的问题——同一个类里A方法调B方法B的Transactional是不生效的因为this调用不走代理对象。我踩过一次这个坑排查了半天才想起来是自调用问题后来把需要事务的方法拆到不同的Bean里才解决。还有一个事务边界的设计心得不要把长时间的外部操作放进事务里比如调用第三方支付接口、发送短信验证码。这些网络请求的耗时可能是几百毫秒甚至几秒如果放在数据库事务里连接会被一直占用并发一高整个系统的连接池就告急了。我的做法是事务内只做数据库状态变更支付请求在事务外发支付结果通过回调来驱动状态流转。4. 开发中踩过的四个坑与完整排查链路4.1 日期区间查询的索引失效这是数据库层最烦人的一个问题。最开始我写的按日期范围选房的SQL查询条件是WHERE start_date ? AND end_date ?这是标准的区间重叠判断。测试数据量小的时候没觉得慢等导入了两年的房态数据后接口直接超时。排查步骤是这样的先打印SQL执行计划typeALL全表扫描尝试给start_date和end_date分别加索引发现MySQL优化器还是放弃了索引因为两个条件都是范围查询选择性不高验证了索引合并也没啥效果后决定改表结构引入单日明细表方案这个经历给我的教训是数据库索引不是万能药设计时就要考虑你的查询形态是否能利用到B树的有序性。区间重叠类的条件本质上就不适合关系型数据库优化要么用明细行拆开要么引入时间段维度表别硬扛。4.2 事务自调用导致的失效有一次测试支付流程时发现订单状态更新了但房态没改过来数据对不上。单独调用房态更新的方法明明没问题放在一个Service里就失效。后来翻代码发现Controller调的是Service的A方法A方法内部调用了同一个类的B方法而B方法上标了Transactional。因为Spring的事务代理机制是基于AOP的同类内部调用走的是this不经过代理对象所以B方法的事务注解根本不会被解析。这个问题有个俗名叫“自调用陷阱”。我最后把一个内部方法移到了独立的Bean里通过注入新Bean来调用事务就生效了。这个坑特别隐蔽因为代码编译和运行都不报错只有数据异常时才暴露。建议所有给方法加Transactional时的第一反应就是看看这个方法是给谁调的跨Bean调用才靠谱。4.3 并发下单时的超卖风险压测时开了100个并发线程同时抢同一个房型结果生成了十几个订单但房间只有8间。问题出在我最初校验库存用的是先查询再更新的模式——先select看有没有房再update扣库存这中间有巨大的并发窗口多个线程都能查到“还有房”。这也让我认清了乐观锁的真实使用边界不是所有表都适合加version做乐观控制因为并发高的时候乐观锁的失败重试会浪费大量数据库操作。针对房态预占这个场景我最后换成了条件更新CAS式的update语句单条SQL保证状态判断和修改原子进行校验和占用在数据库层面完成了不再依赖应用层的先查后改。改了之后压测数据就稳定了同一个房间的预占成功率符合预期。4.4 前后端联调时的跨域问题前端跑在8081端口后端Spring Boot跑在8080端口联调时所有请求都被浏览器拦成了跨域错误。这不是Spring Boot特有的问题但Spring Boot的解决方式很简单。我在配置类里写了一个全局CORS配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有个细节需要留意生产环境不要用allowedOriginPatterns(*)加allowCredentials(true)的组合这对所有域名都放了cookie权限属于安全漏洞。合理做法是维护一个允许跨域的域名白名单只对列表里的域名放开。5. 项目结构与部署这套代码怎么组织才算合格5.1 分包结构与包名命名规范分包我采用的是经典的分层结构但比很多教程里的写法多了一层领域划分controller接收请求只做参数校验和结果封装service业务逻辑层事务边界在这里mapper持久层接口entity数据库映射实体dto数据传输对象主要是接口的入参出参common统一返回结构、全局异常拦截、枚举定义config配置类task定时任务util工具类这里有一件事我比较坚持Controller层不允许直接返回entity。数据库实体里面可能包含密码字段、冗余字段直接暴露给前端不合适。我专门定义了VOView Object来承载需要展示的字段通过BeanUtils复制属性。虽然多写了一点代码但接口文档和前端的数据契约就清晰了。5.2 配置文件的区分管理我把配置拆分成了三个文件application.yml通用配置包括端口、应用名、日志级别application-dev.yml开发环境本地数据库地址日志输出到控制台application-prod.yml生产环境独立的数据库地址日志输出到文件并做滚动切割启动时通过spring.profiles.active环境变量来指定用哪套配置。这个习惯帮我避免过好多次把测试环境配置发到生产的事故。配置里的敏感信息比如数据库密码我没有硬编码在文件里而是通过环境变量注入部署时在服务器上配置好。有人说密码放配置文件里图省事但一旦数据库被脱库连带一堆项目的密码都泄露得不偿失。5.3 部署流程与一键启动脚本因为项目规模不大我用了相对传统的部署方式打jar包 服务器上systemd管理进程。打包的时候有一个细节排除测试代码用mvn package -DskipTests避免测试类里连不上测试数据库导致打包失败。服务的启动脚本大概长这样nohup java -Xms512m -Xmx512m -XX:HeapDumpOnOutOfMemoryError \ -jar hotel-reservation-system.jar \ --spring.profiles.activeprod \ --server.port8080 \ logs/app.log 21 -XX:HeapDumpOnOutOfMemoryError这个参数平时用不上但系统OOM时能自动生成堆转储文件排查内存问题的时候就靠它了。我希望这个项目不要一直在宿舍楼或本地环境里待着而是真正地被部署到一台Linux机器上开启生产配置跑起来这样你才能体会到从代码到服务的完整链路是什么样也才能真正暴露出开发环境从来没出现过的资源问题。数据库初始化脚本放在db/目录下包含建表语句、初始房价数据、测试账号。首次部署时导入即可不用手工去库里敲SQL。初始化数据里我放了十几间房的示例数据覆盖了大床、双床、套房三个房型日期范围也做了前两个月的数据方便直接体验完整的预订流程。6. 交付文档怎么组织让接手的人不看代码也能跑起来很多人做完项目不爱写文档觉得代码就是文档。但这种偏业务型系统如果不把业务规则写清楚后面的人接手就是灾难。我这次的文档分成三本分别给不同角色看系统部署文档给运维或自己看的包括环境要求JDK版本、MySQL版本、Maven配置、初始化数据库步骤、打包命令、启动方式、常见报错处理系统设计文档给二次开发的人看的包含架构图我用简单文本画的没有用太复杂的工具、数据库表结构说明、每个字段含义、核心接口的调用时序、业务状态机说明用户操作手册给前台运营看的包括怎么开房型、怎么手动调整房态、怎么查报表写设计文档时有一个心得别贴大段代码要贴关键逻辑的说明和接口的定义。代码会变但接口契约和业务规则相对稳定。像订单状态机那张图我用纯文本的方式把每个状态能执行什么操作、会跳转到哪个状态列清楚了谁来看都能快速理解这套预订流程的设计意图。另外在数据库脚本上我做了版本管理。第一版是v1.0_init.sql后面调整表结构就新增增量脚本v1.1_add_room_status_plan.sql不直接改初始脚本。这种习惯在正式项目里可以保证老库可以平滑升级不会因为重新执行初始化脚本而丢数据。对于学习用途的项目来说这种方式还能让你对比出“表结构演进”的过程这比看最终的建表语句要有价值得多。最后再分享一个自己长期使用的小习惯每写完一个模块就手动测一遍完整的业务链路包括异常路径。比如测试支付时我会先故意不支付让它超时确认房态能正确释放再测试支付成功后取消订单看看积分会不会正确扣回。这些边界行为不亲手验证一遍上线后出了问题都没地方查。这套系统做完最大的感受是酒店预订系统的复杂度不在功能多而在状态流转和并发控制要闭环能把这套闭环跑通你就已经超过了绝大多数只会写CRUD的Spring Boot学习者。