酒店预订需求在Java后端项目里出现的频率非常高几乎每个学Spring Boot的人都会碰到也几乎是毕业设计和简历项目的常客。但会做和做得像样之间差得很远。你可能看过不少教程跟着敲完了却说不清登录鉴权为什么要用JWT、房态并发怎么控制、订单状态机怎么设计。这篇我就拿一个典型的基于Spring Boot的酒店预订系统含源码、数据库脚本和配套文档来做整体拆解把功能设计、技术选型、数据库关系、核心代码实现、部署步骤和排错经验都过一遍。适合正在做毕业设计的学生也适合想系统过一遍真实业务链路的开发者。这个系统麻雀虽小但用户-房间-订单-评论这条主链路覆盖了后端开发中大部分基础且关键的环节。1. 系统功能拆解与整体设计思路一个酒店预订系统核心是解决客人通过线上渠道完成选房、下单、支付、入住、退房这条完整的业务链路。但作为教学和课程设计项目它又必须带有明显的学习属性也就是要覆盖常见的后端知识点。1.1 角色边界与权限划分这个系统里至少有三类角色对应不同的操作边界客户前台用户浏览房源、按条件筛选房间、提交订单、模拟支付、查看自己的订单列表、发表评论。酒店前台/管理员管理房型信息、管理房间信息、处理订单确认、安排入住、办理退房、管理客户账号、查看统计信息。权限控制是这类系统的基础能力。我见过不少项目把所有操作都放在一个页面里没有区分角色这其实丧失了练习的意义。做得好的项目会在登录后把用户身份写进会话或令牌然后通过拦截器做访问控制管理员接口和普通用户接口严格分开。1.2 业务闭环与核心流程一个完整的预订流程大体是这样的客户注册登录进入首页浏览酒店房间列表。按日期、房型、价格区间筛选可订房间。选定入住和退房日期提交预订订单生成待支付订单。模拟支付成功后订单进入已确认状态。前台安排房间办理入住后订单变更为已入住。客户退房后订单完结之后可对本次住宿发表评论。这中间有个细节容易被忽略房间库存和日期冲突。酒店的库存不只是总量而是某时间段内是否有空房。同一个房间如果1号到3号被人占了那这期间就不能再被预订。所以订单表里必须记录入住时间和退房时间查询可用房间时要排除日期区间重叠的订单。1.3 单体架构为什么是这个场景的最优解在技术选型上这类课程设计项目几乎清一色选择单体架构Monolithic而不是微服务。原因很直接微服务的注册中心、配置中心、网关、服务间调用这些组件对教学项目来说成本过高而且没有业务体量支撑纯属为了用而用。单体架构部署简单一个jar包跑起来就是整个系统写文档和答辩演示都方便。单体架构在代码组织上并不妨碍模块化控制层、服务层、持久层只要按规范分层后面要拆微服务也有基础。Spring Boot在这个场景下是最合适的选择。它能快速跑通项目、内嵌Tomcat、自动配置各种组件大幅减少了繁琐的XML配置。相比传统的SSMSpring Spring MVC MyBatis项目Spring Boot把配置地狱压缩到了几行application.yml文件里。很多学校课程还在教SSH或SSM但真正到了做项目和面试阶段大概率还是要落到Spring Boot上。2. 核心技术栈选型与原因剖析技术栈的每一项选择都不是随意的它们共同影响着开发效率、学习覆盖面和后期维护成本。下面把各层选型拆开说清楚。2.1 后端框架Spring Boot 2.x与Java版本的选择Spring Boot目前主流稳定版本是2.7.x或3.x这两版的差别主要在JDK版本基线和底层依赖的Jakarta命名空间迁移上。做课程设计推荐用2.7.x配JDK8或JDK11理由如下JDK8仍然是很多学校机器和服务器上预装的版本兼容性最好。Spring Boot 2.x的生态资料极其丰富遇到问题基本都能搜到对应答案。3.x要求JDK17起步某些环境的maven编译器插件配置不当会踩坑对新手不友好。项目里用到的核心依赖也就那么几个spring-boot-starter-web网络层、spring-boot-starter-jdbc或mybatis-spring-boot-starter持久层、mysql-connector-java数据库驱动、lombok简化实体类代码、jjwt生成和校验令牌。2.2 持久层选型MyBatis还是JPA这是很多学习者纠结的地方。两类方案我都试过说下体感Spring Data JPA面向对象思维写实体类加注解就能自动建表、自动管理关联写复杂查询时用JPQL或方法名推导。优点是开发快缺点是一旦关联关系复杂SQL不可见调优困难新手容易写出慢查询。MyBatisSQL手写可见可控复杂多表查询非常直白。代价是每个Mapper接口都要配XML或注解样板代码多一些。MyBatis-Plus在MyBatis基础上做了增强单表CRUD不用写SQL内置分页插件还能配字段自动填充。可以说是课程设计项目的最优解既保留了SQL可控性又不至于写太多重复劳动。我在这个项目里用的是MyBatis-Plus最直接的好处是订单列表的翻页查询省了一大堆手工分页代码直接new Page然后调selectPage就结束。但如果你在校课程里学的是原生MyBatis想巩固SQL能力原生MyBatis也完全够用。2.3 前端方案不是所有场景都需要前后端分离后台管理这类项目前端方案有三个层次模板引擎渲染、Bootstrap jQuery半分离、Vue前后端完全分离。我个人的建议是纯课程设计级别尽量选择模板引擎加少量Ajax的方式。省去跨域处理和前端构建工具的配置成本。页面直接在服务端渲染用户登录信息塞进Session或Model里就能用。答辩和演示时跑一个后端项目就能出整个系统不必再单独npm install、起前端工程。Thymeleaf是Spring Boot官方推荐的模板引擎语法基于HTML标签属性像th:each、th:if这些学起来非常快。再加上Bootstrap的栅格和样式一个体面的后台界面半天就能拼出来。2.4 鉴权方案JWT还是HttpSession登录鉴权往往是面试中被追问最多的点。简单的项目可以只用Session但既然学了Spring Boot我更建议把JWTJSON Web Token这一套完整跑通。大致思路是用户登录成功后后端生成一个JWT令牌里面封装用户ID和用户名。前端拿到令牌后保存在本地存储中每次请求在请求头里携带Authorization: Bearer token。后端通过拦截器解析令牌把当前登录用户信息解析出来放进ThreadLocal或请求上下文。JWT方案相比Session最大的优势是服务端无状态适合后续扩展分布式场景。但要注意JWT无法主动失效用户改密码之后老Token依然有效。真正的企业项目里通常配合黑名单或Redis做二次校验课程设计到能在拦截器里解析Token这一层就足够了。3. 数据库设计表结构、字段含义与关系梳理酒店预订系统的表结构通常围绕人-房-单-评来建不同项目有细节差异但核心表逃不出这几个。3.1 核心表清单与字段设计用户表t_user用户ID、用户名、密码明文存储是禁忌至少用MD5加盐或BCrypt、手机号、邮箱、角色客户/管理员、创建时间。房型表t_room_type房型ID、房型名称、面积、床型、可住人数、单价、房型图片地址、描述。房间表t_room房间ID、所属房型ID、房间号、楼层、房间状态可用/打扫中/维修中。订单表t_order订单号、用户ID、房间ID、入住日期、退房日期、订单金额、状态待支付/已确认/已入住/已退房/已取消、下单时间、支付时间。评论表t_comment评论ID、订单ID、用户ID、评分、评论内容、回复内容、评论时间。这里有两个设计细节值得说第一订单表里存房间ID还是房型ID。很多新手直接存房型ID数量这是电商思维不是酒店思维。酒店预订的是具体房间在某时间段的占用权必须落到具体房间。当然也有的系统为了简化允许预订某个房型下任意一间那种场景要额外做库存计数。本系统走最常规路线订单关联具体房间。第二订单状态用数字枚举。数据库里不要存已确认这样的中文而用0、1、2、3这类数字表示在代码里用枚举常量映射。好处是排序方便、存储紧凑也不会因为改文案造成数据变更。3.2 各表之间的关联关系用户表和订单表是1对N一个用户可以有多个订单。房间表和房型表是N对1多个房间属于同一房型。订单表和房间表是N对1一个房间被多条不同时间段的订单引用。评论表和订单表是1对1。外键在课程设计里加不加我的建议是逻辑外键足够。也就是说在Java代码里维护关联而不是在数据库里定义物理外键约束。物理外键在删除和批量导入数据时会非常受限而且性能上有锁开销。很多生产环境压根不用物理外键靠应用层保证一致性。3.3 关键SQL场景判断哪些房间在某时间段可订这是整个数据库设计里最考验逻辑的部分。要判断一个房间在2025-06-01到2025-06-03之间是否空闲不能只看有没有订单要查出所有时间重叠的订单SELECT DISTINCT room_id FROM t_order WHERE status IN (1, 2, 3) -- 已确认、已入住、待支付等占用状态这里按实际状态值调整 AND check_in_date 2025-06-03 -- 已有订单的入住日期早于目标离店日期 AND check_out_date 2025-06-01 -- 已有订单的离店日期晚于目标入住日期这条SQL的核心逻辑就是两个时间区间是否有交集已有订单的入住时间 小于 目标的离店时间且已有订单的离店时间 大于 目标的入住时间。只要查出来这个房间在这两个条件下有记录就说明时间冲突不可订。很多新手会把它写成在某个日期当天是否被占结果跨天连续预订就判断错了这是很容易踩的坑。4. 核心业务模块实现要点与代码细节框架搭起来不难真正有含金量的是几个关键模块的实现细节。这里我挑四个容易做崩的环节重点讲。4.1 基于JWT的登录鉴权与拦截器配置登录接口本身没什么稀奇无非是查用户表比对密码。真正要注意的是令牌签发和后续请求的鉴权。签发JWT的代码大致长这样public String createToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器里要做两件事放行不需要鉴权的URL比如登录、注册、首页房间列表拦截其他URL并解析令牌。写拦截器时建议用HandlerInterceptor配合WebMvcConfigurer注册而不是全部塞进Filter里这样能直接在Spring MVC的上下文里拿到用户信息代码更干净。踩过的一个坑是跨域配置和拦截器顺序问题。特别是如果后面想改成前后端分离让前端从别的端口发请求必须先配置CORS再注册拦截器否则拦截器先处理了OPTIONS预检请求会导致前端报跨域错误。4.2 房间搜索与动态条件查询筛选功能在酒店系统里是高频操作。用户可能同时选入住日期、离店日期、房型、人数上限、价格范围。Search条件不定需要动态拼SQL。MyBatis里有两种拼法XML里的where标签或者MyBatis-Plus的LambdaQueryWrapper。前者SQL直观后者代码少。这个项目里我用的后者LambdaQueryWrapperRoom wrapper new LambdaQueryWrapper(); if (typeId ! null) { wrapper.eq(Room::getTypeId, typeId); } if (maxPrice ! null) { wrapper.le(Room::getPrice, maxPrice); } ListRoom rooms roomMapper.selectList(wrapper);但注意一个业务细节房间筛选不能只看房间本身的属性还要排除掉被当前时间段订单占用的房间。所以比较稳的处理方法是第一步查出目标时间段被占用的房间ID集合第二步查房间列表时加一个not in条件把被占的房间排除。4.3 订单状态机与并发锁房处理订单状态流转是系统的业务核心。我在数据库里用数字标识状态0待支付1已确认已支付2已入住3已退房完成4已取消正常流转路径是待支付→已确认→已入住→已退房。待支付订单超时可取消已确认订单在入住前也可取消并退款课程设计里就做逻辑退款即可。状态流转建议写在一个方法里每次变更校验当前状态是否合法。比如已入住只能由已确认转过来不能从待支付直接跳。这个校验逻辑放在Service层而不是在Controller里写一堆if。并发问题是这个项目最能体现水平的地方。场景是同一间房间两个用户同时下单各提交一次事务都把房间状态改成了已使用。如果没有锁机制超卖就发生了。最简单的方案是乐观锁在房间表加一个版本号字段更新时带上版本号条件UPDATE t_room SET status 0, version version 1 WHERE room_id #{roomId} AND version #{version}如果更新影响行数为0说明这个房间已经被其他事务改了本次下单判定为失败并提示用户重新选择。这个方案足够课程设计使用而且面试被问到并发问题时可以顺势展开说明自己理解乐观锁和悲观锁的取舍乐观锁适合读多写少场景冲突少时性能好悲观锁SELECT ... FOR UPDATE适合冲突率高的场景但是会锁表/锁行并发差。4.4 定时任务处理超时未支付订单用户提交订单后5分钟内不支付订单自动取消释放房间。不要靠用户下次刷新页面时才校验那样房间可能一直被占着。正确做法是用Spring自带的Scheduled定时任务扫表。类上标注EnableScheduling方法上标注Scheduled(fixedRate 60000)每分钟执行一次Scheduled(fixedRate 60000) public void cancelTimeoutOrders() { // 查询订单状态为0且创建时间早于5分钟前的订单 // 批量更新状态为4已取消并释放对应房间 }这个机制的细节在于不是随便把5分钟前创建的待支付订单取消要检查订单关联房间的状态如果用户提交了两个相同房间的订单其中一个已支付另一个待支付那么后者超时取消时不要释放房间因为房间还被已支付订单占着。所以释放房间前一定要再确认一下该房间当前没有其他有效订单。5. 工程结构与代码组织方式这部分讲清楚代码怎么分层文件放在哪个目录职责怎么切分这样拿到一套项目源码时不会一头雾水自己动手写的时候也有章法可循。5.1 标准分包结构一个规范的Spring Boot后端工程包结构建议这样com.example.hotel ├── controller # 接口层接收参数、返回结果 ├── service # 业务层处理业务逻辑、事务 │ └── impl # Service实现类 ├── mapper # MyBatis映射接口或MyBatis-Plus持久层接口 ├── entity # 数据库实体类 ├── dto # 前端交互用的数据传输对象 ├── vo # 视图对象 ├── config # 配置类拦截器、跨域、定时任务等 ├── interceptor # 拦截器定义 ├── common # 公共返回结果、状态枚举、全局异常处理 └── utils # JWT工具类、日期工具等有些同学喜欢在service包里直接把接口和实现类全放一块甚至只写类不写接口对于小项目来说这是可以接受的妥协。不过既然做完整系统我更建议按接口impl的结构来这样方便以后替换实现方式比如从MyBatis换JPA也符合Spring的依赖注入习惯。Controller层不要写任何业务逻辑只负责参数校验、调用Service、封装返回结果。5.2 统一返回结果与全局异常处理前后端交互的数据结构如果不统一前端处理每个接口都要单独判断非常乱。建议定义一个通用返回体Data public class ResultT { private Integer code; // 200成功500失败 private String message; private T data; }Controller里所有接口都返回Result。配合RestControllerAdvice全局异常处理器Service层只管抛业务异常由全局处理器统一捕获并包装成错误Result返回这样Controller代码会非常清爽。这个习惯越早养成越好我见过很多项目Controller里全是try-catch和Map拼装返回值代码又长又难维护对后续扩展也是负担。5.3 配置文件分层与环境切换开发环境和部署环境的数据库连接、日志级别往往不同。建议用Spring Boot的Profile机制配置文件拆成application.yml公共配置application-dev.yml开发环境配置本地数据库、日志debugapplication-prod.yml生产环境配置服务器数据库、日志info部署时启动命令加上--spring.profiles.activeprod即可切换。这个小操作如果没做很可能出现本地跑得好好的放到服务器上却连接了本地数据库地址导致连不上。使用Profile从源头上规避这个问题。6. 环境搭建、部署发布与启动验证拿到一套源码第一件事就是把它在本地跑起来。很多人项目跑不起来不是因为代码有问题而是环境细节没对上。这里说一套标准的起步流程。6.1 本地环境版本建议JDK版本8或11对应Spring Boot 2.7.xMaven3.6.x以上MySQL5.7或8.0开发工具IDEA社区版或旗舰版都行MySQL 8.0和5.7在驱动配置上有一点差别8.0的驱动类是com.mysql.cj.jdbc.DriverURL里建议加上serverTimezoneAsia/Shanghai参数不然连接时经常报时区错误。5.7的驱动类是com.mysql.jdbc.Driver不用带时区参数。6.2 初始化数据库项目通常会附带一个hotel.sql脚本包含建库、建表、插入初始数据。执行方式有两种命令行导入mysql -u root -p hotel.sqlNavicat里打开SQL文件直接执行执行完检查一下orders和t_room表里是否有初始数据房间至少要有十几条测试数据不然前端页面展示着会很空演示效果差很多。6.3 修改application.yml并启动数据库配置这块要自己核对不要直接抄示例spring: datasource: url: jdbc:mysql://localhost:3306/hotel_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver启动入口类是标注了SpringBootApplication的主类IDEA里右键Run即可。看到Tomcat started on port(s): 8080的字样就算启动成功。常见的一个问题是Tomcat端口被占用。Windows下用netstat -ano | findstr :8080查进程PID然后taskkill /F /PID 进程号解决或者直接改server.port换到8081。6.4 生产环境打包验证如果你要在Linux服务器上跑套路是固定的mvn clean package -DskipTests打包成功后在target目录下会生成hotel-0.0.1-SNAPSHOT.jar执行java -jar hotel-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod用nohup后台运行的话nohup java -jar hotel-0.0.1-SNAPSHOT.jar hotel.log 21 注意如果部署机器上的MySQL版本是小版本差异较大最好提前在服务器上测试下数据库连接否则应用启动时的数据源初始化就会失败。7. 常见问题与排查技巧实录这里把我在实际开发中遇到过的、以及帮别人排查项目时最常见的问题整理一下每个问题都附带排查路径。问题现象核心原因排查步骤应用启动报数据库连接失败数据库地址、账号、密码不对先在命令行里用同样账号密码连接MySQL验证检查服务是否在运行启动报端口占用8080端口被其他进程占用用netstat查占用进程后kill或改server.port查询中文乱码URL参数或数据库表字符集不是utf8改数据库连接URL加characterEncodingutf8检查表字符集出现Whitelabel Error PageController路由错误或服务异常看控制台完整异常栈排查空指针或SQL错误请求被拦截器拦截无法放行拦截器配置的放行路径写错核对excludePathPatterns的路径与实际请求路径是否一致注册用户密码是明文的密码未加密赶紧改BCrypt加密不要带坏头房间明明没被订却显示不可订时间区间查询逻辑写错用本文3.3节的交集SQL替换7.1 排查No qualifying bean of type错误这几乎是新手最容易遇到的问题。大概意思是某个Mapper接口或Service没有被Spring容器管理。排查思路检查启动类上是否有MapperScan(com.example.hotel.mapper)注解把Mapper包路径写对。检查Mapper接口上是否漏了Mapper注解如果没配MapperScan。检查Service实现类是否有Service注解。检查ServiceImpl是否实现了对应接口且方法签名完整。这个错误的根源通常就一句话Spring找不到这个Bean要么是扫描路径不对要么是缺少注解。7.2 数据库表字段命名映射问题Java实体类习惯用驼峰命名比如roomTypeId数据库字段习惯用下划线room_type_id。如果没有开启驼峰映射MyBatis查询结果是查不到对应属性的返回的对象全是null。解决办法有两个在Mapper的XML里显式给列起别名SELECT room_type_id AS roomTypeId FROM ...在application.yml里配置mybatis.configuration.map-underscore-to-camel-case: true推荐第二种全局生效省事且不容易忘。7.3 前端302跳转与Session失效问题用Thymeleaf模板时如果没有正确处理用户未登录的情况点击页面跳转经常会出现302重定向到登录页这是正常现象。但有个问题是如果前端通过Ajax调用需要登录的接口未登录时后端重定向返回的HTML会被当成普通请求处理前端看不到明确提示。处理方法在拦截器里判断请求头X-Requested-With: XMLHttpRequest如果是Ajax请求就返回JSON状态码401而不是重定向。8. 项目二次扩展的可选方向一套基础系统完成之后如果想让它更有竞争力比如放进作品集甚至作为实习项目可以考虑逐步叠加下面的模块按优先级排列。8.1 引入Redis做缓存和验证码酒店房间列表和房型信息是典型的读多写少数据可以缓存到Redis减少MySQL压力。登录验证码也可以存在Redis里并设置过期时间比存在Session里更规范。这一步对技术深度的提升立竿见影。8.2 对接云存储做房间图片现在的系统应该有房间图片上传的功能但本地存储图片放在服务器目录下部署时图片环境不一致。进一步可以对接对象存储服务如云存储Controller接收文件流后上传至云端数据库存访问URL。这个扩展对前端交互和后端文件处理都是很好的实战练习。8.3 引入消息推送或邮件通知订单确认、支付成功、入住提醒这些环节可以接入简单的邮件通知服务用JavaMailSender发送邮件让业务闭环更加真实。进一步地也可以加WebSocket做简易站内信提醒覆盖面又不一样了。这些扩展不用全做选一个做透比三个都是半吊子要强得多。面试聊项目时能把为什么用Redis缓存房型信息、缓存一致性怎么保证讲明白已经能赢过不少背框架的人。9. 配套文档该怎么写才加分很多同学做完代码就以为项目结束了其实配套文档的重要性不亚于代码本身。课程设计和作品集评审里文档的完整度往往直接决定印象分。一份合格的系统文档至少包含以下章节需求分析、系统设计、数据库设计、核心功能实现说明、系统测试、部署指南。每一个章节都要能回答具体问题。写文档有个技巧每个功能模块都配合截图并说明输入、处理、输出三要素。比如订单模块要写清楚输入是房间ID和日期区间处理的逻辑是怎么验证房间可用性、怎么计算金额、怎么锁定房间输出是订单号和支付入口。不要只写实现了订单功能这种废话真详细的内容才是文档的加分项。数据库设计部分建议附上E-R图配合每个表的字段说明表格。字段说明里除了字段名和类型还要标注是否为空、默认值是什么、字段含义是什么。截图和表格的排版如果都没问题这份文档的完成度已经超过大部分同类型项目了。10. 最后分享一点我做这类项目的个人体会做酒店预订系统这类经典管理型项目最容易犯的错是只顾着堆功能忽略了业务闭环。我见过太多项目把注册登录、房间列表、订单增删改查都做完了但整体跑一遍流程才发现问题前台用户下单了却不知道自己在哪个房间后台管理员无法把订单标记为入住用户想退房发现根本没有对应操作。功能全而无序演示起来非常尴尬。我的建议是拿到需求先画一张简单的状态流转图哪怕是在草稿纸上画把订单从创建到完结的每一跳都走通再开始写代码。状态梳理清楚了数据库字段设计和接口设计自然就顺了。另外开发过程中一定要养成看日志的习惯。Spring Boot的控制台输出信息量很大很多问题的答案就在异常栈里不要一出错就急着百度。先把日志从下往上读一遍往往问题原因已经写得很直白了。这个习惯越早养成后面的开发效率提升就越明显。这套系统的核心价值不在酒店这两个字上而在预订这两个字背后的一整套业务状态管理和资源冲突处理。把这条链路走通、想透你再去碰机票、会议室、剧本杀等任何带资源占用的业务都会觉得顺理成章。 
长河君 · 2026/10/10 18:49:11 · 阅读 1.2k Spring Boot酒店预订系统实战：从设计到部署全解析
酒店预订需求在Java后端项目里出现的频率非常高几乎每个学Spring Boot的人都会碰到也几乎是毕业设计和简历项目的常客。但会做和做得像样之间差得很远。你可能看过不少教程跟着敲完了却说不清登录鉴权为什么要用JWT、房态并发怎么控制、订单状态机怎么设计。这篇我就拿一个典型的基于Spring Boot的酒店预订系统含源码、数据库脚本和配套文档来做整体拆解把功能设计、技术选型、数据库关系、核心代码实现、部署步骤和排错经验都过一遍。适合正在做毕业设计的学生也适合想系统过一遍真实业务链路的开发者。这个系统麻雀虽小但用户-房间-订单-评论这条主链路覆盖了后端开发中大部分基础且关键的环节。1. 系统功能拆解与整体设计思路一个酒店预订系统核心是解决客人通过线上渠道完成选房、下单、支付、入住、退房这条完整的业务链路。但作为教学和课程设计项目它又必须带有明显的学习属性也就是要覆盖常见的后端知识点。1.1 角色边界与权限划分这个系统里至少有三类角色对应不同的操作边界客户前台用户浏览房源、按条件筛选房间、提交订单、模拟支付、查看自己的订单列表、发表评论。酒店前台/管理员管理房型信息、管理房间信息、处理订单确认、安排入住、办理退房、管理客户账号、查看统计信息。权限控制是这类系统的基础能力。我见过不少项目把所有操作都放在一个页面里没有区分角色这其实丧失了练习的意义。做得好的项目会在登录后把用户身份写进会话或令牌然后通过拦截器做访问控制管理员接口和普通用户接口严格分开。1.2 业务闭环与核心流程一个完整的预订流程大体是这样的客户注册登录进入首页浏览酒店房间列表。按日期、房型、价格区间筛选可订房间。选定入住和退房日期提交预订订单生成待支付订单。模拟支付成功后订单进入已确认状态。前台安排房间办理入住后订单变更为已入住。客户退房后订单完结之后可对本次住宿发表评论。这中间有个细节容易被忽略房间库存和日期冲突。酒店的库存不只是总量而是某时间段内是否有空房。同一个房间如果1号到3号被人占了那这期间就不能再被预订。所以订单表里必须记录入住时间和退房时间查询可用房间时要排除日期区间重叠的订单。1.3 单体架构为什么是这个场景的最优解在技术选型上这类课程设计项目几乎清一色选择单体架构Monolithic而不是微服务。原因很直接微服务的注册中心、配置中心、网关、服务间调用这些组件对教学项目来说成本过高而且没有业务体量支撑纯属为了用而用。单体架构部署简单一个jar包跑起来就是整个系统写文档和答辩演示都方便。单体架构在代码组织上并不妨碍模块化控制层、服务层、持久层只要按规范分层后面要拆微服务也有基础。Spring Boot在这个场景下是最合适的选择。它能快速跑通项目、内嵌Tomcat、自动配置各种组件大幅减少了繁琐的XML配置。相比传统的SSMSpring Spring MVC MyBatis项目Spring Boot把配置地狱压缩到了几行application.yml文件里。很多学校课程还在教SSH或SSM但真正到了做项目和面试阶段大概率还是要落到Spring Boot上。2. 核心技术栈选型与原因剖析技术栈的每一项选择都不是随意的它们共同影响着开发效率、学习覆盖面和后期维护成本。下面把各层选型拆开说清楚。2.1 后端框架Spring Boot 2.x与Java版本的选择Spring Boot目前主流稳定版本是2.7.x或3.x这两版的差别主要在JDK版本基线和底层依赖的Jakarta命名空间迁移上。做课程设计推荐用2.7.x配JDK8或JDK11理由如下JDK8仍然是很多学校机器和服务器上预装的版本兼容性最好。Spring Boot 2.x的生态资料极其丰富遇到问题基本都能搜到对应答案。3.x要求JDK17起步某些环境的maven编译器插件配置不当会踩坑对新手不友好。项目里用到的核心依赖也就那么几个spring-boot-starter-web网络层、spring-boot-starter-jdbc或mybatis-spring-boot-starter持久层、mysql-connector-java数据库驱动、lombok简化实体类代码、jjwt生成和校验令牌。2.2 持久层选型MyBatis还是JPA这是很多学习者纠结的地方。两类方案我都试过说下体感Spring Data JPA面向对象思维写实体类加注解就能自动建表、自动管理关联写复杂查询时用JPQL或方法名推导。优点是开发快缺点是一旦关联关系复杂SQL不可见调优困难新手容易写出慢查询。MyBatisSQL手写可见可控复杂多表查询非常直白。代价是每个Mapper接口都要配XML或注解样板代码多一些。MyBatis-Plus在MyBatis基础上做了增强单表CRUD不用写SQL内置分页插件还能配字段自动填充。可以说是课程设计项目的最优解既保留了SQL可控性又不至于写太多重复劳动。我在这个项目里用的是MyBatis-Plus最直接的好处是订单列表的翻页查询省了一大堆手工分页代码直接new Page然后调selectPage就结束。但如果你在校课程里学的是原生MyBatis想巩固SQL能力原生MyBatis也完全够用。2.3 前端方案不是所有场景都需要前后端分离后台管理这类项目前端方案有三个层次模板引擎渲染、Bootstrap jQuery半分离、Vue前后端完全分离。我个人的建议是纯课程设计级别尽量选择模板引擎加少量Ajax的方式。省去跨域处理和前端构建工具的配置成本。页面直接在服务端渲染用户登录信息塞进Session或Model里就能用。答辩和演示时跑一个后端项目就能出整个系统不必再单独npm install、起前端工程。Thymeleaf是Spring Boot官方推荐的模板引擎语法基于HTML标签属性像th:each、th:if这些学起来非常快。再加上Bootstrap的栅格和样式一个体面的后台界面半天就能拼出来。2.4 鉴权方案JWT还是HttpSession登录鉴权往往是面试中被追问最多的点。简单的项目可以只用Session但既然学了Spring Boot我更建议把JWTJSON Web Token这一套完整跑通。大致思路是用户登录成功后后端生成一个JWT令牌里面封装用户ID和用户名。前端拿到令牌后保存在本地存储中每次请求在请求头里携带Authorization: Bearer token。后端通过拦截器解析令牌把当前登录用户信息解析出来放进ThreadLocal或请求上下文。JWT方案相比Session最大的优势是服务端无状态适合后续扩展分布式场景。但要注意JWT无法主动失效用户改密码之后老Token依然有效。真正的企业项目里通常配合黑名单或Redis做二次校验课程设计到能在拦截器里解析Token这一层就足够了。3. 数据库设计表结构、字段含义与关系梳理酒店预订系统的表结构通常围绕人-房-单-评来建不同项目有细节差异但核心表逃不出这几个。3.1 核心表清单与字段设计用户表t_user用户ID、用户名、密码明文存储是禁忌至少用MD5加盐或BCrypt、手机号、邮箱、角色客户/管理员、创建时间。房型表t_room_type房型ID、房型名称、面积、床型、可住人数、单价、房型图片地址、描述。房间表t_room房间ID、所属房型ID、房间号、楼层、房间状态可用/打扫中/维修中。订单表t_order订单号、用户ID、房间ID、入住日期、退房日期、订单金额、状态待支付/已确认/已入住/已退房/已取消、下单时间、支付时间。评论表t_comment评论ID、订单ID、用户ID、评分、评论内容、回复内容、评论时间。这里有两个设计细节值得说第一订单表里存房间ID还是房型ID。很多新手直接存房型ID数量这是电商思维不是酒店思维。酒店预订的是具体房间在某时间段的占用权必须落到具体房间。当然也有的系统为了简化允许预订某个房型下任意一间那种场景要额外做库存计数。本系统走最常规路线订单关联具体房间。第二订单状态用数字枚举。数据库里不要存已确认这样的中文而用0、1、2、3这类数字表示在代码里用枚举常量映射。好处是排序方便、存储紧凑也不会因为改文案造成数据变更。3.2 各表之间的关联关系用户表和订单表是1对N一个用户可以有多个订单。房间表和房型表是N对1多个房间属于同一房型。订单表和房间表是N对1一个房间被多条不同时间段的订单引用。评论表和订单表是1对1。外键在课程设计里加不加我的建议是逻辑外键足够。也就是说在Java代码里维护关联而不是在数据库里定义物理外键约束。物理外键在删除和批量导入数据时会非常受限而且性能上有锁开销。很多生产环境压根不用物理外键靠应用层保证一致性。3.3 关键SQL场景判断哪些房间在某时间段可订这是整个数据库设计里最考验逻辑的部分。要判断一个房间在2025-06-01到2025-06-03之间是否空闲不能只看有没有订单要查出所有时间重叠的订单SELECT DISTINCT room_id FROM t_order WHERE status IN (1, 2, 3) -- 已确认、已入住、待支付等占用状态这里按实际状态值调整 AND check_in_date 2025-06-03 -- 已有订单的入住日期早于目标离店日期 AND check_out_date 2025-06-01 -- 已有订单的离店日期晚于目标入住日期这条SQL的核心逻辑就是两个时间区间是否有交集已有订单的入住时间 小于 目标的离店时间且已有订单的离店时间 大于 目标的入住时间。只要查出来这个房间在这两个条件下有记录就说明时间冲突不可订。很多新手会把它写成在某个日期当天是否被占结果跨天连续预订就判断错了这是很容易踩的坑。4. 核心业务模块实现要点与代码细节框架搭起来不难真正有含金量的是几个关键模块的实现细节。这里我挑四个容易做崩的环节重点讲。4.1 基于JWT的登录鉴权与拦截器配置登录接口本身没什么稀奇无非是查用户表比对密码。真正要注意的是令牌签发和后续请求的鉴权。签发JWT的代码大致长这样public String createToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器里要做两件事放行不需要鉴权的URL比如登录、注册、首页房间列表拦截其他URL并解析令牌。写拦截器时建议用HandlerInterceptor配合WebMvcConfigurer注册而不是全部塞进Filter里这样能直接在Spring MVC的上下文里拿到用户信息代码更干净。踩过的一个坑是跨域配置和拦截器顺序问题。特别是如果后面想改成前后端分离让前端从别的端口发请求必须先配置CORS再注册拦截器否则拦截器先处理了OPTIONS预检请求会导致前端报跨域错误。4.2 房间搜索与动态条件查询筛选功能在酒店系统里是高频操作。用户可能同时选入住日期、离店日期、房型、人数上限、价格范围。Search条件不定需要动态拼SQL。MyBatis里有两种拼法XML里的where标签或者MyBatis-Plus的LambdaQueryWrapper。前者SQL直观后者代码少。这个项目里我用的后者LambdaQueryWrapperRoom wrapper new LambdaQueryWrapper(); if (typeId ! null) { wrapper.eq(Room::getTypeId, typeId); } if (maxPrice ! null) { wrapper.le(Room::getPrice, maxPrice); } ListRoom rooms roomMapper.selectList(wrapper);但注意一个业务细节房间筛选不能只看房间本身的属性还要排除掉被当前时间段订单占用的房间。所以比较稳的处理方法是第一步查出目标时间段被占用的房间ID集合第二步查房间列表时加一个not in条件把被占的房间排除。4.3 订单状态机与并发锁房处理订单状态流转是系统的业务核心。我在数据库里用数字标识状态0待支付1已确认已支付2已入住3已退房完成4已取消正常流转路径是待支付→已确认→已入住→已退房。待支付订单超时可取消已确认订单在入住前也可取消并退款课程设计里就做逻辑退款即可。状态流转建议写在一个方法里每次变更校验当前状态是否合法。比如已入住只能由已确认转过来不能从待支付直接跳。这个校验逻辑放在Service层而不是在Controller里写一堆if。并发问题是这个项目最能体现水平的地方。场景是同一间房间两个用户同时下单各提交一次事务都把房间状态改成了已使用。如果没有锁机制超卖就发生了。最简单的方案是乐观锁在房间表加一个版本号字段更新时带上版本号条件UPDATE t_room SET status 0, version version 1 WHERE room_id #{roomId} AND version #{version}如果更新影响行数为0说明这个房间已经被其他事务改了本次下单判定为失败并提示用户重新选择。这个方案足够课程设计使用而且面试被问到并发问题时可以顺势展开说明自己理解乐观锁和悲观锁的取舍乐观锁适合读多写少场景冲突少时性能好悲观锁SELECT ... FOR UPDATE适合冲突率高的场景但是会锁表/锁行并发差。4.4 定时任务处理超时未支付订单用户提交订单后5分钟内不支付订单自动取消释放房间。不要靠用户下次刷新页面时才校验那样房间可能一直被占着。正确做法是用Spring自带的Scheduled定时任务扫表。类上标注EnableScheduling方法上标注Scheduled(fixedRate 60000)每分钟执行一次Scheduled(fixedRate 60000) public void cancelTimeoutOrders() { // 查询订单状态为0且创建时间早于5分钟前的订单 // 批量更新状态为4已取消并释放对应房间 }这个机制的细节在于不是随便把5分钟前创建的待支付订单取消要检查订单关联房间的状态如果用户提交了两个相同房间的订单其中一个已支付另一个待支付那么后者超时取消时不要释放房间因为房间还被已支付订单占着。所以释放房间前一定要再确认一下该房间当前没有其他有效订单。5. 工程结构与代码组织方式这部分讲清楚代码怎么分层文件放在哪个目录职责怎么切分这样拿到一套项目源码时不会一头雾水自己动手写的时候也有章法可循。5.1 标准分包结构一个规范的Spring Boot后端工程包结构建议这样com.example.hotel ├── controller # 接口层接收参数、返回结果 ├── service # 业务层处理业务逻辑、事务 │ └── impl # Service实现类 ├── mapper # MyBatis映射接口或MyBatis-Plus持久层接口 ├── entity # 数据库实体类 ├── dto # 前端交互用的数据传输对象 ├── vo # 视图对象 ├── config # 配置类拦截器、跨域、定时任务等 ├── interceptor # 拦截器定义 ├── common # 公共返回结果、状态枚举、全局异常处理 └── utils # JWT工具类、日期工具等有些同学喜欢在service包里直接把接口和实现类全放一块甚至只写类不写接口对于小项目来说这是可以接受的妥协。不过既然做完整系统我更建议按接口impl的结构来这样方便以后替换实现方式比如从MyBatis换JPA也符合Spring的依赖注入习惯。Controller层不要写任何业务逻辑只负责参数校验、调用Service、封装返回结果。5.2 统一返回结果与全局异常处理前后端交互的数据结构如果不统一前端处理每个接口都要单独判断非常乱。建议定义一个通用返回体Data public class ResultT { private Integer code; // 200成功500失败 private String message; private T data; }Controller里所有接口都返回Result。配合RestControllerAdvice全局异常处理器Service层只管抛业务异常由全局处理器统一捕获并包装成错误Result返回这样Controller代码会非常清爽。这个习惯越早养成越好我见过很多项目Controller里全是try-catch和Map拼装返回值代码又长又难维护对后续扩展也是负担。5.3 配置文件分层与环境切换开发环境和部署环境的数据库连接、日志级别往往不同。建议用Spring Boot的Profile机制配置文件拆成application.yml公共配置application-dev.yml开发环境配置本地数据库、日志debugapplication-prod.yml生产环境配置服务器数据库、日志info部署时启动命令加上--spring.profiles.activeprod即可切换。这个小操作如果没做很可能出现本地跑得好好的放到服务器上却连接了本地数据库地址导致连不上。使用Profile从源头上规避这个问题。6. 环境搭建、部署发布与启动验证拿到一套源码第一件事就是把它在本地跑起来。很多人项目跑不起来不是因为代码有问题而是环境细节没对上。这里说一套标准的起步流程。6.1 本地环境版本建议JDK版本8或11对应Spring Boot 2.7.xMaven3.6.x以上MySQL5.7或8.0开发工具IDEA社区版或旗舰版都行MySQL 8.0和5.7在驱动配置上有一点差别8.0的驱动类是com.mysql.cj.jdbc.DriverURL里建议加上serverTimezoneAsia/Shanghai参数不然连接时经常报时区错误。5.7的驱动类是com.mysql.jdbc.Driver不用带时区参数。6.2 初始化数据库项目通常会附带一个hotel.sql脚本包含建库、建表、插入初始数据。执行方式有两种命令行导入mysql -u root -p hotel.sqlNavicat里打开SQL文件直接执行执行完检查一下orders和t_room表里是否有初始数据房间至少要有十几条测试数据不然前端页面展示着会很空演示效果差很多。6.3 修改application.yml并启动数据库配置这块要自己核对不要直接抄示例spring: datasource: url: jdbc:mysql://localhost:3306/hotel_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver启动入口类是标注了SpringBootApplication的主类IDEA里右键Run即可。看到Tomcat started on port(s): 8080的字样就算启动成功。常见的一个问题是Tomcat端口被占用。Windows下用netstat -ano | findstr :8080查进程PID然后taskkill /F /PID 进程号解决或者直接改server.port换到8081。6.4 生产环境打包验证如果你要在Linux服务器上跑套路是固定的mvn clean package -DskipTests打包成功后在target目录下会生成hotel-0.0.1-SNAPSHOT.jar执行java -jar hotel-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod用nohup后台运行的话nohup java -jar hotel-0.0.1-SNAPSHOT.jar hotel.log 21 注意如果部署机器上的MySQL版本是小版本差异较大最好提前在服务器上测试下数据库连接否则应用启动时的数据源初始化就会失败。7. 常见问题与排查技巧实录这里把我在实际开发中遇到过的、以及帮别人排查项目时最常见的问题整理一下每个问题都附带排查路径。问题现象核心原因排查步骤应用启动报数据库连接失败数据库地址、账号、密码不对先在命令行里用同样账号密码连接MySQL验证检查服务是否在运行启动报端口占用8080端口被其他进程占用用netstat查占用进程后kill或改server.port查询中文乱码URL参数或数据库表字符集不是utf8改数据库连接URL加characterEncodingutf8检查表字符集出现Whitelabel Error PageController路由错误或服务异常看控制台完整异常栈排查空指针或SQL错误请求被拦截器拦截无法放行拦截器配置的放行路径写错核对excludePathPatterns的路径与实际请求路径是否一致注册用户密码是明文的密码未加密赶紧改BCrypt加密不要带坏头房间明明没被订却显示不可订时间区间查询逻辑写错用本文3.3节的交集SQL替换7.1 排查No qualifying bean of type错误这几乎是新手最容易遇到的问题。大概意思是某个Mapper接口或Service没有被Spring容器管理。排查思路检查启动类上是否有MapperScan(com.example.hotel.mapper)注解把Mapper包路径写对。检查Mapper接口上是否漏了Mapper注解如果没配MapperScan。检查Service实现类是否有Service注解。检查ServiceImpl是否实现了对应接口且方法签名完整。这个错误的根源通常就一句话Spring找不到这个Bean要么是扫描路径不对要么是缺少注解。7.2 数据库表字段命名映射问题Java实体类习惯用驼峰命名比如roomTypeId数据库字段习惯用下划线room_type_id。如果没有开启驼峰映射MyBatis查询结果是查不到对应属性的返回的对象全是null。解决办法有两个在Mapper的XML里显式给列起别名SELECT room_type_id AS roomTypeId FROM ...在application.yml里配置mybatis.configuration.map-underscore-to-camel-case: true推荐第二种全局生效省事且不容易忘。7.3 前端302跳转与Session失效问题用Thymeleaf模板时如果没有正确处理用户未登录的情况点击页面跳转经常会出现302重定向到登录页这是正常现象。但有个问题是如果前端通过Ajax调用需要登录的接口未登录时后端重定向返回的HTML会被当成普通请求处理前端看不到明确提示。处理方法在拦截器里判断请求头X-Requested-With: XMLHttpRequest如果是Ajax请求就返回JSON状态码401而不是重定向。8. 项目二次扩展的可选方向一套基础系统完成之后如果想让它更有竞争力比如放进作品集甚至作为实习项目可以考虑逐步叠加下面的模块按优先级排列。8.1 引入Redis做缓存和验证码酒店房间列表和房型信息是典型的读多写少数据可以缓存到Redis减少MySQL压力。登录验证码也可以存在Redis里并设置过期时间比存在Session里更规范。这一步对技术深度的提升立竿见影。8.2 对接云存储做房间图片现在的系统应该有房间图片上传的功能但本地存储图片放在服务器目录下部署时图片环境不一致。进一步可以对接对象存储服务如云存储Controller接收文件流后上传至云端数据库存访问URL。这个扩展对前端交互和后端文件处理都是很好的实战练习。8.3 引入消息推送或邮件通知订单确认、支付成功、入住提醒这些环节可以接入简单的邮件通知服务用JavaMailSender发送邮件让业务闭环更加真实。进一步地也可以加WebSocket做简易站内信提醒覆盖面又不一样了。这些扩展不用全做选一个做透比三个都是半吊子要强得多。面试聊项目时能把为什么用Redis缓存房型信息、缓存一致性怎么保证讲明白已经能赢过不少背框架的人。9. 配套文档该怎么写才加分很多同学做完代码就以为项目结束了其实配套文档的重要性不亚于代码本身。课程设计和作品集评审里文档的完整度往往直接决定印象分。一份合格的系统文档至少包含以下章节需求分析、系统设计、数据库设计、核心功能实现说明、系统测试、部署指南。每一个章节都要能回答具体问题。写文档有个技巧每个功能模块都配合截图并说明输入、处理、输出三要素。比如订单模块要写清楚输入是房间ID和日期区间处理的逻辑是怎么验证房间可用性、怎么计算金额、怎么锁定房间输出是订单号和支付入口。不要只写实现了订单功能这种废话真详细的内容才是文档的加分项。数据库设计部分建议附上E-R图配合每个表的字段说明表格。字段说明里除了字段名和类型还要标注是否为空、默认值是什么、字段含义是什么。截图和表格的排版如果都没问题这份文档的完成度已经超过大部分同类型项目了。10. 最后分享一点我做这类项目的个人体会做酒店预订系统这类经典管理型项目最容易犯的错是只顾着堆功能忽略了业务闭环。我见过太多项目把注册登录、房间列表、订单增删改查都做完了但整体跑一遍流程才发现问题前台用户下单了却不知道自己在哪个房间后台管理员无法把订单标记为入住用户想退房发现根本没有对应操作。功能全而无序演示起来非常尴尬。我的建议是拿到需求先画一张简单的状态流转图哪怕是在草稿纸上画把订单从创建到完结的每一跳都走通再开始写代码。状态梳理清楚了数据库字段设计和接口设计自然就顺了。另外开发过程中一定要养成看日志的习惯。Spring Boot的控制台输出信息量很大很多问题的答案就在异常栈里不要一出错就急着百度。先把日志从下往上读一遍往往问题原因已经写得很直白了。这个习惯越早养成后面的开发效率提升就越明显。这套系统的核心价值不在酒店这两个字上而在预订这两个字背后的一整套业务状态管理和资源冲突处理。把这条链路走通、想透你再去碰机票、会议室、剧本杀等任何带资源占用的业务都会觉得顺理成章。