1. 项目整体设计与技术选型思路1.1 这个系统到底是什么解决什么问题餐饮管理系统说白了就是帮餐厅把“线下手工账”变成“线上电子账”的一套Web软件。前台能点菜、结账、打印小票后台能管菜品、库存、员工、报表老板打开电脑就能看到今天卖了多少钱、哪个菜卖得最好。这套SpringBootVue的完整项目正是面向这类场景的标准Java Web毕设方案。很多人做毕设容易犯一个错一上来就写代码写到一半发现模块太多、关联太乱最后草草收尾。这套项目比较好的地方在于它是典型的“前后端分离 权限控制 业务闭环”结构前端用Vue做单页应用后端用SpringBoot提供RESTful接口数据库用MySQL存业务数据整套链路是完整的不是那种“只有登录注册”的玩具项目。我拿到这个标题第一反应是这套项目适合谁三类人。第一类是计算机相关专业做毕业设计的学生需要一套能跑通、能答辩、能讲清楚原理的项目第二类是刚入行Java开发、想找个完整项目练手的初级工程师想看看企业级项目的目录结构、接口规范、权限模型长什么样第三类是确实有餐厅管理需求的小型商户想快速搭一套内部管理系统。这三类人看这篇文章都能拿到自己想要的东西。1.2 为什么选SpringBoot Vue这对组合先说后端。SpringBoot在Java Web领域已经不是“流行”而是“标配”了它内置Tomcat、自动配置、起步依赖让开发者不用再折腾繁琐的XML配置。对于毕设而言SpringBoot最大的优势是“上手快、资料多、容错率高”你遇到任何问题搜索引擎一搜就是成片解决方案这对答辩前的排错非常重要。再说前端。Vue在国内中小型管理系统的普及率极高它的响应式数据绑定和组件化开发让开发者能很快地把UI页面搭起来。配合Element UI组件库表格、表单、弹窗、菜单这些后台管理系统的“常客”全部现成不用从零写样式。最关键的是“前后端分离”这套架构。前端跑在8080端口后端跑在8081端口两边通过JSON格式的数据交互。这种模式的好处是前端开发和后端开发可以并行开工互不阻塞接口重用性好同一套后端可以同时服务Web端、小程序端、App端部署的时候也能各自扩展前端静态文件丢Nginx后端打jar包丢服务器互不影响。1.3 功能模块全景拆解这套餐饮管理系统按角色划分权限角色不同看到的菜单和能执行的操作完全不同。我把核心模块列出来你看看这个覆盖面是否够“毕设级”模块功能点涉及角色登录认证JWT签发、刷新、退出、密码加密所有用户员工管理员工CRUD、账号启用禁用、角色分配管理员角色权限角色CRUD、菜单树权限绑定管理员菜品管理菜品分类、菜品CRUD、图片上传、上下架管理员/厨师桌台管理桌台状态空闲/占用/清洁、桌台类型收银员/管理员订单管理开台、点菜、加菜、换菜、退菜、结账服务员/收银员会员管理会员卡充值、消费记录、积分收银员报表统计营业额日报、菜品销量排行、订单趋势老板/管理员你会发现这套系统覆盖了餐饮业务的主链路客人到店 → 开台 → 点菜 → 后厨出餐 → 结账 → 数据汇总。每个模块都不是孤立的订单关联桌台和菜品报表依赖订单数据权限控制又贯穿所有模块。这种“业务闭环”恰恰是答辩时最能打动老师的地方因为评委一眼就能看出这不是堆砌功能而是有业务逻辑在里面的。2. 数据库设计与SQL脚本核心拆解2.1 数据库表结构的设计逻辑拿到项目源码后第一步应该看数据库而不是先跑代码。数据库是整套系统的地基表结构设计得合不合理直接决定业务功能能不能顺畅实现。这套项目的SQL脚本我梳理了一下核心表大概在10张左右分成三类。第一类是“用户与权限类”包括系统用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。这套是经典的RBAC基于角色的访问控制模型用户不直接绑定权限而是通过“用户-角色-菜单”三层关系间接获得权限。为什么要这样设计因为餐厅员工流动性大今天来了个服务员明天走了个收银员管理员只需要调整角色关联不用一条条去改权限配置。第二类是“基础资料类”包括菜品分类表、菜品表、桌台表、会员表。这些表是业务运转的基础数据特点是“相对稳定、变化不频繁”。菜品表里有个字段值得注意——status状态字段0表示下架、1表示上架。这个字段看起来简单实际上很有讲究因为它把“删除菜品”和“下架菜品”做了区分。物理删除会把历史订单里的关联数据一起删掉导致报表统计失真而逻辑下架只是改了状态历史数据还完好地留在库里。做餐饮管理系统订单数据是要用来算营业额、分析菜品销量的物理删除是大忌。第三类是“业务流转类”包括订单表、订单明细表。订单表记录每一次消费的总体信息桌台ID、用餐人数、订单状态、应付金额、实付金额、下单时间订单明细表记录订单里的每一道菜品菜品ID、菜品名称、单价、数量、小计。这俩是典型的主从表关系主表一条记录对应从表多条记录。拆分的好处是显而易见的查订单摘要时不需要把每个菜品的明细都捞出来统计销量时又可以直接聚合明细表两边各司其职查询效率高逻辑也清晰。2.2 建表语句的关键细节打开SQL脚本文件你会发现建表语句里有些细节处理得特别到位。我挑几个对毕设答辩有帮助的点说。字段类型方面金额字段统一用DECIMAL而不是FLOAT或DOUBLE。这个很多初学者不理解FLOAT不是也能存小数吗但FLOAT和DOUBLE是浮点数存储时有精度误差0.1 0.2 的结果可能是 0.30000000000000004。金额算错了哪怕差一分钱财务上都过不去。DECIMAL是定点数按整数方式存储小数点位置固定不会有精度丢失。餐饮系统里的菜品单价、订单金额、充值金额全部用DECIMAL(10,2)意思是总长10位、小数占2位最大能存9999999.99对于餐饮场景绰绰有余。时间字段统一用DATETIME并且在设计表的时候默认值设为CURRENT_TIMESTAMP。这样插入记录时不需要手动填写创建时间数据库会自动生成省代码又不会漏。很多同学在写代码的时候手动new Date()传参实际上完全没有必要数据库层面就能解决。索引的设置有讲究。订单明细表里的order_id、菜品ID订单表里的order_time都要建索引。道理很朴素报表查询和订单查询是高频操作没有索引就是全表扫描数据量到几万条以后查询会明显变慢。但索引也不是越多越好每个索引都会拖慢插入和更新速度只给查询频繁的字段加就好。字符集用utf8mb4而不是utf8。原因很简单utf8在MySQL里最多存3个字节而大部分emoji表情需要4个字节如果客人备注里有表情符号用utf8就会报错。utf8mb4是utf8的超集兼容所有字符。这个细节在答辩时主动说出来是很加分的点。2.3 SQL脚本的执行与常见坑执行SQL脚本时最常遇到的报错是版本兼容问题。如果你是MySQL 5.7以下的老版本碰到类似“Invalid default value for create_time”这种错误大概率是DATETIME类型的默认值写法不被支持。解决办法有两个一是升级MySQL版本到5.7以上二是把默认值改成“0000-00-00 00:00:00”并在应用层手动赋值。另一个坑是导入顺序。脚本文件里如果有外键约束必须先建父表再建子表否则会报“Cannot add foreign key constraint”错误。项目里如果准备了一份完整的SQL脚本正常情况下顺序已经排好但如果你是手动从多个脚本文件里复制拼接就要格外小心这个顺序问题。还有个细节建议把SQL脚本里的DROP TABLE IF EXISTS语句保留。很多同学拿到项目后反复导入脚本如果表已存在又没删掉就会报“Table already exists”。有了这行语句每次导入都会先把旧表清掉再建新表保证数据库环境始终是干净的初始状态。但这里要提醒一句这条语句只会删表不会删库而且会清空所有数据生产环境千万别这么干。3. 后端SpringBoot核心实现3.1 项目目录结构与启动流程拿到SpringBoot后端源码先别急着运行花十分钟把目录结构过一遍。这套项目的分层非常清晰属于教科书式的规范结构。com.example.restaurant ├── controller // 控制层接收前端请求、返回结果 ├── service // 业务层处理核心业务逻辑 │ └── impl // 业务实现类 ├── mapper // 数据访问层操作数据库 ├── entity // 实体类对应数据库表结构 ├── dto // 数据传输对象封装前端交互数据 ├── vo // 视图对象定制返回给前端的字段 ├── config // 配置类跨域、拦截器、Knife4j等 ├── common // 公共类统一返回结果、异常处理 ├── utils // 工具类JWT工具、日期工具等 └── RestaurantApplication.java // 启动类实体类、DTO、VO这三者的区别是很多面试官爱问的问题。项目里你能看到实际用法实体类对应数据库表结构字段和表字段一一对应DTO用于接收前端提交的数据比如新增菜品时前端传过来的参数可能包含“图片Base64编码”这个字段数据库中不存在就放在DTO里VO用于定制返回给前端的数据比如查询订单列表时前端需要显示“桌台名称”但订单表里只有“桌台ID”这时就在VO里加一个tableName字段由业务层去关联填充。这种分离设计让每一层各司其职不会出现“一个对象到处传、字段越来越臃肿”的情况。启动流程也很简单先在application.yml里配置好数据库连接信息、Redis连接信息、端口号然后运行RestaurantApplication的main方法。SpringBoot内嵌Tomcat启动后直接监听配置的端口不需要额外安装Tomcat。我第一次用SpringBoot的时候觉得很神奇后来才明白它是在项目启动时通过内嵌容器把Web应用加载起来了。3.2 Spring Security JWT 权限认证机制权限认证是这套系统的安全基石也是面试时的高频考点值得重点讲。项目用的是Spring Security JWT的方案整体思路是这样的用户登录时前端把用户名密码发给后端登录接口。后端验证账号密码是否正确正确就用JWT工具类生成一个token返回给前端。前端拿到token后存在本地之后每次发请求都在请求头里带上“Authorization: Bearer token”。后端有一个JWT认证过滤器会拦截所有请求解析token判断用户身份和有效期把用户信息放到SecurityContext里这样后续的接口就能知道“当前操作的人是谁”。JWT本身是一个三段的字符串由Header、Payload、Signature三部分组成。Header里声明了加密算法Payload里放着用户ID、用户名、过期时间这些核心信息Signature是用密钥对前两段签名生成的。这里有个关键点JWT是无状态的服务器不保存token所以一旦签发在过期之前是无法主动让它失效的。这就是为什么项目里用户退出登录时前端要主动把本地token清掉——后端其实“管不了”已经签发的token。Spring Security的过滤器链配置也有讲究。配置类里通常会放行登录接口和静态资源其他接口全部走认证。另外要设置密码加密器项目里用的基本都是BCryptPasswordEncoder。BCrypt和传统的MD5相比有个显著优势它是加盐的哈希算法同一个密码每次加密的结果都不一样而且计算速度故意设计得比较慢这让暴力破解的成本大幅提高。餐饮系统的员工账号密码虽然不涉及顶级机密但用BCrypt仍然是一个正确的专业习惯。3.3 订单核心流程的状态机设计订单模块是餐饮系统的业务核心也是最值得展开讲的模块。它的难点在于订单状态不是单一的而是随着业务流程不断变化的一个状态机。常规设计下订单状态至少包含待支付已开台但未下单、进行中已下单、菜品制作中、待结账菜品已上齐客人准备买单、已完成结账完成、已取消整单取消。每次状态流转都有一个动作触发比如“点菜”动作把状态从待支付变成进行中“结账”动作把状态从待结账变成已完成。这套设计在代码里通常体现为一个OrderController里面暴露了一系列接口开台接口、点菜接口、加菜接口、退菜接口、结账接口。每个接口都更新订单状态同时保证状态流转的合法性。比如退菜只能在“进行中”状态下操作已经结完账的订单不能退菜——这是业务规则的硬约束必须在代码里校验不能依赖前端隐藏按钮来规避。还有一个细节在并发控制上。两个服务员同时给同一桌客人点菜如果都去更新同一个订单数据会不会乱常规方案是给订单表加一个version字段更新前先比对版本号不一致就说明数据已被别人改过重新查询后再操作。这种乐观锁方案在毕设里可能不会遇到太高并发但写出来显得思考深度够面试或答辩时可以主动提一嘴。3.4 统一返回结果与全局异常处理看一个SpringBoot项目专不专业先看它的接口返回格式统不统一。这套项目里所有接口的返回结果都被包装成一个统一对象结构大概是{ code: 200, msg: 操作成功, data: {} }code是业务状态码200表示成功其他数字分别代表不同的错误类型msg是人类可读的提示信息data是真正的业务数据。这样做的最大好处是前端可以用一套统一的逻辑处理接口返回——先看code再决定是展示数据还是弹错误提示不用每个接口单独判断。与之配套的是全局异常处理。项目里有一个用RestControllerAdvice标注的异常处理类它像一个“兜底网”把Controller层抛出的异常统一拦截下来。业务代码里遇到参数不合法、数据不存在、权限不足这些情况直接抛出对应的自定义异常全局处理器接住后转成统一的错误响应返回给前端。这样做的好处非常明显业务代码里不用写一堆try-catch逻辑干净前端接收到的错误信息格式统一处理起来不用写很多分支判断。我见过很多半成品项目一个模块返回的是{“success”: true}另一个模块返回的是{“status”: 1}前端接口封装被逼着写各种兼容逻辑维护成本高得离谱。这套项目在这点上处理得很规范直接照着用就可以了。4. 前端Vue的实现思路与联调要点4.1 前端项目结构与路由设计前端部分用的是Vue 2 Element UI Axios Vue Router Vuex这套经典组合。为什么不用Vue 3一方面是因为这套组合经过了大量项目的验证资料多、坑少对毕设来说稳定性最重要另一方面是很多学校的Java Web课程还在讲Vue 2教学和项目保持一致答辩时老师更容易看懂。前端项目的基础结构是这样的src ├── api // 接口请求封装按模块拆分成不同的JS文件 ├── assets // 静态资源图片、全局样式 ├── components // 公共组件比如上传组件、分页组件 ├── router // 路由配置文件定义页面路径和组件的对应关系 ├── store // Vuex状态管理存用户信息、token ├── views // 页面组件登录页、菜品管理页、订单页等 ├── utils // 工具函数request封装、token存取 └── App.vue // 根组件路由设计上项目用到了路由守卫router.beforeEach。核心逻辑是每次跳转路由之前先检查本地有没有token。有token就放行没有token就跳转到登录页。这样一来用户就算手动在浏览器地址栏输入一个需要登录才能访问的页面URL也会被守卫拦截下来跳回登录页。这个机制和前端菜单栏的权限控制搭配构成了按钮级权限的完整闭环。Axios请求封装是另一个值得关注的点。项目里的utils/request.js文件创建了一个Axios实例设置基础URLbaseURL为后端的接口地址然后通过请求拦截器自动在请求头里添加“Authorization”字段值是从本地存储中取出来的token。响应拦截器则统一处理返回结果如果后端返回的code不是200就弹出错误提示如果code是401token过期或无效就清除本地登录状态并跳转到登录页。4.2 登录流程与菜单权限的前端控制登录页面是整个前端最基础也最关键的一个页面它的完整流转逻辑是这样的用户输入用户名密码点击登录按钮前端调用后端登录接口。后端校验通过后返回token和用户信息前端把token存到localStorage里把用户信息存到Vuex里。紧接着前端再次请求后端“获取当前用户信息”接口拿到该用户的角色和对应的菜单列表动态生成左侧边栏菜单。这里有个技术点值得展开动态路由和动态菜单。前端路由表里只写死公共路由登录页、404页业务页面路由是根据后端返回的菜单数据动态添加的。具体做法是后端菜单表里每个菜单项都对应一个前端路由的path和组件名称前端拿到菜单数据后通过Vue Router的addRoutes方法动态注册。这套机制的好处是不同角色登录后看到的菜单完全不一样。服务员登录看不到“报表统计”菜单管理员登录才能看到“员工管理”菜单。权限控制自然地从后端透传到了前端既保证了数据安全也改善了用户体验。4.3 跨域问题与联调技巧前后端分离开发时“跨域”是绕不开的问题。前端跑在http://localhost:8080后端跑在http://localhost:8081端口不同浏览器会判定这是跨域请求默认情况下会拦截。解决跨域问题有三种常见方案。第一种最简单在后端写一个跨域配置类实现WebMvcConfigurer接口重写addCorsMappings方法允许所有来源、所有请求头、所有方法的跨域访问。第二种是使用Nginx反向代理前端请求打给NginxNginx再转发给后端浏览器看到的只是同一个域名。第三种是前端开发环境下用Vue CLI的proxy代理配置一个proxyTable让开发服务器把/api开头的请求转发给后端。项目里第二种和第三种方案用得较多因为生产环境用Nginx代理是标配。联调阶段有一个非常实用的技巧把后端接口的baseURL统一维护在一个独立的配置文件里比如src/config/index.js。后端接口地址变了只改这一处就全局生效。千万不要在每个API文件里硬编码URL否则光是改接口地址就能浪费半天时间。5. 接口文档与调试工具5.1 为什么项目要配套接口文档接口文档是前后端协作的“契约”。前端要知道后端接口的URL是什么、请求参数有哪些、返回格式长什么样才能正确调用。这套项目在公司里一般用Swagger或Knife4j自动生成接口文档后端代码写完文档自动更新不会出现代码改了文档忘记同步的尴尬。对于毕设来说接口文档还有一个隐性价值答辩时老师问“你的系统怎么设计的”你可以直接打开接口文档页面对着一个个接口讲业务功能的实现逻辑。这种展示方式比PPT截图要有说服力得多因为它展示了你的系统是真正跑起来的东西而不是空画流程图。5.2 Knife4j接口文档的集成与使用Knife4j是Swagger的增强框架UI界面比原版好看很多还支持接口调试在SpringBoot项目里集成非常简单。先引入依赖再添加一个配置类扫描Controller所在的包最后访问/doc.html就能看到文档页面。集成的时候有几个容易忽略的细节。第一生产环境一定要关闭接口文档的访问权限不然等于把系统的所有接口路径和参数结构暴露给外部属实在安全上留了个坑。关闭方式很简单在配置类里加一个Profile({dev})注解只在开发环境生效。第二接口文档上的说明信息比如“接口描述”“参数说明”是通过注解写在代码里的写的时候要实事求是别写和实际逻辑不符的描述否则调试时会被误导。Knife4j最实用的功能是“在线调试”。我在整合前后端联调时经常遇到一种情况前端说“接口报错了”但不知道是参数传错还是后端逻辑有问题。这时候直接在Knife4j的文档页面上模拟请求传一遍同样的参数就能确定问题到底出在哪一端。这个手段在答辩演示时也是神器老师想看某个接口怎么工作直接在文档页面点一下就看到了返回结果比切换到Postman演示方便得多。5.3 接口设计规范与返回结构约定这套项目的接口设计遵循RESTful风格接口路径用名词复数表示资源用HTTP动词表示操作。请求方式路径功能POST/api/login用户登录GET/api/employee/list分页查询员工列表POST/api/employee新增员工PUT/api/employee/{id}修改员工信息DELETE/api/employee/{id}删除员工GET/api/dish/list分页查询菜品列表POST/api/order/create创建订单参数校验也在接口层做了统一处理比如用户名不能为空、手机号格式要正确、价格必须大于0这些规则通过Valid注解配合实体类字段上的校验注解NotBlank、Pattern、DecimalMin等自动完成不需要在业务代码里写一堆if-else判断。这种“声明式校验”风格既简洁又规范在实际开发中也是主流做法。6. 常见问题与排查技巧实录6.1 启动阶段高频报错项目跑不起来的坑80%集中在启动阶段。我整理了这套项目最常出现的几个问题以及对应的排查思路。问题一Application run failed报数据库连接失败这个报错有九成是数据库配置问题。检查顺序数据库服务有没有启动账号密码对不对连接地址端口、库名是否和实际一致。还有一个容易忽略的点如果用的是MySQL 8.0以上版本驱动类要换成com.mysql.cj.jdbc.Driver同时要在连接URL后面加上时区参数serverTimezoneAsia/Shanghai否则启动时会报时区相关的错误。问题二端口被占用后端端口若设置成8080经常被其他程序占用。解决办法一是改application.yml里的端口号二是找到占用进程并杀掉。Windows下用netstat -ano | findstr 8080找到进程PID再在任务管理器里结束Linux下用lsof -i:8080查看。我是建议直接改端口比如8081因为前端Vue开发服务器默认就是8080两边端口错开联调时不容易混。问题三Java版本不匹配SpringBoot 2.x版本对Java版本有要求用Java 8或Java 11是最稳妥的选择。如果你本机装的是Java 17启动时报UnsupportedClassVersionError或类似错误大概率就是版本不对。下载安装JDK 8后在IDE里把项目的SDK和编译级别都切到1.8同时检查Maven配置里有没有指定编译版本。6.2 前后端联调阶段经典问题联调阶段最经典的问题就是跨域报错。浏览器控制台出现“Access to XMLHttpRequest at ... from origin ... has been blocked by CORS policy”基本就是跨域配置没生效。检查顺序后端有没有配置CORS配置的路径是否覆盖了前端请求的地址请求头里有没有带上后端允许的headers。第二个高频问题是token丢失或过期。前端登录成功后token是存在localStorage里的如果页面刷新后请求401先看请求头里Authorization字段有没有值。没有值说明登录态没存住检查登录逻辑里是否调用了存储token的操作有值但还报401可能是token过期了理论上重新登录就行。第三个问题是接口请求成功了但数据不显示。这种情况通常是返回数据的字段名对不上。后端返回的字段是驼峰命名比如tableName前端却写成了下划线命名table_name或者后端返回的是一个嵌套对象前端页面直接去取了一个不存在的属性。排查方法很简单打开浏览器的开发者工具切到Network标签页看接口返回的JSON结构再和前端代码里取值的地方对照一目了然。6.3 菜品图片上传报错排查图片上传是餐饮系统必有的功能但也是坑最多的模块之一。常见报错是“MultipartException: Current request is not a multipart request”。这个报错的意思是前端提交的请求格式不是multipart/form-data。检查前端的请求头设置上传文件时千万不能手动设置Content-Type为application/json要让浏览器自动生成带boundary的multipart格式。另一个上传问题是文件保存路径。开发环境下保存到本机一个绝对路径比如D:/upload/跑起来没问题。但部署到服务器后路径不存在或者没权限就会报错。更稳妥的做法是把上传路径做成可配置的写在application.yml里部署时按需修改同时要保证上传目录有写权限Linux下可以用chmod 755 /data/upload设置。6.4 常见问题速查表问题现象可能原因处理办法启动报数据库连接失败数据库地址/账号/密码错误或时区未设置核对application.yml配置URL加serverTimezone接口返回401token缺失或过期清理本地缓存后重新登录检查请求拦截器前端请求跨域被拦截后端未配置CORS后端添加CORS配置类或前端配置dev proxy图片上传失败请求格式不对或服务器路径无权限检查请求头改用multipart格式配置可写路径菜品列表显示不出来字段名对不上或数据未加载用浏览器F12看接口返回对照字段名端口被占用本机其他进程使用同一端口改端口号或kill占用进程菜单显示不完整当前用户角色未绑定对应菜单用管理员账号登录在角色管理中绑定菜单结账金额不对使用了浮点类型存储金额检查表结构金额字段是否为DECIMAL7. 项目扩展与实际落地建议7.1 从毕设到项目还能怎么加功能如果时间充裕我建议在现有基础上加一两个亮点功能这会让你的毕设从“完成”升级为“优秀”。加一个Redis缓存。当前菜品分类和菜品信息是每次直接查数据库的数据量大了之后接口响应会变慢。引入Redis后把菜品列表缓存起来设置过期时间比如30分钟菜品变更时主动清掉缓存。这个“缓存穿透、缓存失效”的内容在答辩时可以讲出一套完整的故事非常能体现技术水平。加一个WebSocket实时通知。餐厅场景里客人下单后后厨的屏幕上应该实时弹出新订单提醒。用WebSocket实现服务端主动推送前端页面收到消息后自动刷新订单列表。这种“实时性”是前后端分离架构的经典应用场景技术栈里加一个WebSocket整个系统的完整性立刻提升一个档次。加一个数据导出功能。报表统计只停留在页面展示不算完整。用EasyExcel导出Excel报表老板可以把每天的营业数据下载下来做二次分析。EasyExcel是阿里开源的性能好、使用简单而且在简历上是个常见的技能点。7.2 上线部署的核心要点如果这套系统不只要交毕设而是真的要在小餐厅跑起来有几个部署要点值得提前考虑。前端构建打包。在Vue项目目录下执行npm run build生成dist静态目录把dist目录上传到服务器的Nginx静态目录下配置一个server块root指向dist目录即可。后端打成jar包用java -jar命令启动也可以注册成systemd服务开机自启。Nginx的配置既要托管前端静态资源也别忘了反向代理后端接口。一个典型的配置是这样监听80端口location /指向dist目录location /api/ { proxy_pass http://127.0.0.1:8081/; }把/api开头的请求转发给后端的SpringBoot服务。这种部署方式把前后端整合到了同一个域名下也顺带解决了跨域问题。数据库和备份。生产环境的MySQL记得设置好账号权限不要用root跑业务。定期备份数据库最简单的方式是写一个crontab定时任务每天凌晨用mysqldump导出SQL文件保留最近7天的备份。7.3 给初学者的学习路径建议最后聊点实在的。如果你拿着这套源码不知道怎么下手去学我建议按顺序做下面四步。先用起来。搭好环境导入SQL脚本启动后端和前端把系统的每个功能点都点一遍。这一步的目标是建立“整体感知”知道系统有哪些页面、每个页面能干什么、数据是怎么流转的。再理结构。对照接口文档从前端页面出发逐步追踪到后端接口、Service层、Mapper层把一条完整的请求链路打通。比如“菜品列表是怎么从数据库到页面上的”把这一个链路读懂了其他模块基本都是类似的套路。然后改功能。找一个你感兴趣的模块尝试加一个小功能。“菜品管理”加一个“批量上架”或者“报表统计”加一个“按周统计”改的过程中你会自然理解哪些地方需要修改哪些地方耦合度比较高这才是调试能力成长最快的时候。最后静下心思考设计。问问自己为什么用JWT而不用Session为什么用RBAC模型做权限为什么金额字段用DECIMAL这些“为什么”才是面试官真正关心的东西也是你比别人多出来的核心竞争力。源码可以抄思路必须自己消化。我在实际跑这个项目的过程中最大的体会是一套完整的项目源码真正的价值不在于“能跑”而在于它是你理解整套技术栈如何协作的最佳教材。把前端、后端、数据库、接口文档这条链上每一个环节都亲手打通你的Java Web水平会上一个真正的台阶。拿到源码的朋友别急着炫技加功能先顺着业务把代码读通这是最快的学习路径。 SpringBoot+Vue餐饮管理系统设计与实现：从数据库到权限控制的完整毕设项目
1. 项目整体设计与技术选型思路1.1 这个系统到底是什么解决什么问题餐饮管理系统说白了就是帮餐厅把“线下手工账”变成“线上电子账”的一套Web软件。前台能点菜、结账、打印小票后台能管菜品、库存、员工、报表老板打开电脑就能看到今天卖了多少钱、哪个菜卖得最好。这套SpringBootVue的完整项目正是面向这类场景的标准Java Web毕设方案。很多人做毕设容易犯一个错一上来就写代码写到一半发现模块太多、关联太乱最后草草收尾。这套项目比较好的地方在于它是典型的“前后端分离 权限控制 业务闭环”结构前端用Vue做单页应用后端用SpringBoot提供RESTful接口数据库用MySQL存业务数据整套链路是完整的不是那种“只有登录注册”的玩具项目。我拿到这个标题第一反应是这套项目适合谁三类人。第一类是计算机相关专业做毕业设计的学生需要一套能跑通、能答辩、能讲清楚原理的项目第二类是刚入行Java开发、想找个完整项目练手的初级工程师想看看企业级项目的目录结构、接口规范、权限模型长什么样第三类是确实有餐厅管理需求的小型商户想快速搭一套内部管理系统。这三类人看这篇文章都能拿到自己想要的东西。1.2 为什么选SpringBoot Vue这对组合先说后端。SpringBoot在Java Web领域已经不是“流行”而是“标配”了它内置Tomcat、自动配置、起步依赖让开发者不用再折腾繁琐的XML配置。对于毕设而言SpringBoot最大的优势是“上手快、资料多、容错率高”你遇到任何问题搜索引擎一搜就是成片解决方案这对答辩前的排错非常重要。再说前端。Vue在国内中小型管理系统的普及率极高它的响应式数据绑定和组件化开发让开发者能很快地把UI页面搭起来。配合Element UI组件库表格、表单、弹窗、菜单这些后台管理系统的“常客”全部现成不用从零写样式。最关键的是“前后端分离”这套架构。前端跑在8080端口后端跑在8081端口两边通过JSON格式的数据交互。这种模式的好处是前端开发和后端开发可以并行开工互不阻塞接口重用性好同一套后端可以同时服务Web端、小程序端、App端部署的时候也能各自扩展前端静态文件丢Nginx后端打jar包丢服务器互不影响。1.3 功能模块全景拆解这套餐饮管理系统按角色划分权限角色不同看到的菜单和能执行的操作完全不同。我把核心模块列出来你看看这个覆盖面是否够“毕设级”模块功能点涉及角色登录认证JWT签发、刷新、退出、密码加密所有用户员工管理员工CRUD、账号启用禁用、角色分配管理员角色权限角色CRUD、菜单树权限绑定管理员菜品管理菜品分类、菜品CRUD、图片上传、上下架管理员/厨师桌台管理桌台状态空闲/占用/清洁、桌台类型收银员/管理员订单管理开台、点菜、加菜、换菜、退菜、结账服务员/收银员会员管理会员卡充值、消费记录、积分收银员报表统计营业额日报、菜品销量排行、订单趋势老板/管理员你会发现这套系统覆盖了餐饮业务的主链路客人到店 → 开台 → 点菜 → 后厨出餐 → 结账 → 数据汇总。每个模块都不是孤立的订单关联桌台和菜品报表依赖订单数据权限控制又贯穿所有模块。这种“业务闭环”恰恰是答辩时最能打动老师的地方因为评委一眼就能看出这不是堆砌功能而是有业务逻辑在里面的。2. 数据库设计与SQL脚本核心拆解2.1 数据库表结构的设计逻辑拿到项目源码后第一步应该看数据库而不是先跑代码。数据库是整套系统的地基表结构设计得合不合理直接决定业务功能能不能顺畅实现。这套项目的SQL脚本我梳理了一下核心表大概在10张左右分成三类。第一类是“用户与权限类”包括系统用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。这套是经典的RBAC基于角色的访问控制模型用户不直接绑定权限而是通过“用户-角色-菜单”三层关系间接获得权限。为什么要这样设计因为餐厅员工流动性大今天来了个服务员明天走了个收银员管理员只需要调整角色关联不用一条条去改权限配置。第二类是“基础资料类”包括菜品分类表、菜品表、桌台表、会员表。这些表是业务运转的基础数据特点是“相对稳定、变化不频繁”。菜品表里有个字段值得注意——status状态字段0表示下架、1表示上架。这个字段看起来简单实际上很有讲究因为它把“删除菜品”和“下架菜品”做了区分。物理删除会把历史订单里的关联数据一起删掉导致报表统计失真而逻辑下架只是改了状态历史数据还完好地留在库里。做餐饮管理系统订单数据是要用来算营业额、分析菜品销量的物理删除是大忌。第三类是“业务流转类”包括订单表、订单明细表。订单表记录每一次消费的总体信息桌台ID、用餐人数、订单状态、应付金额、实付金额、下单时间订单明细表记录订单里的每一道菜品菜品ID、菜品名称、单价、数量、小计。这俩是典型的主从表关系主表一条记录对应从表多条记录。拆分的好处是显而易见的查订单摘要时不需要把每个菜品的明细都捞出来统计销量时又可以直接聚合明细表两边各司其职查询效率高逻辑也清晰。2.2 建表语句的关键细节打开SQL脚本文件你会发现建表语句里有些细节处理得特别到位。我挑几个对毕设答辩有帮助的点说。字段类型方面金额字段统一用DECIMAL而不是FLOAT或DOUBLE。这个很多初学者不理解FLOAT不是也能存小数吗但FLOAT和DOUBLE是浮点数存储时有精度误差0.1 0.2 的结果可能是 0.30000000000000004。金额算错了哪怕差一分钱财务上都过不去。DECIMAL是定点数按整数方式存储小数点位置固定不会有精度丢失。餐饮系统里的菜品单价、订单金额、充值金额全部用DECIMAL(10,2)意思是总长10位、小数占2位最大能存9999999.99对于餐饮场景绰绰有余。时间字段统一用DATETIME并且在设计表的时候默认值设为CURRENT_TIMESTAMP。这样插入记录时不需要手动填写创建时间数据库会自动生成省代码又不会漏。很多同学在写代码的时候手动new Date()传参实际上完全没有必要数据库层面就能解决。索引的设置有讲究。订单明细表里的order_id、菜品ID订单表里的order_time都要建索引。道理很朴素报表查询和订单查询是高频操作没有索引就是全表扫描数据量到几万条以后查询会明显变慢。但索引也不是越多越好每个索引都会拖慢插入和更新速度只给查询频繁的字段加就好。字符集用utf8mb4而不是utf8。原因很简单utf8在MySQL里最多存3个字节而大部分emoji表情需要4个字节如果客人备注里有表情符号用utf8就会报错。utf8mb4是utf8的超集兼容所有字符。这个细节在答辩时主动说出来是很加分的点。2.3 SQL脚本的执行与常见坑执行SQL脚本时最常遇到的报错是版本兼容问题。如果你是MySQL 5.7以下的老版本碰到类似“Invalid default value for create_time”这种错误大概率是DATETIME类型的默认值写法不被支持。解决办法有两个一是升级MySQL版本到5.7以上二是把默认值改成“0000-00-00 00:00:00”并在应用层手动赋值。另一个坑是导入顺序。脚本文件里如果有外键约束必须先建父表再建子表否则会报“Cannot add foreign key constraint”错误。项目里如果准备了一份完整的SQL脚本正常情况下顺序已经排好但如果你是手动从多个脚本文件里复制拼接就要格外小心这个顺序问题。还有个细节建议把SQL脚本里的DROP TABLE IF EXISTS语句保留。很多同学拿到项目后反复导入脚本如果表已存在又没删掉就会报“Table already exists”。有了这行语句每次导入都会先把旧表清掉再建新表保证数据库环境始终是干净的初始状态。但这里要提醒一句这条语句只会删表不会删库而且会清空所有数据生产环境千万别这么干。3. 后端SpringBoot核心实现3.1 项目目录结构与启动流程拿到SpringBoot后端源码先别急着运行花十分钟把目录结构过一遍。这套项目的分层非常清晰属于教科书式的规范结构。com.example.restaurant ├── controller // 控制层接收前端请求、返回结果 ├── service // 业务层处理核心业务逻辑 │ └── impl // 业务实现类 ├── mapper // 数据访问层操作数据库 ├── entity // 实体类对应数据库表结构 ├── dto // 数据传输对象封装前端交互数据 ├── vo // 视图对象定制返回给前端的字段 ├── config // 配置类跨域、拦截器、Knife4j等 ├── common // 公共类统一返回结果、异常处理 ├── utils // 工具类JWT工具、日期工具等 └── RestaurantApplication.java // 启动类实体类、DTO、VO这三者的区别是很多面试官爱问的问题。项目里你能看到实际用法实体类对应数据库表结构字段和表字段一一对应DTO用于接收前端提交的数据比如新增菜品时前端传过来的参数可能包含“图片Base64编码”这个字段数据库中不存在就放在DTO里VO用于定制返回给前端的数据比如查询订单列表时前端需要显示“桌台名称”但订单表里只有“桌台ID”这时就在VO里加一个tableName字段由业务层去关联填充。这种分离设计让每一层各司其职不会出现“一个对象到处传、字段越来越臃肿”的情况。启动流程也很简单先在application.yml里配置好数据库连接信息、Redis连接信息、端口号然后运行RestaurantApplication的main方法。SpringBoot内嵌Tomcat启动后直接监听配置的端口不需要额外安装Tomcat。我第一次用SpringBoot的时候觉得很神奇后来才明白它是在项目启动时通过内嵌容器把Web应用加载起来了。3.2 Spring Security JWT 权限认证机制权限认证是这套系统的安全基石也是面试时的高频考点值得重点讲。项目用的是Spring Security JWT的方案整体思路是这样的用户登录时前端把用户名密码发给后端登录接口。后端验证账号密码是否正确正确就用JWT工具类生成一个token返回给前端。前端拿到token后存在本地之后每次发请求都在请求头里带上“Authorization: Bearer token”。后端有一个JWT认证过滤器会拦截所有请求解析token判断用户身份和有效期把用户信息放到SecurityContext里这样后续的接口就能知道“当前操作的人是谁”。JWT本身是一个三段的字符串由Header、Payload、Signature三部分组成。Header里声明了加密算法Payload里放着用户ID、用户名、过期时间这些核心信息Signature是用密钥对前两段签名生成的。这里有个关键点JWT是无状态的服务器不保存token所以一旦签发在过期之前是无法主动让它失效的。这就是为什么项目里用户退出登录时前端要主动把本地token清掉——后端其实“管不了”已经签发的token。Spring Security的过滤器链配置也有讲究。配置类里通常会放行登录接口和静态资源其他接口全部走认证。另外要设置密码加密器项目里用的基本都是BCryptPasswordEncoder。BCrypt和传统的MD5相比有个显著优势它是加盐的哈希算法同一个密码每次加密的结果都不一样而且计算速度故意设计得比较慢这让暴力破解的成本大幅提高。餐饮系统的员工账号密码虽然不涉及顶级机密但用BCrypt仍然是一个正确的专业习惯。3.3 订单核心流程的状态机设计订单模块是餐饮系统的业务核心也是最值得展开讲的模块。它的难点在于订单状态不是单一的而是随着业务流程不断变化的一个状态机。常规设计下订单状态至少包含待支付已开台但未下单、进行中已下单、菜品制作中、待结账菜品已上齐客人准备买单、已完成结账完成、已取消整单取消。每次状态流转都有一个动作触发比如“点菜”动作把状态从待支付变成进行中“结账”动作把状态从待结账变成已完成。这套设计在代码里通常体现为一个OrderController里面暴露了一系列接口开台接口、点菜接口、加菜接口、退菜接口、结账接口。每个接口都更新订单状态同时保证状态流转的合法性。比如退菜只能在“进行中”状态下操作已经结完账的订单不能退菜——这是业务规则的硬约束必须在代码里校验不能依赖前端隐藏按钮来规避。还有一个细节在并发控制上。两个服务员同时给同一桌客人点菜如果都去更新同一个订单数据会不会乱常规方案是给订单表加一个version字段更新前先比对版本号不一致就说明数据已被别人改过重新查询后再操作。这种乐观锁方案在毕设里可能不会遇到太高并发但写出来显得思考深度够面试或答辩时可以主动提一嘴。3.4 统一返回结果与全局异常处理看一个SpringBoot项目专不专业先看它的接口返回格式统不统一。这套项目里所有接口的返回结果都被包装成一个统一对象结构大概是{ code: 200, msg: 操作成功, data: {} }code是业务状态码200表示成功其他数字分别代表不同的错误类型msg是人类可读的提示信息data是真正的业务数据。这样做的最大好处是前端可以用一套统一的逻辑处理接口返回——先看code再决定是展示数据还是弹错误提示不用每个接口单独判断。与之配套的是全局异常处理。项目里有一个用RestControllerAdvice标注的异常处理类它像一个“兜底网”把Controller层抛出的异常统一拦截下来。业务代码里遇到参数不合法、数据不存在、权限不足这些情况直接抛出对应的自定义异常全局处理器接住后转成统一的错误响应返回给前端。这样做的好处非常明显业务代码里不用写一堆try-catch逻辑干净前端接收到的错误信息格式统一处理起来不用写很多分支判断。我见过很多半成品项目一个模块返回的是{“success”: true}另一个模块返回的是{“status”: 1}前端接口封装被逼着写各种兼容逻辑维护成本高得离谱。这套项目在这点上处理得很规范直接照着用就可以了。4. 前端Vue的实现思路与联调要点4.1 前端项目结构与路由设计前端部分用的是Vue 2 Element UI Axios Vue Router Vuex这套经典组合。为什么不用Vue 3一方面是因为这套组合经过了大量项目的验证资料多、坑少对毕设来说稳定性最重要另一方面是很多学校的Java Web课程还在讲Vue 2教学和项目保持一致答辩时老师更容易看懂。前端项目的基础结构是这样的src ├── api // 接口请求封装按模块拆分成不同的JS文件 ├── assets // 静态资源图片、全局样式 ├── components // 公共组件比如上传组件、分页组件 ├── router // 路由配置文件定义页面路径和组件的对应关系 ├── store // Vuex状态管理存用户信息、token ├── views // 页面组件登录页、菜品管理页、订单页等 ├── utils // 工具函数request封装、token存取 └── App.vue // 根组件路由设计上项目用到了路由守卫router.beforeEach。核心逻辑是每次跳转路由之前先检查本地有没有token。有token就放行没有token就跳转到登录页。这样一来用户就算手动在浏览器地址栏输入一个需要登录才能访问的页面URL也会被守卫拦截下来跳回登录页。这个机制和前端菜单栏的权限控制搭配构成了按钮级权限的完整闭环。Axios请求封装是另一个值得关注的点。项目里的utils/request.js文件创建了一个Axios实例设置基础URLbaseURL为后端的接口地址然后通过请求拦截器自动在请求头里添加“Authorization”字段值是从本地存储中取出来的token。响应拦截器则统一处理返回结果如果后端返回的code不是200就弹出错误提示如果code是401token过期或无效就清除本地登录状态并跳转到登录页。4.2 登录流程与菜单权限的前端控制登录页面是整个前端最基础也最关键的一个页面它的完整流转逻辑是这样的用户输入用户名密码点击登录按钮前端调用后端登录接口。后端校验通过后返回token和用户信息前端把token存到localStorage里把用户信息存到Vuex里。紧接着前端再次请求后端“获取当前用户信息”接口拿到该用户的角色和对应的菜单列表动态生成左侧边栏菜单。这里有个技术点值得展开动态路由和动态菜单。前端路由表里只写死公共路由登录页、404页业务页面路由是根据后端返回的菜单数据动态添加的。具体做法是后端菜单表里每个菜单项都对应一个前端路由的path和组件名称前端拿到菜单数据后通过Vue Router的addRoutes方法动态注册。这套机制的好处是不同角色登录后看到的菜单完全不一样。服务员登录看不到“报表统计”菜单管理员登录才能看到“员工管理”菜单。权限控制自然地从后端透传到了前端既保证了数据安全也改善了用户体验。4.3 跨域问题与联调技巧前后端分离开发时“跨域”是绕不开的问题。前端跑在http://localhost:8080后端跑在http://localhost:8081端口不同浏览器会判定这是跨域请求默认情况下会拦截。解决跨域问题有三种常见方案。第一种最简单在后端写一个跨域配置类实现WebMvcConfigurer接口重写addCorsMappings方法允许所有来源、所有请求头、所有方法的跨域访问。第二种是使用Nginx反向代理前端请求打给NginxNginx再转发给后端浏览器看到的只是同一个域名。第三种是前端开发环境下用Vue CLI的proxy代理配置一个proxyTable让开发服务器把/api开头的请求转发给后端。项目里第二种和第三种方案用得较多因为生产环境用Nginx代理是标配。联调阶段有一个非常实用的技巧把后端接口的baseURL统一维护在一个独立的配置文件里比如src/config/index.js。后端接口地址变了只改这一处就全局生效。千万不要在每个API文件里硬编码URL否则光是改接口地址就能浪费半天时间。5. 接口文档与调试工具5.1 为什么项目要配套接口文档接口文档是前后端协作的“契约”。前端要知道后端接口的URL是什么、请求参数有哪些、返回格式长什么样才能正确调用。这套项目在公司里一般用Swagger或Knife4j自动生成接口文档后端代码写完文档自动更新不会出现代码改了文档忘记同步的尴尬。对于毕设来说接口文档还有一个隐性价值答辩时老师问“你的系统怎么设计的”你可以直接打开接口文档页面对着一个个接口讲业务功能的实现逻辑。这种展示方式比PPT截图要有说服力得多因为它展示了你的系统是真正跑起来的东西而不是空画流程图。5.2 Knife4j接口文档的集成与使用Knife4j是Swagger的增强框架UI界面比原版好看很多还支持接口调试在SpringBoot项目里集成非常简单。先引入依赖再添加一个配置类扫描Controller所在的包最后访问/doc.html就能看到文档页面。集成的时候有几个容易忽略的细节。第一生产环境一定要关闭接口文档的访问权限不然等于把系统的所有接口路径和参数结构暴露给外部属实在安全上留了个坑。关闭方式很简单在配置类里加一个Profile({dev})注解只在开发环境生效。第二接口文档上的说明信息比如“接口描述”“参数说明”是通过注解写在代码里的写的时候要实事求是别写和实际逻辑不符的描述否则调试时会被误导。Knife4j最实用的功能是“在线调试”。我在整合前后端联调时经常遇到一种情况前端说“接口报错了”但不知道是参数传错还是后端逻辑有问题。这时候直接在Knife4j的文档页面上模拟请求传一遍同样的参数就能确定问题到底出在哪一端。这个手段在答辩演示时也是神器老师想看某个接口怎么工作直接在文档页面点一下就看到了返回结果比切换到Postman演示方便得多。5.3 接口设计规范与返回结构约定这套项目的接口设计遵循RESTful风格接口路径用名词复数表示资源用HTTP动词表示操作。请求方式路径功能POST/api/login用户登录GET/api/employee/list分页查询员工列表POST/api/employee新增员工PUT/api/employee/{id}修改员工信息DELETE/api/employee/{id}删除员工GET/api/dish/list分页查询菜品列表POST/api/order/create创建订单参数校验也在接口层做了统一处理比如用户名不能为空、手机号格式要正确、价格必须大于0这些规则通过Valid注解配合实体类字段上的校验注解NotBlank、Pattern、DecimalMin等自动完成不需要在业务代码里写一堆if-else判断。这种“声明式校验”风格既简洁又规范在实际开发中也是主流做法。6. 常见问题与排查技巧实录6.1 启动阶段高频报错项目跑不起来的坑80%集中在启动阶段。我整理了这套项目最常出现的几个问题以及对应的排查思路。问题一Application run failed报数据库连接失败这个报错有九成是数据库配置问题。检查顺序数据库服务有没有启动账号密码对不对连接地址端口、库名是否和实际一致。还有一个容易忽略的点如果用的是MySQL 8.0以上版本驱动类要换成com.mysql.cj.jdbc.Driver同时要在连接URL后面加上时区参数serverTimezoneAsia/Shanghai否则启动时会报时区相关的错误。问题二端口被占用后端端口若设置成8080经常被其他程序占用。解决办法一是改application.yml里的端口号二是找到占用进程并杀掉。Windows下用netstat -ano | findstr 8080找到进程PID再在任务管理器里结束Linux下用lsof -i:8080查看。我是建议直接改端口比如8081因为前端Vue开发服务器默认就是8080两边端口错开联调时不容易混。问题三Java版本不匹配SpringBoot 2.x版本对Java版本有要求用Java 8或Java 11是最稳妥的选择。如果你本机装的是Java 17启动时报UnsupportedClassVersionError或类似错误大概率就是版本不对。下载安装JDK 8后在IDE里把项目的SDK和编译级别都切到1.8同时检查Maven配置里有没有指定编译版本。6.2 前后端联调阶段经典问题联调阶段最经典的问题就是跨域报错。浏览器控制台出现“Access to XMLHttpRequest at ... from origin ... has been blocked by CORS policy”基本就是跨域配置没生效。检查顺序后端有没有配置CORS配置的路径是否覆盖了前端请求的地址请求头里有没有带上后端允许的headers。第二个高频问题是token丢失或过期。前端登录成功后token是存在localStorage里的如果页面刷新后请求401先看请求头里Authorization字段有没有值。没有值说明登录态没存住检查登录逻辑里是否调用了存储token的操作有值但还报401可能是token过期了理论上重新登录就行。第三个问题是接口请求成功了但数据不显示。这种情况通常是返回数据的字段名对不上。后端返回的字段是驼峰命名比如tableName前端却写成了下划线命名table_name或者后端返回的是一个嵌套对象前端页面直接去取了一个不存在的属性。排查方法很简单打开浏览器的开发者工具切到Network标签页看接口返回的JSON结构再和前端代码里取值的地方对照一目了然。6.3 菜品图片上传报错排查图片上传是餐饮系统必有的功能但也是坑最多的模块之一。常见报错是“MultipartException: Current request is not a multipart request”。这个报错的意思是前端提交的请求格式不是multipart/form-data。检查前端的请求头设置上传文件时千万不能手动设置Content-Type为application/json要让浏览器自动生成带boundary的multipart格式。另一个上传问题是文件保存路径。开发环境下保存到本机一个绝对路径比如D:/upload/跑起来没问题。但部署到服务器后路径不存在或者没权限就会报错。更稳妥的做法是把上传路径做成可配置的写在application.yml里部署时按需修改同时要保证上传目录有写权限Linux下可以用chmod 755 /data/upload设置。6.4 常见问题速查表问题现象可能原因处理办法启动报数据库连接失败数据库地址/账号/密码错误或时区未设置核对application.yml配置URL加serverTimezone接口返回401token缺失或过期清理本地缓存后重新登录检查请求拦截器前端请求跨域被拦截后端未配置CORS后端添加CORS配置类或前端配置dev proxy图片上传失败请求格式不对或服务器路径无权限检查请求头改用multipart格式配置可写路径菜品列表显示不出来字段名对不上或数据未加载用浏览器F12看接口返回对照字段名端口被占用本机其他进程使用同一端口改端口号或kill占用进程菜单显示不完整当前用户角色未绑定对应菜单用管理员账号登录在角色管理中绑定菜单结账金额不对使用了浮点类型存储金额检查表结构金额字段是否为DECIMAL7. 项目扩展与实际落地建议7.1 从毕设到项目还能怎么加功能如果时间充裕我建议在现有基础上加一两个亮点功能这会让你的毕设从“完成”升级为“优秀”。加一个Redis缓存。当前菜品分类和菜品信息是每次直接查数据库的数据量大了之后接口响应会变慢。引入Redis后把菜品列表缓存起来设置过期时间比如30分钟菜品变更时主动清掉缓存。这个“缓存穿透、缓存失效”的内容在答辩时可以讲出一套完整的故事非常能体现技术水平。加一个WebSocket实时通知。餐厅场景里客人下单后后厨的屏幕上应该实时弹出新订单提醒。用WebSocket实现服务端主动推送前端页面收到消息后自动刷新订单列表。这种“实时性”是前后端分离架构的经典应用场景技术栈里加一个WebSocket整个系统的完整性立刻提升一个档次。加一个数据导出功能。报表统计只停留在页面展示不算完整。用EasyExcel导出Excel报表老板可以把每天的营业数据下载下来做二次分析。EasyExcel是阿里开源的性能好、使用简单而且在简历上是个常见的技能点。7.2 上线部署的核心要点如果这套系统不只要交毕设而是真的要在小餐厅跑起来有几个部署要点值得提前考虑。前端构建打包。在Vue项目目录下执行npm run build生成dist静态目录把dist目录上传到服务器的Nginx静态目录下配置一个server块root指向dist目录即可。后端打成jar包用java -jar命令启动也可以注册成systemd服务开机自启。Nginx的配置既要托管前端静态资源也别忘了反向代理后端接口。一个典型的配置是这样监听80端口location /指向dist目录location /api/ { proxy_pass http://127.0.0.1:8081/; }把/api开头的请求转发给后端的SpringBoot服务。这种部署方式把前后端整合到了同一个域名下也顺带解决了跨域问题。数据库和备份。生产环境的MySQL记得设置好账号权限不要用root跑业务。定期备份数据库最简单的方式是写一个crontab定时任务每天凌晨用mysqldump导出SQL文件保留最近7天的备份。7.3 给初学者的学习路径建议最后聊点实在的。如果你拿着这套源码不知道怎么下手去学我建议按顺序做下面四步。先用起来。搭好环境导入SQL脚本启动后端和前端把系统的每个功能点都点一遍。这一步的目标是建立“整体感知”知道系统有哪些页面、每个页面能干什么、数据是怎么流转的。再理结构。对照接口文档从前端页面出发逐步追踪到后端接口、Service层、Mapper层把一条完整的请求链路打通。比如“菜品列表是怎么从数据库到页面上的”把这一个链路读懂了其他模块基本都是类似的套路。然后改功能。找一个你感兴趣的模块尝试加一个小功能。“菜品管理”加一个“批量上架”或者“报表统计”加一个“按周统计”改的过程中你会自然理解哪些地方需要修改哪些地方耦合度比较高这才是调试能力成长最快的时候。最后静下心思考设计。问问自己为什么用JWT而不用Session为什么用RBAC模型做权限为什么金额字段用DECIMAL这些“为什么”才是面试官真正关心的东西也是你比别人多出来的核心竞争力。源码可以抄思路必须自己消化。我在实际跑这个项目的过程中最大的体会是一套完整的项目源码真正的价值不在于“能跑”而在于它是你理解整套技术栈如何协作的最佳教材。把前端、后端、数据库、接口文档这条链上每一个环节都亲手打通你的Java Web水平会上一个真正的台阶。拿到源码的朋友别急着炫技加功能先顺着业务把代码读通这是最快的学习路径。