每到毕业季我都能收到一堆类似的私信“学长毕设选题是SpringBootVue的网上订餐系统感觉不难但真打开IDEA又不知道从哪下手数据表怎么建”“前后端分离项目怎么部署答辩的时候老师问购物车逻辑怎么办”这篇文章就是写给准备做、正在做这类SpringBootVue全天候/网上订餐系统的同学。基于标题里反复出现的三个关键词——网上订餐、智慧餐饮在线点餐平台、云餐厅即时订餐系统我按自己带项目上岸的经验把从需求分析、数据库建模、接口设计到本地联调、服务器部署的完整链路拆开揉碎讲清楚。内容覆盖管理员端、商家端、用户端三端功能适配数据库设计、后端技术点、前端工程化以及答辩时最容易被追问的几个技术细节保证你能看懂、能上手、能复现。1. 需求边界一个“网上订餐系统”到底要做哪些事很多同学拿到这个题目第一反应是“不就是点菜下单吗”结果一开写就失控——今天想加优惠券明天想接入实时配送追踪最后项目做了一堆半成品功能数据库里躺了二十几张互相对不上的表。我建议先从真实业务里抽离出三条最核心的主线。1.1 三条业务主线用户点餐、商家接单、平台管理用户端是系统面对C端消费者的核心流程如下注册登录 → 浏览菜品分类、搜索、详情 → 加入购物车 → 提交订单 → 在线/到店支付 → 查看订单状态 → 催单或申请退款。这部分不难点但容易忽略的是菜品列表的展示维度用户进入的是哪一个店铺是否区分堂食自取和外卖配送配送订单要填地址、自取订单只需确定取餐时间这两种订单在数据库里建议用同一个字段区分也可以拆表后面我会细讲。商家端解决的是“店老板怎么赚钱”的问题核心是菜品管理上下架、库存、价格、图片、订单处理接单/出餐/完成、经营概览今日订单数、营收、热销菜品。大多数毕设会把商家端和管理员端合并成“后台”但从答辩角度我建议把“角色”设计清楚管理员管平台商家管店铺用户管自己的订单。哪怕你用同一个前端工程也要在路由权限上做隔离。平台管理端包括用户管理封禁/解禁、商家审核入驻/停业、菜品分类管理、所有订单的查看与统计。这三条主线明确之后你再回头填细节会发现整个系统做什么、不做什么边界非常清晰。1.2 功能做加法之前先做减法订餐系统的难点不在功能多而在状态流转订单状态从“待支付”到“已支付”到“商家接单”到“制作中”到“配送中/待取餐”到“已完成”到“已取消/退款”每一个状态变更背后都有对应的逻辑、操作入口和数据库字段变化。这个状态机理清楚系统就成立理不清楚页面再多也是空中楼阁。所以我的建议是第一版只做MVP功能——用户下单、商家出餐、管理员管理支付直接用模拟接口后端生成一个“已支付”状态即可。优惠券、积分、配送策略这些都放到“后续扩展”里写进文档不要一开始就铺开。答辩时老师问你怎么扩展你有完整的设计思路就行这比做出一堆半成品更有说服力。2. 技术选型落地SpringBoot版本、Vue2还是Vue3、数据库怎么定这个标题表面看是“技术组合”但真正让毕业生栽跟头的往往是技术选型的细节SpringBoot版本太高和某些依赖冲突、Vue3配套的组件库和教程不一致、前后端分离项目不知道怎么部署。这里给出我实测下来最稳妥的组合以及“为什么这么做”。2.1 SpringBoot版本怎么定别追新用2.7.x最省事我见过太多同学一上来就创建SpringBoot 3.x项目然后栽在javax转jakarta、Redis配置变化、Spring Security 6的写法差异上。如果你做毕设SpringBoot 2.7.x是最稳妥的版本——它兼容市面上绝大多数教程和依赖网上搜问题也好搜。相关热搜词里很多人问“springboot版本太高怎么办”这背后就是版本迁移踩坑后的求助。具体依赖以Maven为例parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent需要说明的是如果你的JDK是1.8SpringBoot 2.7.x没问题如果你本机装了17那直接用它也没问题。但如果你非要踩新版本做好心里准备网上搜到的不少教程里SpringSecurity、MyBatis-Plus的写法和SpringBoot 3.x对不上。2.2 Vue2还是Vue3新项目直接用Vue3 Element Plus我知道很多网课还在教Vue2但新做的项目没有任何理由选择Vue2。Vue3 Vite Element Plus如果做PC端管理平台 Vant如果做移动端点餐是当前的主流组合这套组合在GitHub上也有大量现成的后台管理模板可以参考省下很多造轮子时间。一个常见的困惑是“Vue3一定比Vue2难吗”其实正好相反Vue3的组合式APIComposition API对毕设非常友好逻辑复用比Vue2的Options API直观得多比如购物车的总价计算、多个页面共享用户登录状态用setup语法写起来很清晰。热搜词里的“vue安装及环境配置”“idea创建springboot项目”这些多半是新手卡在脚手架搭建上。我的建议前端工程用Vite脚手架后端用IDEA自带Spring Initializr两边分端口启动走代理联调。2.3 数据库与中间件MySQL 8够用Redis要不要挂毕设场景下数据库用MySQL 8注意是8不是5.7很多Vector索引、JSON字段要用到ORM选择MyBatis-Plus——它能极大省去CRUD的XML编写而且它的LambdaQueryWrapper写条件查询非常顺手搜索菜品、过滤分类这类需求不用手写SQL。Redis要不要加我的建议是如果你的答辩时间充足加上Redis做缓存和会话维持会是很漂亮的加分项。但如果你对Redis不熟宁可不用也别硬加——老师追问“Redis缓存了哪些数据、怎么保证一致性”时答不上来反而扣分。如果决定用典型用途是菜品分类列表缓存、用户登录Token的刷新次数限制、手机验证码存储如果有接验证码接口。这三个场景都是Redis的舒适区比生硬地缓存一堆表合理得多。3. 数据库建模把订单、菜品、购物车的关系一次想透这一部分我直接给出我常用的一套表结构设计也是我当年做类似点餐系统时实际的表关系。这里有一个容易被低估的乱点“关联查询表字段怎么设计才能避免后期写SQL找来找去”原则很简单主键自增int/long搞定不要用UUID做主键时间字段统一datetime金额字段一律decimal(10,2)不要用double/float——涉及金额怎么可能用浮点数。3.1 用户、商家、分类、菜品四张基础表的字段设计用户表t_userid、username、passwordBCrypt加密存储、real_name、phone、avatar、role区分管理员/商家/普通用户可以用枚举字符串、status启用/禁用、gmt_create、gmt_modified。角色字段很重要后面权限拦截全靠它。商家表t_merchantid、user_id关联用户表一个商家账号对应一个user记录、name、address、logo、notice公告、business_hours、status营业/打烊、gmt_create。如果你不想做“多商家平台”也可以把这表合并到用户表里加几个字段。但毕设的话我个人建议还是拆出来因为“平台入驻商家”是一个清晰的分支拆出来表关系更明确。分类表t_category):id、merchant_id如果是多商家系统分类归属商家如果是单店系统可以去掉、name、sort、status。菜品表t_productid、merchant_id、category_id、name、description、price、image、stock库存量0或-1表示无限、status上架/下架、sale_num销量统计、gmt_create、gmt_modified。菜品表注意要存image字段按实际路径存字符串别想着直接存Base64图片数据库会很膨胀后期接口返回速度肉眼可见地慢。3.2 购物车放后端还是前端订单与订单明细必须拆开购物车有一个经典问题把购物车数据存到数据库后端还是存localStorage前端我的建议是——毕设系统里购物车放前端localStorage就够理由有三用户点餐场景下单频次低不需要实时同步购物车到服务端省去一张购物车表和相关CRUD接口工程量直接减小购物车状态本质是“用户本地操作中间态”不影响数据一致性。但如果你为了展示Table的关联能力非要做后端购物车表t_cartid、user_id、product_id、quantity也行但记得加一个user_id product_id的唯一索引避免同一个用户重复插入同一道菜。**订单表t_order和订单明细表t_order_item**必须拆分这是数据库规范里的一个坎也是答辩老师常盯的点。订单表存整体信息id、order_no唯一业务单号、user_id、merchant_id、total_amount总金额、pay_amount实付金额、status状态机建议用数字加注释0待支付/1已支付/2已接单/3配送中或待自取/4已完成/5已取消、pay_type支付方式、consignee_name、consignee_phone、consignee_address配送地址自取可留空、remark、gmt_create、gmt_pay、gmt_finish。订单明细表存商品快照信息id、order_id、product_id、product_name、price、quantity、total_price。为什么要冗余product_name和price因为菜品可能被修改/下架订单需要保留下单时的快照——如果在订单明细表里只存product_id到时候反查菜品价格可能已经是改过的价格业务上容易出问题。3.3 库存扣减与事务别在小项目里埋大坑点了菜品下单之后要不要扣减库存建议下单时扣减、取消订单时回补并且这段逻辑必须放在一个事务里用Transactional保证原子性。Transactional(rollbackFor Exception.class) public Order createOrder(CreateOrderRequest req) { // 1. 根据购物车/点菜列表构造订单明细 // 2. 计算总金额 // 3. 插入t_order状态0待支付 // 4. 插入t_order_item批量 // 5. 扣减菜品库存 // 6. 返回order_no前端跳转“去支付” }这里一个细节库存扣减不要先SELECT再UPDATE而是用一条原子UPDATE语句比如UPDATE t_product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}如果影响行数为0说明库存不足直接抛出异常。答辨时这句话说出来老师会知道你懂并发控制。4. 后端接口与工程细节JWT鉴权、全局异常、XSS过滤后端这块是毕设的工作量重头但也是很多网课讲得不透的地方。我按实际开发的顺序给你走一遍顺手把热搜里的几个高频坑都交代了。4.1 登录认证JWT还是Session怎么拦截接口权限SpringBootVue前后端分离的项目Session天然不友好跨域、分布式场景限制多现在的主流选择是JWTJSON Web Token。整体思路是用户登录成功后后端生成Token里面包含userId、role等信息设置过期时间比如72小时返回给前端前端存localStorage并在每次请求时携带在请求头Authorization里后端通过拦截器HandlerInterceptor统一解析校验Token无效或过期直接返回401。Token生成我还是推荐用现成库java-jwt或jjwt不要自己拼字符串。一个典型的拦截器核心逻辑public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod false) { return true; } String token request.getHeader(Authorization); if (token null request.getParameter(token) ! null) { token request.getParameter(token); } if (token null) { response.setStatus(401); return false; } try { DecodedJWT jwt JWT.require(Algorithm.HMAC256(secret)) .build().verify(token.replace(Bearer , )); // 将用户信息放入request Long userId jwt.getClaim(userId).asLong(); String role jwt.getClaim(role).asString(); request.setAttribute(userId, userId); request.setAttribute(role, role); return true; } catch (JWTVerificationException e) { response.setStatus(401); return false; } }拦截器注册到WebMvcConfigurer时要设置白名单/api/login、/api/register、/api/products/**菜品浏览可以不用登录或者用户必须登录也可以看你系统要求。权限控制方面接口层可以用角色标识判断比如管理员接口要求role为ADMIN商家接口要求role为MERCHANT写一个简单的自定义注解 拦截器判断即可。这样既能做权限区分代码量又不至于膨胀到引入Spring Security这么重。4.2 统一响应结构与全局异常处理前后端分离时接口返回格式必须统一我惯用的格式是ResultTcode、message、data这样前端Axios拦截器就能统一处理成功/失败逻辑public class ResultT { private Integer code; // 200成功500失败401未登录 private String message; private T data; // 静态方法 ok(), error(), error(msg) }配合**RestControllerAdvice**做全局异常处理好处非常明显字段校验异常、数据不存在异常、库存不足异常、Token异常全部在全局异常处理器里转换为规范的Result返回而不是层层try-catch之后还是杂乱的返回格式。这是个加分项而且代码量不过几十行强烈建议加上。4.3 XSS过滤在文件上传场景里的坑重点避雷这是个热搜词里的实际关键词“springboot项目全局过滤器处理上传pdf文件时xss攻击”——我简单说一下背后发生了什么。很多SpringBoot项目为了防XSS攻击会写一个全局过滤器Filter把所有请求的参数都替换掉HTML标签。如果对上传文件的multipart/form-data或PDF文件流做同样的“字符串替换”很容易把文件字节流破坏掉或者直接抛出类型转换异常。正确做法是过滤器仅对JSON文本或表单文本字段做转义处理对文件上传的请求跳过参数清洗对文件类型做白名单校验。具体实现有两种思路用HttpServletRequestWrapper包装请求重写getParameter/getHeader方法对字符串参数统一转义输出如果你的参数都是JSON格式可以使用Jackson的ObjectMapper配置转义或在Controller里统一处理字符串字段。我的经验是不要在过滤器里对整个InputStream做read再转义InputStream只能读一次你动了它后续Controller就取不到参数了。这也是这个坑最容易让人卡住的原因。在毕设里防SQL注入用MyBatis-Plus预编译就够了XSS过滤能借接口对文本字段做HTML转义即可不要过度设计。4.4 防重复提交一个看着小却很实用的功能用户点击“提交订单”时机不是一瞬间网络卡顿、双击按钮都可能导致同一条订单被创建两次。前后端同时防前端把按钮在提交中转圈禁用后端用Redis或本地内存来防重复提交——核心思路是在请求进入时拿一个业务唯一Key比如用户id菜品加类型时间戳生成的签名或直接用订单提交幂等键去Redis设值成功才能往下走否则拒绝。如果你没接Redis也可以用本地并发下的Map做简易版本。但注意SpringBoot默认多线程直接用HashMap会出并发问题建议用ConcurrentHashMap或者加上synchronized。这不难但在答辩现场算是很实在的“亮点”。5. 前端工程化Vue3项目结构、路由懒加载、Axios封装前端这块做到什么程度算合格我见过太多直接把大杂烩Script写在单文件里页面跳来跳去没有统一入口最后项目没法维护。这里我推荐一套结构清晰、可直接抄的Vue3前端工程化方案。5.1 Vue工程目录划分一个管用户端一个管后台前端建议拆两层用户端点餐界面偏移动端风格 管理端后台表格PC端风格。两者各做一个layout壳内部用路由嵌套。如果你为了省事儿也可以放一个工程里用不同路由地址区分。作为毕设我更推荐用一个Vue3工程加两套layout入口页根据用户角色跳转。典型目录结构Vite项目src/ api/ # 接口请求模块 auth.js product.js order.js assets/ # 静态资源 components/ # 公共组件 layout/ UserLayout.vue # 用户端布局 AdminLayout.vue # 后台布局 views/ user/ Login.vue Home.vue Cart.vue OrderList.vue admin/ Dashboard.vue UserManagement.vue ProductManagement.vue OrderManagement.vue router/ index.js # 路由表 守卫 store/ # Pinia 状态管理 utils/ request.js # Axios实例路由需要配置懒加载让首页不用加载所有页面的JS。Vue3用router.beforeEach做登录守卫统一判断“有没有token、是不是要跳过白名单、用户角色是否允许访问当前菜单”。5.2 Axios封装请求和响应拦截器这样写才对我见过不止一个同学在每个页面里直接axios.get一遍没有统一封装导致每次都要重复处理登录过期、错误提示。正确做法是一个utils/request.js里创建独立的Axios实例import axios from axios const request axios.create({ baseURL: /api, // 走Vite代理不要写死http://localhost:8080 timeout: 10000 }) // 请求拦截器 request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer token } return config }) // 响应拦截器 request.interceptors.response.use( response { const res response.data if (res.code 200) { return res } if (res.code 401) { // 登录过期 localStorage.removeItem(token) window.location.href /login return Promise.reject(new Error(未登录)) } return Promise.reject(new Error(res.message || 请求失败)) }, error { return Promise.reject(error) } ) export default request这里有个关键点baseURL写/api通过Vite的proxy代理转发到后端避免开发时跨域报错。Vite配置文件vite.config.js里加server: { proxy: { /api: { target: http://localhost:8080, // SpringBoot接口地址 changeOrigin: true } } }这样后端接口路径统一带/api前缀即可开发时无需开启后端CORS但如果你本地往往还会打开SpringBoot的跨域配置也无妨只是生产环境建议走代理。5.3 状态管理购物车到底放Pinia还是localStorage配合前面说的“购物车存前端”的建议缓存方案是Pinia中维护购物车响应式数组每次变更后同步一份到localStorage下次进入页面重新加载。这样用户的购物车刷新不丢失、退出浏览器再进还在前端体验很好后端不用维护购物车表。核心逻辑state: cartList: [{productId, name, price, image, quantity, stock}]getter: cartTotal总价、 cartCount总数量action: addToCart、removeFromCart、clearCart这个设计有一个额外好处——用户端点餐页和后端接口解耦购物车操作即时响应没有网络延迟体验远好于每次点菜都调后端接口。6. 联调、部署与避坑从本地跑通到服务器上线的完整闭环很多同学到这一步就开始慌了前后端分离项目怎么部署怎么在服务器上同时跑Vue和SpringBoot“怎么将springboot jar反编译成项目”这种热搜词也印证了很多人在拿到项目压缩包后的第一步就搞反了方向。6.1 三套部署方案按你的精力选方案A毕设演示最省事本机全栈联调后端在IDEA里运行8080端口前端npm run dev5173端口。演示时两个窗口开着即可。注意因为前端走Vite代理图片上传和访问要处理好——后台上传的图片如果存到本地磁盘前端在另一个端口无法直接访问建议前端访问路径也通过/api代理或者图片路径返回相对地址。方案B单体服务器部署适合答辩展示前端npm run build打包生成dist目录交给Nginx托管后端mvn clean package打成jar包用java -jar xxx.jar运行。Nginx配置里设置server { listen 80; server_name 你的域名或IP; location / { root /usr/local/dist; # 前端静态文件 try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } }注意前端history路由模式去掉#号需要try_filesFallback到index.html否则刷新页面会404。这个问题是新手高频翻车点。方案CDocker Compose加分项能写就写进文档三个容器——MySQL、SpringBoot、Nginx前端打包成镜像/或者直接卷挂载。写一个docker-compose.yml通过网络互访。这个答案跑通一次之后会上瘾以后做任何项目都用这套。热搜里的“docker部署springboot项目”也是同样的知识点。6.2 一个必须提前处理的问题跨域与图片上传前后端分离联调中最常见的报错就是跨域CORS。上面我提过Vite代理是开发期方案但在生产环境前端已经部署到Nginx里因为不再走Vite所以需要用Nginx反向代理把/api转发到后端这是最稳妥的。如果后端必须开启跨域则推荐用CrossOrigin注解加在Controller类上或者全局配置CorsFilter但这只适合开发期正式上线要依赖代理不然安全性堪忧。图片上传是另外一个坑SpringBoot的multipart上传设置默认单文件1MB调试上传菜品图片时经常报“FileSizeLimitExceededException”。在配置类或application.yml里设置spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB另外上传后的图片存储路径要配置为真实磁盘路径并通过一个/upload/**静态资源映射暴露出去前端才能访问到。6.3 实战踩坑清单这些坑我已经替你趟过了以下是我和历届学弟踩坑后沉淀下来的清单基本覆盖了毕设周期内最常见的“问题-根因-注意事项”错误1创建SpringBoot项目时选择了3.x版本然后发现MyBatis-Plus、BeanUtils的import全变了。解法是统一用2.7.18mybatis-plus-boot-starter选3.5.x的对应版本。错误2本地联调开启Vue后请求报401但后端单独测试接口没问题。根因往往是Token没带或JWT校验时不过滤预检OPTIONS请求。解法在拦截器里对OPTIONS请求放行否则浏览器跨域预检就会失败。错误3数据库表名/字段名和Java实体对不上。我建议所有字段在数据库里用下划线命名gmt_create在Java里用驼峰命名gmtCreate并在MyBatis-Plus中开启驼峰映射configuration.map-underscore-to-camel-case: true。错误4订单取消或退款之后忘记回补库存。这个问题只在测试后期才会暴露——点完菜取消几次后菜品库存越来越少。解法是在状态变更的所有分支取消/超时未支付统一做回补。错误5前端打包后图片路径404。原因是Vite构建时相对路径问题。解法base: ./配上同时图片资源用绝对路径或代理路径访问别用相对路径。错误6用DTO、VO时直接拿Entity往响应里塞把用户密码字段也返回给了前端。至少要做到设置JsonIgnore更建议用VO类隔离字段——这也能体现你对安全的意识。错误7如果拿到别人项目第一反应想看“反编译jar”——这个方向就错了。正确方法是找源码压缩包对老项目先看pom.xml或build.gradle早期项目可能是Gradle配置确定版本依赖后再起服务。胡乱反编译只会得到一堆混淆逻辑并不会让你真正理解系统设计。7. 答辩时最容易被追问的四个技术点以及怎么答作为有实战经验的博主我想额外多写几段因为毕设不只是代码的事——答辩时的表达往往决定了评价高低。老师会挑几个技术追问提前准备好回答思路比代码跑通更稳。7.1 “为什么选JWT而不是Session”——要说出取舍这个问题基本必问。回答思路前后端分离项目前端可能部署在Nginx、后端可能在另外的服务器Session方案依赖Cookie传递且不好跨域JWT无状态、服务端不用存登录状态更适合接口化架构。但隐含缺点要说出来JWT无法主动吊销、载荷别存敏感信息。主动说明局限反而能展示你真的懂。7.2 “订单状态是怎么流转的”——要背出状态机答状态字段用数字枚举0待支付 - 1已支付 - 2商家接单 - 3配送/自取 - 4完成任何状态下可以走5已取消/退款。每个状态变更都有独立的方法pay、cancel、complete事务保证一致性。能画个人工状态图更好但注意别画不知道的技术图简单手写状态即可。7.3 “购物车为什么放前端”——要说出业务判断答购物车是本地临时操作不依赖服务端实时数据放前端减少数据库压力用户未下单前的操作不持久化。下单时再把购物车数据一次性提交给后端生成订单。这就够了。如果老师追问“多个设备购物车不同步怎么办”——回答可以在扩展版本中通过后端购物车表或Redis解决。7.4 “项目是前后端分离部署是怎么解决的”——要完整说链路答前端构建静态资源部署NginxNginx反向代理/api到SpringBoot服务MySQL独立容器或本机进程。生产环境用Nginx代理解决跨域开发环境用Vite proxy。这样陈述清晰又有一定完整性。最后再分享一个小技巧如果你打算把这个项目再往上走一步可以把它扩展成“扫码点餐 堂食号牌叫号”或者“对接小程序端”这样的小型智慧餐饮场景新增的需求其实都建立在你已经做好的用户、菜品、订单三张核心表上后端接口复用率极高数据结构不用大改。这也是网上订餐系统这个题目最大的价值——它虽然不炫技但把前后端分离项目的关键链路都覆盖到了而且每一步都有明确的位置可以继续深挖。希望这篇整理能帮你把这个项目真正做扎实也祝答辩顺利。