每年到三四月份总有不少同学私信问我毕设到底选什么题系统做到什么程度答辩才稳有没有一个项目是“功能够全、技术栈够主流、工作量看起来也够足”的如果你正在为选题挠头那我非常建议看看“基于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.xMyBatis Plus 3.5.xMySQL 8.05.7也行但8.0的驱动配置注意要带上时区参数Node.js 16或18Vue3 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类包含code200成功500失败、message提示信息、data返回数据三个字段。所有接口都返回这个结构前端axios响应拦截器只需要判断一次code即可大幅降低了联调成本。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }3.2 认证方案JWT 拦截器认证这块我强烈推荐JWT而不是传统的Session。理由很实际前后端分离项目如果用Session前端每次请求都要带上JSESSIONID跨域时还得处理Cookie麻烦不说前端同学还经常搞不懂为什么登录失效。JWT则把用户信息加密放在请求头里后端拦截器验证放行思路简单直观也好答辩。实现思路是这样的用户登录成功后后端使用io.jsonwebtokenJJWT库生成一个有效期为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-formatYYYY-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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码characterEncodingutf8与serverTimezoneAsia/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这类业务系统从设计到落地的完整链路这个能力是实打实的。 基于SpringBoot+Vue的酒店管理系统设计与实现全攻略
每年到三四月份总有不少同学私信问我毕设到底选什么题系统做到什么程度答辩才稳有没有一个项目是“功能够全、技术栈够主流、工作量看起来也够足”的如果你正在为选题挠头那我非常建议看看“基于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.xMyBatis Plus 3.5.xMySQL 8.05.7也行但8.0的驱动配置注意要带上时区参数Node.js 16或18Vue3 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类包含code200成功500失败、message提示信息、data返回数据三个字段。所有接口都返回这个结构前端axios响应拦截器只需要判断一次code即可大幅降低了联调成本。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }3.2 认证方案JWT 拦截器认证这块我强烈推荐JWT而不是传统的Session。理由很实际前后端分离项目如果用Session前端每次请求都要带上JSESSIONID跨域时还得处理Cookie麻烦不说前端同学还经常搞不懂为什么登录失效。JWT则把用户信息加密放在请求头里后端拦截器验证放行思路简单直观也好答辩。实现思路是这样的用户登录成功后后端使用io.jsonwebtokenJJWT库生成一个有效期为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-formatYYYY-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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码characterEncodingutf8与serverTimezoneAsia/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这类业务系统从设计到落地的完整链路这个能力是实打实的。