先说结论如果你打算做一套能放到简历里、能通过毕业答辩、又能把 SpringBoot Vue 这套前后端分离开发流程真正跑通的项目酒店管理系统是一个非常经典的选题。它不像电商系统那样业务链路冗长也不像纯 CRUD 的后台管理系统那样缺乏亮点它的业务模型刚好卡在“有真实复杂度”和“一个人能完成”之间客房状态流转、预订与入住、账单结算这几个核心场景既能展示你对表结构的设计能力也能体现前后端联调的工程意识。这篇博文我不会把完整源码贴出来再讲一遍而是分享我在开发这套系统时的完整思路为什么这样设计数据库、为什么后端要分那么多层、前端页面哪些地方最容易翻车、打包部署时又有哪些坑等着你。无论你现在是刚开始写第一个 Java Web 项目还是已经在开发中段、正被各种异常折磨这篇文章都值得你从头看一遍。1. 选型拆解不是所有技术栈都适合作为独立开发者完成的项目1.1 为什么是 SpringBoot Vue而不是 JSP 或前后端不分离方案很多学生在选题时纠结过学校教的是 JSP Servlet网上教程都是 SpringBoot Vue到底选哪个我的建议很直接如果你时间充足跟着主流走也就是 SpringBoot Vue。这套组合代表着当前企业里最常见的开发形态之一你把它做完之后前端、后端、数据库之间是怎么协作的心里会有一个完整的框架。而 JSP 方案当然也能实现但它让你陷入“页面和后端代码纠缠”的模型里这种模型现在企业里已经很少用了。你不需要在这套系统里追求微服务、Redis、MQ 这类重组件那是过度设计。一套单体 SpringBoot 应用内部按 Controller - Service - Mapper 分好层前端用 Vue 组织单页应用就足够撑起一个酒店管理系统的完整业务闭环。技术栈选得太重你反而会被环境问题拖死。1.2 Vue 2 还是 Vue 3Element UI 还是 Element Plus这个选择题几乎所有做毕设的人都遇到过。我的看法是如果项目从现在开始写优先 Vue 3 Element Plus。原因不是所谓“新版本更先进”而是 Vue 3 的组合式 API 写起来更利落Element Plus 的组件对表单校验、表格、弹窗这类管理后台场景覆盖得很完整。但如果你对 Vue 2 的选项式 API 更熟悉、看过的教程大多是 Vue 2 的内容那用 Vue 2 Element UI 也完全没问题系统该有的功能都能实现。真正要警惕的是版本混搭。比如 Node 版本太高导致 Vue CLI 创建项目失败或者 npm 安装依赖时网络超时这些环境问题消耗的时间往往比写代码还多。一个可行的做法是固定 Node 16 或 18 的 LTS 版本搭配 Vue CLI 5这套组合比较稳定。如果要用 Vite注意 Node 版本不能太低否则直接白屏启动不起来。提示一定要先确认环境再写业务代码。很多人一上来先敲代码敲到第三天项目跑不起来才发现是 Node 版本和 Vue CLI 不兼容整个项目的节奏全被打乱了。1.3 业务模块的功能边界做到什么程度才算“完整系统”酒店管理系统听起来简单但它的功能边界其实需要认真划线。太少了显得单薄太多了做不完。我的做法是划分成五个核心模块系统管理管理员登录、修改密码、管理员信息维护客房管理房型设置、房间信息维护、房间状态查询预订管理客人预订、取消预订、预订记录查询入住与退房入住登记、退房结算、在住列表数据统计今日入住、今日退房、近几日营收情况的简单统计这五个模块已经能让系统形成业务闭环。千万不要再加什么“积分商城”“员工考勤”项目一变大代码质量反而下降答辩时也容易被问倒。2. 数据库表结构设计先想清楚关系再动手建库2.1 核心表拆分与字段设计我曾经见过有人把房间信息、预订信息、入住信息全部塞进一张表里表面上看起来操作简单实际上后面每次查询都要带一堆条件状态一变就出错。酒店管理系统的表结构至少要拆出这几张表管理员表、房型表、客房表、会员表可选、预订表、入住登记表、账单表。以客房表和预订表为例客房表里记录房间编号、房型 ID、楼层、房间状态预订表里记录预订人姓名、电话、房型 ID、预期入住日期、预期离店日期、预订状态。这里有一个容易被忽略的设计细节不要直接在预订表里写死某个房间的 ID。预订时应该先锁定房型办理入住时才真正分配具体房间。这样设计的原因是预订阶段如果和具体房间绑定酒店经理手动调整房间时会非常痛苦而且取消预订时状态恢复也很麻烦。2.2 房间状态的设计一个状态字段引发的连锁反应客房表里最重要的字段就是状态。我设计了四种状态可售、已预订、已入住、打扫中。这个字段在设计上看起来简单实际业务里却是最容易出问题的地方。举个例子当用户在前台预订一个房间如果系统只把房间状态改成“已预订”那么前台办理入住时系统就必须判断这个房间是否真的已经被预订且未被他人登记。如果状态是“打扫中”需要先允许保洁人员更新为“可售”否则房间就永远没法销售。因此我建议状态管理要做成一张小的状态流转表或者用前端字典统一管理不要散落在各个接口里用魔法数字硬编码。我实际用的方案是在数据库里状态用整数存储前端通过自定义字典渲染成中文。比如 0 代表可售1 代表已预订2 代表已入住3 代表打扫中。这样前后端都不容易被硬编码字符串搞乱。2.3 防重复预订的 SQL 判断逻辑这是这个系统里最值得写在简历上的一个小亮点。为了实现“同一房型在同一个日期区间内不能被重复预订”我在查询可用房间时用了一条 SQL 来排除“已经有重叠预订的房型”SELECT * FROM room WHERE room_type_id #{typeId} AND room_status 0 AND id NOT IN ( SELECT room_id FROM reservation WHERE status 1 AND #{checkInDate} expected_check_out_date AND #{checkOutDate} expected_check_in_date )这段逻辑的核心思想是只要新预订的入住日期早于已有订单的离店日期且新预订的离店日期晚于已有订单的入住日期就说明两个订单在时间上存在重叠。这个区间重叠判断比搜一堆“大于等于、小于等于”条件要清晰得多也不容易漏边界。3. 后端工程结构从一个控制器方法看整套分层思想3.1 标准项目结构一个清晰的后端项目结构长这样com.hotel.management ├── controller ├── service │ └── impl ├── mapper ├── entity ├── dto ├── config ├── common │ ├── result │ └── exception └── utilController 层只负责接收参数和返回结果Service 层负责业务逻辑Mapper 层负责数据库操作。entity 对应数据库表结构dto 用来接收前端传来的参数对象。有一些人可能会把 dto 和 entity 混着用这在单体小项目里问题不大但一旦字段开始变化比如前端需要额外传一个确认密码字段entity 里就会出现一个不存在的列名MyBatis 的自动映射就会一头雾水。3.2 返回结果统一封装我强烈建议你从第一天开始就统一接口返回格式否则前后端联调时会痛苦到怀疑人生。我做了一个 Result 类来封装返回结构public class ResultT { private Integer code; // 200 成功500 失败 private String message; private T data; }所有控制器的返回类型都是 Result 前端 axios 拦截器统一处理 code。这样写的最大好处是异常时也能返回结构一致的数据前端不用在每个请求里做不同的异常处理。3.3 登录鉴权的实现链路登录鉴权我用的是 JWT 拦截器的方式。流程大致是用户提交用户名密码后端校验通过后生成一个 token返回给前端前端在后续的每个请求头里带上 Token后端用一个拦截器统一校验 Token没有 Token 就直接返回 401。注意两个细节。第一密码不能明文存放。教学项目用 MD5 加密也说得通但如果你想在简历里写得好听一点直接用 Spring Security 的 BCryptPasswordEncoder成本很低查一下文档就会用。第二拦截器拦截路径一定要设计好登录接口、静态资源这些路径必须放行否则你写好的登录页一提交就跳到 401半天找不到原因。密码加密和 token 生成这两块可以单独封装成工具类这样 Controller 里的代码会非常干净。3.4 一个预订接口的完整实现思路以“提交预订”为例看一个后端接口的标准流程。Controller 接收前端传来的 dto 对象其中包含联系人姓名、电话、房型 ID、入住时间、离店时间。Service 层要依次做这些事校验房型是否存在、是否可用查询该房型在这个时间段内是否有重叠的预订计算预计总金额房型单价乘以天数生成预订单号可以用时间戳加随机数插入预订记录每一步都对应一段独立的代码逻辑。这样的好处是任何一个环节出了问题都可以单独测试。比如我写完“查询重叠预订”的方法后先在数据库里手工插了几条边界数据再调用这个方法验证结果确认无误后才继续写后面的逻辑。4. 前端 Vue 项目页面组织、请求封装和最容易出错的联调细节4.1 项目目录与路由设计前端目录我按页面功能划分成 view 组件、router 路由、api 接口、utils 工具四个部分。路由用了嵌套路由登录后进入 Layout 主框架主框架里再嵌套各个功能页面。{ path: /hotel, component: Layout, redirect: /hotel/room, children: [ { path: room, component: () import(/views/hotel/room.vue), meta: { title: 客房管理 } }, { path: reservation, component: () import(/views/hotel/reservation.vue), meta: { title: 预订管理 } } ] }路由懒加载是用 import 函数导入组件这样首屏加载会快一些。meta 里的 title 字段可以配合面包屑组件使用后端管理系统的体验会显得更完整。4.2 Axios 请求封装与代理配置Axios 封装时我会统一设置 baseURL并在请求拦截器里添加 token 头在响应拦截器里统一处理 401、500 等状态码。比如 401 直接跳到登录页500 弹一个错误提示这是管理后台的通用做法。跨域问题是在开发阶段最常遇到的坎。我在 vue.config.js 里配置 devServer 代理把 /api 开头的请求转发到后端的 8080 端口前端的本地开发服务器跑在 8081 端口这样浏览器里就没有跨域问题了。devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }写完这个配置后前端请求地址里直接写/api/hotel/room/list就能打到后端。这里容易犯错的地方是请求路径带上了 /api后端的 Controller 映射里也写了 /api导致重复前缀。我习惯后端统一用 /api 开头前端代理时不重写路径这样最省心。实际中很多同学前端和后端前缀对不上联调时所有请求都 404问题就出在这个细微的地方。4.3 联调阶段的三个高频问题后端返回的日期格式是时间戳前端直接显示会变成一串数字。我在后端统一配置了 Jackson 的日期格式输出为 yyyy-MM-dd并用 JsonFormat 注解给日期字段做了格式化。前端表格里的操作列比如“入住”“退房”按钮需要根据当前行的状态动态控制。这个用 el-table 的列插槽很方便但要注意状态更新之后必须重新刷新列表数据否则界面上的状态不变造成“明明操作成功但页面没反应”的错觉。下拉框绑定的是房型 ID回显时需要先从后端带回整个房型列表再做映射。很多人漏掉这一步导致编辑时下拉框显示的是数字 ID 而不是中文房型名。5. 实战踩坑记录开发过程中耗掉我最多时间的五个问题5.1 环境问题Java、Node、MySQL 版本不匹配引发的连锁反应有一段时间我项目一直启动失败控制台报的错是 MySQL 驱动的时区问题具体错误是Server returns invalid timezone。这是因为 MySQL 8.0 的驱动对时区敏感。解决办法是在数据库连接串里加serverTimezoneAsia/Shanghai或者直接在 MySQL 配置里设置全局时区。还有一次是 Node 版本太高导致 npm install 的时候 node-sass 编译失败。node-sass 这个库对 Node 版本非常挑剔后来我把项目里的 sass 换成了纯 JavaScript 实现的版本问题就解决了。所以我强烈建议大家在做这套系统遇到依赖报错时首先检查版本兼容性而不是反复删除 node_modules 重新安装那是徒劳。5.2 SpringBoot 2.7、MySQL 8.0 驱动版本与 MyBatis 扫描配置这个系统里最坑的场景之一是 MyBatis 的 mapper 接口和 XML 文件扫描不到。明明 XML 文件写在 resources/mapper 下面代码就是报Invalid bound statement (not found)。排查链路是这样的先看 application.yml 里有没有配置 mapper-locations然后再检查启动类上有没有加 MapperScan。很多教程里会在启动类上加 MapperScan 指向某一个包这个包必须和实际 Mapper 接口所在的包完全一致大小写和包名不能错。我遇到过的大小写不一致、包路径名字多打了一个字母这类问题花了我差不多一个晚上才定位到。5.3 MyBatis 一级缓存引发的数据不一致问题一个比较隐蔽的问题是 MyBatis 的一级缓存。默认会话级别缓存在同一个 SqlSession 里执行两次相同的查询第二次会直接返回缓存结果。如果你的业务里先查询了房间状态然后通过其他方式修改了数据库房间状态再执行快速查询时查到了旧值就会很困惑。解决方法是在需要强一致的 Mapper 方法上设置flushCachetrue或者使用注解Options(flushCache Options.FlushCachePolicy.TRUE)。在这个酒店系统的场景里房间状态查询比较频繁而且状态变化很快我故意在几个关键状态查询上关闭了缓存避免前台显示过期的房间状态。5.4 登录 Token 失效与拦截器误伤拦截器放行路径我一开始配得很少结果前端登录成功后跳转首页首页请求列表数据时带上了 token但 token 在登录接口里还没返回给前端于是首页首次请求就没有 token 头又被拦截器拦了。这个问题的根源是前端 token 存储时机不对。正确的做法是在登录成功的回调函数里先 localStorage.setItem 保存 token再调用 next 跳转或者刷新列表。顺序反了就会出现这种诡异的间歇性 403。5.5 前端打包后放到后端时路由变成 404 的问题如果最后使用前后端合并部署即前端构建后的 dist 目录复制到 SpringBoot 项目的 static 目录下会遇到刷新页面 404 的问题。原因在于 Vue Router 默认的 history 模式需要服务器的路径重写支持而 SpringBoot 静态资源服务器不会自动把所有请求转发到 index.html。我最终的解决方式有两个选择一是把 Vue Router 改成 hash 模式URL 里带一个 # 号虽然不好看但省心二是在 SpringBoot 里写一个转发 Controller把所有非 API 路径转发到 index.html。我试过两种实际展示时用了 hash 模式简单可靠。6. 打包部署与答辩准备从能跑变成能展示、能加分6.1 后端打包的标准流程后端用 Maven 打包执行mvn clean package -DskipTests生成 jar 包后直接java -jar运行。这里有个常见问题SpringBoot 自带 Tomcat打出来的 jar 里包含全部依赖任何一台装了 JDK 的机器都能跑不需要额外装 Tomcat这一点在答辩现场很加分。前端打包执行npm run build生成 dist 目录。dist 里面是静态文件可以单独部署到 Nginx也可以复制到后端项目的 resources/static 目录下。我为了演示方便直接采用后者一个 jar 包启动起来之后浏览器访问 8080 端口就是整个系统不需要再启动前端开发服务器。6.2 演示数据的准备答辩或录演示视频时最尴尬的情况是页面打开后表格里空荡荡的或者日期对不上。我会提前准备一批看起来自然的数据比如今天的入住记录、明天的预订记录、后天的退房记录然后用 SQL 脚本一次性插入数据库。这样演示的时候点开“今日到店”就有数据点开“经营统计”就有曲线观众和老师都会觉得系统是真实在使用的状态。6.3 如何把项目讲出深度很多人面试或答辩时喜欢背项目功能“我做了管理员登录、客房管理、预订管理……”这样讲其实没有区分度。换一种讲法效果完全不一样。你可以从设计层面去讲“在房态管理上我用了四态模型来处理房间状态的流转”“在做预订模块时我用区间重叠算法避免了下单冲突”“在权限控制上我通过 JWT 配合拦截器实现无状态登录”。这三个点每一个都是从实际业务问题出发再到具体技术方案比背功能列表强得多。这也就是为什么前面我在数据库设计和预订 SQL 上花了那么多篇幅因为这些才是整套系统里真正属于“你自己的设计点”。最后分享一个我实际操作中的体会如果你是第一次完整做 SpringBoot Vue 项目我建议不要急着买课或者抄网上的开源项目。先自己把数据库表建出来用 Postman 把后端每个接口调通再开始写前端页面。顺序反了的话你会陷入“前端页面写了半天结果查不到数据也不知道问题出在前端还是后端”的泥潭里。每做完一个接口就立即用 Postman 验证每验证通过一个就再去写对应的前端页面这种节奏会稳很多。再有开发过程中所有环境配置项比如 MySQL 连接串、端口号、文件上传路径我建议写进一个 docs 笔记里。这个系统隔一段时间再打开时很多细节会忘掉有个笔记能帮你十分钟内恢复上下文。这套系统做完之后你会对 Java 后端开发、Vue 前端开发、表结构设计、接口联调、打包部署这整条链路形成真实的体感这份体感比任何课程都值钱。
