每年到三四月份，总有不少同学私信问我：毕设到底选什么题？系统做到什么程度答辩才稳？有没有一个项目是“功能够全、技术栈够主流、工作量看起来也够足”的？
如果你正在为选题挠头，那我非常建议看看“基于SpringBoot + Vue的酒店管理系统”这个方向。它属于典型的web管理系统类毕设，技术栈主流，数据模型清晰，业务场景大家也都熟悉——不需要你去凭空理解一个复杂的行业概念，订房、退房、查房态这些逻辑，一说就懂。正因为懂，你才能把代码写好，才能在答辩时候把自己的设计讲明白。
这篇文章我会把这套系统的核心设计拆开揉碎，从选题理由、数据库建表、后端接口实现、前端页面打通、部署避坑，一直到文档和答辩怎么准备，完整过一遍。项目本身是我带一个实训小组做过的模拟项目X，前后花了两周半，用的正是SpringBoot 2.x加Vue3这种最典型的毕设组合，下文所有经验和踩过的坑都是真实发生的。无论你是想直接照着做一个相似系统，还是只想要一份“逻辑讲得通、代码写得动”的参考方案，这篇文章都值得看完。
1. 选题与整体设计：毕设选型的核心逻辑
1.1 为什么酒店管理系统是“性价比”很高的毕设方向
先说选题思路。计算机毕设最怕的不是题目难，而是题目太偏、太虚。有些同学一上来就想做人工智能、推荐算法，结果数据集找不到、模型训练跑不动、最后只能拿假结果充数；还有些同学选了电商系统，但订单、库存、支付、物流全都要做，工作量直接被自己撑爆。
酒店管理系统恰好处在一个很舒服的档位：它属于信息管理系统大类，核心是围绕“房间”和“订单”两条主线的增删改查与状态流转。这个复杂度足够你展示SpringBoot + Vue的基础功底，又不会让你陷进支付、消息队列、高并发这些对毕设来说过于遥远的领域。只要你把房态管理、预订流程、订单状态、权限区分这四块讲清楚，答辩评委通常会认为你的系统“麻雀虽小，五脏俱全”。
同时，业务本身足够直观。不需要懂供应链，不需要理解金融风控，酒店里“客人订了一间标准间，住了两晚，退房结账”这个流程，所有人都能秒懂。这对写需求分析、画用例图、做数据库设计都特别友好——你完全可以根据常识把逻辑理清楚，不用去网上东拼西凑一份自己都不理解的行业方案。
1.2 前后端分离架构怎么搭更合适
我用的方案是前端Vue3 + 后端SpringBoot 2.x，数据库MySQL，认证走JWT，前端组件库选择Element Plus。之所以没用SpringBoot 3，是因为考虑到大多数同学本地环境还停留在JDK 8，而SpringBoot 2.x配合JDK 8是兼容性最稳的组合，不至于在环境上耗费无谓的精力。
前后端分离的好处在于，开发和答辩演示都更灵活——前端跑在8081端口，后端跑在8080端口，哪里报错一目了然。而且这种架构在简历上写出来也更符合当前企业开发的主流形态，面试官看了不会觉得你只会写传统的单体JSP项目。
项目整体分成三个模块：前台用户端（登录、浏览客房、在线预约、查看个人订单）、后台管理端（房间管理、订单管理、入住退房登记、评价管理、公告发布）、以及系统基础模块（登录注册、个人中心、权限控制）。前端根据用户角色动态渲染菜单，管理员能看到所有管理入口，普通用户只看到自己的预订和订单，这种权限设计同样是你答辩时的一个加分点。
1.3 提前锁定版本号，环境少踩一半坑
这里说一个很多新手容易忽视的事：SpringBoot、JDK、Node、Vue脚手架之间是有版本兼容关系的。我在带小组实训的时候，有位同学自己装了SpringBoot 3.2加Java 17，结果MyBatis Plus的配置方式和他找的教程完全对不上，白白折腾了一整天。
建议直接确定以下版本组合，照着装：
- JDK 8或JDK 11（推荐8，兼容性最好）
- SpringBoot 2.7.x
- MyBatis Plus 3.5.x
- MySQL 8.0（5.7也行，但8.0的驱动配置注意要带上时区参数）
- Node.js 16或18
- Vue3 + Vite + Element Plus
这套组合的教程存量最大，网上随便搜都能找到对应写法，遇到报错也比新版本好排查。项目一开始就把这些注明在README里，不但自己能少踩坑，导师看文档时也会觉得你思路严谨。
2. 数据库建模：订单与房态的联动设计
2.1 需求盘点：核心表至少有哪几张
酒店管理系统的数据表看起来很多，但真正核心的其实就这几张：用户表、客房类型表、客房表、预订订单表、入住信息表、消费记录表、评价表和公告表。我当时做模拟项目X时，还额外加了一张轮播图表用于前端首页展示，但那是锦上添花，没有也不影响主线。
这里特别要提醒的是“客房类型表”和“客房表”要分开。客房类型描述的是“标准间、大床房、豪华套房”这类抽象的分类，包含单价、面积、床型；客房表描述的是具体某一间房，比如301房间属于大床房类型，位于3楼。如果不分表，直接在每一间房上重复写价格、面积，不但冗余严重，以后想统一调价还要改几十行。
用户表也需要区分角色。我的方案是加一个role字段，0代表普通用户，1代表管理员，不单独拆管理员表。理由很简单：系统的管理员数量很少，而且管理员和用户共享登录、修改密码这些基本功能，拆表会让登录逻辑复杂化，得不偿失。
2.2 核心表结构与字段说明
我把最核心的几张表结构简化后列出来，供你参考（项目里的实际字段会更多一些）：
CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE, `password` VARCHAR(100) NOT NULL, `real_name` VARCHAR(50), `phone` VARCHAR(20), `role` TINYINT DEFAULT 0 COMMENT '0-普通用户 1-管理员', `status` TINYINT DEFAULT 1 COMMENT '0-禁用 1-正常', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `room_type` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL, `price` DECIMAL(10,2) NOT NULL, `area` VARCHAR(20), `bed_type` VARCHAR(20), `max_people` INT DEFAULT 2, `remark` VARCHAR(500) ); CREATE TABLE `room` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `type_id` BIGINT NOT NULL, `room_no` VARCHAR(10) NOT NULL, `floor` VARCHAR(10), `status` TINYINT DEFAULT 0 COMMENT '0-空闲 1-已入住 2-清扫中', UNIQUE KEY `uk_room_no` (`room_no`) ); CREATE TABLE `booking_order` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL UNIQUE, `user_id` BIGINT NOT NULL, `room_id` BIGINT NOT NULL, `check_in_date` DATE NOT NULL, `check_out_date` DATE NOT NULL, `total_price` DECIMAL(10,2) NOT NULL, `status` TINYINT DEFAULT 0 COMMENT '0-待支付 1-已支付 2-已入住 3-已退房 4-已取消', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP );订单号为32位字符串，我采用的是yyyyMMddHHmmss + 用户ID + 随机三位数拼接生成，这样即使在测试环境高频下单，也很难撞号。金额一律用DECIMAL(10,2)，绝不能用浮点类型，否则算总价的时候会出现0.1加0.2不等于0.3的经典问题。
2.3 状态字段用数字还是字符串
有些教程会把订单状态直接存成“已支付”、“已取消”这种中文字符串，乍看很直观，但后续扩展和统计都非常别扭。比如你想筛出所有待支付的订单，或者在代码里写一个判断订单是否已入住的逻辑，中文字符串比对既不安全又容易写错。
正确的做法是存数字枚举，然后在后端或前端维护一张映射表。例如状态为2时，前端显示“已入住”，后端写if (order.getStatus() == 2)做判断。这样代码可读性高，又不会把中文散落在数据库各处。我甚至在前端专门写了一个orderStatusMap常量对象，一处定义所有页面共用。
同理，房间状态、用户状态也都用数字表示。习惯这种设计之后，你会发现后面前后端联调的时候省了不知道多少沟通成本。
3. SpringBoot后端：流程处理比CRUD更重要
3.1 分层结构与统一返回格式
后端我采用的是标准的Controller、Service、Mapper三层结构。Controller只负责接收参数和返回结果，不写业务逻辑；Service层处理所有业务判断；Mapper层通过MyBatis Plus操作数据库。
这里有个容易被忽略的细节：返回给前端的数据格式要统一。我定了一个简单的Result类，包含code（200成功，500失败）、message（提示信息）、data（返回数据）三个字段。所有接口都返回这个结构，前端axios响应拦截器只需要判断一次code即可，大幅降低了联调成本。
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }3.2 认证方案：JWT + 拦截器
认证这块，我强烈推荐JWT而不是传统的Session。理由很实际：前后端分离项目如果用Session，前端每次请求都要带上JSESSIONID，跨域时还得处理Cookie，麻烦不说，前端同学还经常搞不懂为什么登录失效。JWT则把用户信息加密放在请求头里，后端拦截器验证放行，思路简单直观，也好答辩。
实现思路是这样的：用户登录成功后，后端使用io.jsonwebtoken（JJWT库）生成一个有效期为24小时的token，其中存入用户ID和用户名。前端把token保存在localStorage里，之后所有请求通过axios请求拦截器放到header中。
后端写一个拦截器统一处理：放行登录、注册接口，其余接口校验token。校验不通过的返回401状态码，前端收到401就自动跳转到登录页。这一步不复杂，但在答辩的时候属于必问点，你的回答越清晰，评委的好感度越高。
3.3 预订、入住、退房三个关键流程
整套系统中业务逻辑最集中的是预订和入住。简单说，预订要做的事是：接收客房类型ID、入住日期、离店日期，判断该类型下有没有符合条件且状态为空闲的房间，有则锁定房间并生成订单，同时把订单状态设为待支付，把房间状态改为“清扫中”以外的占位状态。
我敲代码时最注意的一个点是：订房和改房态必须保持同步。如果你是先更新了房间状态，再生成订单，一旦订单插入失败，房间就被白白占了。这里必须加@Transactional事务注解，让两步操作要么同时成功、要么同时回滚。
入住流程相对简单，管理员把订单状态从已支付改为已入住，房间状态改为已入住。退房则反向操作：订单状态改已退房，房间状态改为“清扫中”。清扫完成后管理员可以再把房间状态手动改为“空闲”。这三个状态流转就是整个酒店管理系统的核心闭环，比单纯做CRUD有价值得多。
3.4 事务、异常与全局处理
事务处理上面提了一句，这里展开讲一个我实际遇到的内存案例。测试过程中有同学发现：生成订单时偶尔会出现“房间被重复预订”的情况。排查半天发现原因是预订时只查了“房间不存在未完成订单”的条件，但没加锁。两个请求同时进来时都通过了校验，于是一间房被订出去两次。
解决方式是在查询可预订房间的SQL上加上FOR UPDATE行锁。注意，使用行锁时事务内查询条件的字段必须走索引，否则行锁会退化成表锁，反而拖慢速度。这个细节我是实际压测时发现的，写论文的时候也可以作为一个技术亮点单独展开。
异常处理上，我注册了一个@RestControllerAdvice全局异常处理器。Service层只管抛出异常，由全局处理器统一捕获并包装成Result.error()返回。这样不会出现某次数据库操作出错时，前端收到一堆看不懂的英文堆栈。
4. Vue3前端：从登录页到管理后台
4.1 脚手架与页面目录划分
前端我用Vite创建Vue3项目，配合Element Plus做界面组件。相比Vue2 + Element UI的老组合，Vue3的Composition API写起来更清晰，而且Element Plus的表格、表单、弹窗组件在管理类项目中尤其好用，基本不需要自己去画复杂的样式。
页面建议按模块分目录，而不是按组件类型分：
views/user：首页、客房列表、在线预订、我的订单views/admin：房间管理、订单管理、入住管理、评价管理、公告管理views/common：登录、注册、个人中心
这样的目录结构，答辩讲解的时候一展开就能让评委看出你的系统边界很清楚——用户端和管理端互不混淆，哪块功能放在哪一目了然。实际开发中也很舒服，找文件不需要脑袋里绕弯子。
4.2 axios封装与token注入
axios如果不封装，每个页面都得重复写Authorization请求头，代码会又臭又长。我建了一个request.js文件统一封装：
import axios from 'axios'; import { ElMessage } from 'element-plus'; import router from '@/router'; const request = axios.create({ baseURL: '/api', timeout: 10000 }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; }); request.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res; } else { ElMessage.error(res.message); return Promise.reject(new Error(res.message)); } }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); } return Promise.reject(error); } );注意baseURL设置成了/api，原因我在后面部署部分会详细说。这样做的好处是：前端开发时通过Vite的proxy代理把/api转发到后端8080端口，生产环境则用Nginx把/api转发到后端服务，前端代码完全不需要改。
4.3 路由守卫与权限控制
路由守卫是另一个答辩时一定会被提到的地方。需求很明确：未登录的用户不能进入后台管理页和预订页；普通用户不能访问管理员专属页面。
Vue Router提供了全局前置守卫，可以在路由跳转前做判断：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); const role = localStorage.getItem('role'); if (to.meta.requiresAuth && !token) { next('/login'); } else if (to.path.startsWith('/admin') && role !== '1') { next('/'); } else { next(); } });同时在路由表里给需要登录的页面加上meta: { requiresAuth: true }标记。注意，这只控制前端页面能不能进，真正的数据安全还是靠后端的拦截器保障——前端权限只是提升体验，后端权限才是数据防线。不少新手只做前端控制而忘了后端校验，结果别人直接调用接口就能拿到管理数据，这问题严重的时候答辩会被一票否决。
4.4 表单验证与交互细节
管理系统最烦的就是各种表单校验。Element Plus自带的表单校验规则基本能满足所有需求，关键在于你要把规则配清楚。比如预订表单，入住日期必须小于离店日期，入住日期不能早于今天，手机号要符合11位格式，这些规则直接写在rules里即可。
一个容易忽略的点是：日期选择器用的是el-date-picker，返回的是字符串还是Date对象取决于你的value-format配置。我一开始没加value-format="YYYY-MM-DD"，传给后端的数据带了一堆时分秒的尾巴，后端再转LocalDate就报错了。这个小问题卡了我整整一个下午，建议你在写代码时一开始就明确接口的日期格式约定。
列表页方面，Element Plus的el-table配合分页组件el-pagination非常好用。只需实现一个loadData方法，把页码和每页条数传给后端，后端用MyBatis Plus的Page对象分页查询，返回总记录数和当前页数据。前后端各管各的，逻辑非常清晰。
5. 环境配置与部署：从“我电脑能跑”到“换台电脑也能跑”
5.1 本地开发环境配置
很多同学项目做完，代码在本地跑得飞起，但一旦换电脑、换环境或者给评委演示时就当场翻车。我建议从第一天就严格按照固定的版本组合来配置环境，并记录下来。
后端方面，application.yml里面的数据库连接配置要特别注意：
spring: datasource: url: jdbc:mysql://localhost:3306/hotel?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码characterEncoding=utf8与serverTimezone=Asia/Shanghai这两个参数基本属于必配项。前者保证中文字符不乱码，后者避免MySQL驱动报时区错误。如果忽略这两项，你大概率会看到一片乱码或一条红色的The server time zone value异常。
前端方面，Vite的vite.config.js中配置代理：
server: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }这样前端发请求时使用的是/api/xxx这种相对路径，不会产生跨域问题。如果你不用代理而直接写http://localhost:8080，那么后端必须额外配置CORS，又得多写很多代码，还可能遇到跨域请求时Cookie带不上的麻烦。两相对比，代理方案实在省心得多。
5.2 打包部署的常规方法
毕设通常不要求你真的部署到云服务器，只要求在本地演示即可。但做好打包步骤还是有用的。后端在根目录执行mvn clean package，得到jar包后通过java -jar运行。前端先执行npm run build，生成dist目录，里面是纯静态文件。
如果不想用Nginx，也可以把前端dist目录和后端jar包放在一起，通过SpringBoot的静态资源映射来访问。不过这种做法在答辩时演示价值不高，我更推荐你在本地装一个Nginx，把dist目录指向Nginx的html目录，再配置一个指向上游后端服务的反向代理。这一套如果搞顺了，不但毕设演示稳如老狗，你在简历里也多了一条“会部署上线”的资本。
5.3 实测高频报错与排查记录
这里把我在实训过程中遇到频率最高的几个问题列出来，每条都是真实记录。
端口被占用。后端启动报Port 8080 was already in use，这条很常见。Windows下用netstat -ano | findstr 8080找到进程号，再在任务管理器里结束进程即可。不过要注意，有时候被杀掉的是相关进程，最好确认一下再动手。
数据库连接失败。通常报错是Access denied for user或者Communications link failure。前者是用户名密码错误，后者是MySQL服务没启动或者端口不对。最简单稳妥的排查顺序是：先确认MySQL服务在运行，再确认URL里的端口是3306，最后确认用户名密码匹配。
后端接口自己用测试工具测没问题，但前端调用就报404。这种情况几乎都是代理没配对，检查一下Vite的proxy路径和后端Controller的@RequestMapping路径是否一致。比如我后端接口是/api/room/list，前端调用的url也必须完整带上/api前缀，代理只负责转发前缀后面的部分。
静态页面能打开，但一调接口就白屏。大多数是token过期或token未传，打开浏览器F12看网络请求，确认请求头里有没有Authorization字段。
6. 毕设文档与答辩：让成果被看见是一门技术
6.1 毕设文档怎么写不容易翻车
文档是不少同学的痛点。代码写好了，但文档不知道怎么凑够字数，最后只能注水。我的建议是：不要按章节顺序写，先画核心图再填表格。
需求分析阶段，把用例图、流程图先画出来。系统有哪几类角色，每类角色能做什么，全部反映在用例图上。接口设计阶段，把Controller层的每个接口整理成一个表格，包含请求路径、请求方式、请求参数、返回参数，这个表格最能直接体现工作量。数据库设计阶段，把所有表结构汇总成一个字段说明表，注明主键、类型、注释。测试部分，按功能模块写测试用例，写明测试步骤、预期结果、实际结果。
这样一套下来，文档内容和你的系统是严格对应的，每一个字都有依据，导师要什么你都能拿出对应的章节来。千万不要东拼西凑别人的文档，字段名对不上、业务逻辑不一致，答辩时一认真就穿帮。
6.2 答辩演示的路线怎么安排
答辩时间通常只有十分钟左右，最忌讳的是从登录页开始一页一页点，点到关键业务时时间没了。要按主线来演示：
第一分钟，讲选题背景和系统技术栈，一句话带过“为什么用SpringBoot + Vue”。接下来两分钟，展示数据库设计，重点讲订单表和房间表的关联关系、状态字段的设计。然后花四分钟演示核心业务流程：用户注册登录、浏览房间、提交预订、管理员处理订单、退房结算，完整走一条线。最后留两分钟讲你在项目里解决的难点，比如并发订房、权限控制、事务处理。这套节奏下来，评委对你的印象是“目标明确、重点突出”，比从头演示到尾强得多。
6.3 毕设之后还能怎么扩展
最后分享一点我自己的体会。酒店管理系统做完之后，如果你想让它从毕业设计变成简历上的“硬通货”，可以考虑再加两个小功能：一个是基于时间段的价格策略，比如节假日自动上浮房价；另一个是数据统计页，用图表展示每日订单量、房态入住率。这两个功能在工作场景中非常常见，写在简历上比单说“我做了个酒店管理系统”有说服力得多。
做毕设这件事，真正让你成长的不是最后那一份文档，而是你为了让它跑起来不断排查问题、查阅文档、调整设计的整个过程。酒店管理系统也许不是最惊艳的题目，但如果你认真把每一个状态流转、每一次事务处理、每一处权限校验都弄明白，它完全能支撑你毕业，也能让你的技术能力上一个台阶。把这些代码吃透，你就掌握了SpringBoot + Vue这类业务系统从设计到落地的完整链路，这个能力是实打实的。
