做点餐系统这个选题其实挺有意思的。它不是那种纯教学用的玩具项目——餐厅点餐本身就是真实业务场景涉及商品展示、购物车、订单状态机、支付对接、库存扣减这一整条链路做完以后几乎能把前后端开发的主要知识点都串起来。我前前后后带过不少同学做类似的东西Spring Boot Vue 这套组合是出现频率最高的后端生态成熟前端组件库丰富招人市场上需求量也大更重要的是这套技术栈的资料和踩坑记录足够多真卡住了不至于求告无门。这篇东西就从设计思路、核心模块、实操细节到调试部署完整撸一遍我以为的点餐系统该怎么做以及做的时候哪些地方值得多花心思。1. 项目整体设计与技术选型思路1.1 为什么是 Spring Boot Vue 而不是别的组合先说后端。Spring Boot 在中小型系统里的优势不是“性能最强”而是“约定优于配置”带来的开发效率。点餐系统这种业务谈不上高并发、海量数据核心诉求是业务逻辑清晰、接口稳定、方便扩展。Spring Boot 的自动配置能省掉一堆 XML 配置的工夫内嵌 Tomcat 也让部署变成“一个 jar 包丢上去就跑”特别适合课程设计和中小型商业项目。前端这块Vue 的学习曲线相对平缓组件化开发方式特别贴合点餐系统的界面特征——菜品卡片、购物车、订单列表拆成组件以后复用和维护都很顺畅。加上 Element UI 这样的组件库表格、表单、弹窗这些后台管理页面需要的元素几乎都能直接拿来用能把更多精力放在业务逻辑上。这套组合还有一个隐性优势前后端分离的开发模式。后端专心出接口前端专心做页面两边用 JSON 交互天然适合团队分工——哪怕是一个人做也能把关注点拆开后期调试定位问题会省力很多。1.2 系统功能模块怎么划分才合理一个完整的餐厅点餐系统我习惯分成三个端来设计用户端微信小程序风格或 H5 页面用户注册登录、浏览菜品、按分类筛选、加入购物车、下单、查看订单状态、取消订单。商家端后台管理页面菜品管理增删改查、上下架、分类管理、订单处理接单、出餐、完成、菜品的库存/销量统计。管理端可选扩展用户管理、订单总览、数据看板、权限控制。这种三端划分不是拍脑袋。做系统设计最忌“眉毛胡子一把抓”把用户操作和后台管理混在一个界面里代码很快就会乱。前后端分离架构下三个端共用同一套后端接口只是前端路由和数据权限不同这个思路对后期的扩展非常友好——比如以后想加一个外卖配送模块只需要在用户端加一套地址和骑手接口后端扩展对应的 service 就行。1.3 技术选型时要避免的几个坑第一不要一上来就引入微服务、Redis、消息队列这些重组件。点餐系统的核心是业务闭环不是技术表演。初期老老实实用 MySQL Spring Boot 单应用把业务逻辑做扎实比堆一堆中间件然后跑不起来强得多。第二鉴权方案别用复杂的 Spring Security 全量配置。很多人一看到 Spring Security 的过滤器链就头大配了半天还在 403。实际做这个项目用 JWTJSON Web Token做一个轻量级拦截器就够了——登录后签发 token前端请求时带上后端拦截器校验。逻辑清晰代码量小还方便讲清楚原理。第三前端构建工具统一用 Vue CLI 或者 Vite版本别混着来。Vue 2 和 Vue 3 的生态差异很大Element UI 和 Element Plus 也分别对应不同版本组合错了项目直接跑不起来。我在带项目时最怕听到的就是“我照着网上的教程配怎么报错了”——大概率就是版本组合问题。2. 数据库设计与核心表结构拆解2.1 核心表到底需要哪几张餐厅点餐系统的数据库设计不是我自夸下面这套表结构可以说是我在做了几次类似项目后总结出的最实用方案。一共就这几张核心表表名职责关键字段说明users用户信息id, username, passwordBCrypt 加密, phone, avatar, rolecategory菜品分类id, name, sortdish菜品信息id, category_id, name, price, image, description, status1上架/0下架cart购物车id, user_id, dish_id, quantityorders订单主表id, order_no, user_id, total_amount, status, create_time, pay_timeorder_detail订单明细id, order_id, dish_id, dish_name, dish_image, price, quantityaddress可选配送地址id, user_id, detail, phone, is_default这套表的思路要点在于购物车和订单拆分成了“临时态”和“正式态”。购物车里的数据是可以随便改、随便删的订单一旦生成所有信息必须快照固化。所以 order_detail 里不光存 dish_id还把 dish_name、price 冗余了一份——防止商家改了菜品价格后历史订单的金额跟着变这是新手最容易漏掉的一个设计点。2.2 关键字段设计的细节与原因订单号不能直接用自增 id。对外展示的订单号一般会用“日期 随机数”或“日期 递增序列”的格式比如20250607123456789。这样既方便用户和商家沟通也能从订单号直接看出下单时间。实现上可以在后端生成避免前端伪造。金额字段用 Decimal 而不是 Float/Double。这不是矫情——浮点数运算丢精度的问题在涉及“元”和“分”转换时尤其明显。Java 后端用BigDecimalMySQL 用DECIMAL(10,2)前端展示时再格式化。这个习惯养成了以后做任何涉及钱的系统都不会吃大亏。订单状态用 tinyint 还是 varchar我自己的习惯是用 varchar 存状态描述比如PENDING、ACCEPTED、COMPLETED、CANCELLED。优点是看数据库就知道状态排查问题方便缺点是稍微占点存储。对于点餐系统这种量级的项目可读性远比省那几字节重要。软删除菜品、分类这些基础数据不要物理删除。加一个is_deleted字段查询时默认过滤。原因很简单菜品被下单过以后订单明细里引用了它的 id 和名称物理删了会导致历史数据对不上你的“数据统计”模块就全废了。2.3 下单时库存和菜品状态校验菜品表最好加一个stock字段库存数量-1 表示不限。下单时要校验菜品是否还在上架状态status 1。库存是否足够。通过UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这种乐观更新方式扣减库存。最后一步是关键用条件更新防止超卖。虽然点餐系统并发量不高但这个写法是个好习惯——用数据库的行锁天然避免并发问题比先查出来判断再更新安全得多代码也就多一行。3. 后端核心模块的实现细节与实操要点3.1 项目目录结构与分层后端包结构我用标准的三层架构com.xxx.restaurant ├── controller # 接口层 ├── service # 业务层 │ ├── impl │ ├── UserService │ ├── DishService │ ├── OrderService ├── mapper # 数据访问层MyBatis-Plus ├── entity # 实体类 ├── dto # 数据传输对象 ├── vo # 视图对象 ├── config # 配置CORS、JWT拦截器 ├── common # 通用工具、统一返回结果、异常处理分层最重要的是职责分离。Controller 只做参数接收和结果返回业务逻辑全部放在 Service 层mapper 只管 SQL。这样代码的可读性、可测试性都大幅提升。3.2 统一返回结果与全局异常处理前端和后端约定一套统一的响应格式这点非常重要{ code: 200, message: success, data: { } }用泛型定义一个ResultT类code 为 200 时表示成功其余为各种业务异常。配合RestControllerAdvice写一个全局异常处理器业务代码里抛出带错误码的BusinessException前端统一拦截处理提示信息——这样后端 Controller 里的 try-catch 可以全部去掉代码会清爽很多。这个习惯我几乎在每个项目里都会强调它带来的直接好处是前端只需要在 axios 的响应拦截器里统一处理一次错误提示不需要每个接口单独处理异常场景。3.3 JWT 登录鉴权的完整流程登录流程其实很简单用户提交用户名/密码。后端通过BCryptPasswordEncoder校验密码注意密码不能明文存储。校验通过后用jwt工具类生成 token里面放入用户 id 和用户名设置过期时间一般 7 天。前端把 token 存在 localStorage 或 Pinia/Vuex 中后续请求在请求头加Authorization: Bearer token。后端写一个拦截器HandlerInterceptor对需要登录的接口如购物车、订单操作校验 token。需要注意拦截器要把登录接口、菜品列表这些公开接口排除掉。校验解析后的用户信息怎么传给 Controller我习惯用一个 ThreadLocal 的静态工具类做用户上下文——在拦截器里解析完 token 放进 ThreadLocal后续 Controller 和 Service 都能从这里拿用户 id。注意请求结束后要在拦截器的 afterCompletion 里 remove防止线程池复用导致的数据串号。3.4 下单接口的业务逻辑编排下单是核心接口也是最能体现代码水平的地方。要在一个事务里完成Transactional public Order createOrder(OrderCreateDTO dto) { // 1. 创建订单主表记录计算总金额 // 2. 批量校验菜品状态和库存 // 3. 扣减库存 // 4. 批量插入订单明细 // 5. 清空购物车 // 6. 返回订单详情 }Transactional保证要么全部成功要么全部回滚。其中第 2、3 步要复用 DishMapper 的方法避免在 Service 里通过 for 循环单独查数据库批量查询一次出来再内存标记性能更好代码也更好测。3.5 排行榜和统计怎么实现点餐系统都会加一个“销量排行”或“热销榜单”。这个直接用 SQL 统计就行后端写一个统计接口SELECT dish_id, dish_name, SUM(quantity) AS total FROM order_detail WHERE create_time BETWEEN ? AND ? GROUP BY dish_id, dish_name ORDER BY total DESC LIMIT 10注意点统计的是 order_detail 而不是菜品表的销量字段。这也是为什么前面强调下单时要在明细表里冗余菜品名称——有了快照统计就永远正确。如果把销量冗余在菜品表里每次下单去 update一旦出现并发或事务回滚数据就乱了。4. 前端 Vue 的实现思路与页面拆解4.1 项目结构与路由前端项目结构我习惯按业务模块划分src/ ├── api/ # 接口请求封装 │ ├── user.js │ ├── dish.js │ ├── order.js ├── assets/ ├── components/ # 通用组件 │ ├── DishCard.vue │ ├── CartPanel.vue │ └── ... ├── router/index.js ├── store/ # Pinia/Vuex │ ├── modules/cart.js │ └── modules/user.js ├── views/ │ ├── Home.vue │ ├── DishList.vue │ ├── OrderList.vue │ ├── Login.vue │ └── admin/ # 后台管理页面路由用 Vue Router需要区分两类不需要登录的登录页、菜品浏览页和需要登录的购物车、订单、后台管理。在路由前置守卫里做登录校验判断 localStorage 里有没有 token以及要去的路由是否在免登录白名单里。这里的细节是管理员路由和普通用户路由要区分权限。路由表里通过 meta.roles 标记守卫里解析 token 里的角色信息判断是否有权限。前端只是做展示控制后端的接口权限拦截才是真正的安全防线。4.2 axios 封装与请求拦截不封装 axios 的项目会很痛苦。统一的封装做三件事// api/request.js const service axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器自动携带 token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理 code service.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message) // 401 处理跳转登录页 return Promise.reject(new Error(res.message)) } return res.data }, error { // HTTP 层错误统一处理 ElMessage.error(网络异常) return Promise.reject(error) } )baseURL 设为/api配合后端 CORS 配置或前端 dev server 的代理可以避免开发环境的跨域烦恼。这一步是新手最容易卡壳的点我在常见问题里会单独讲。4.3 点餐核心页面菜品列表 购物车点餐页面我分成两个主要组件左侧分类菜单 菜品卡片列表右侧悬浮购物车栏。菜品卡片用 Element Plus 的el-card 自定义插槽展示图片、名称、价格、销量。加入购物车按钮触发cartStore.add(dish)购物车状态用 Pinia 管理。为什么购物车要放全局 store 而不是组件本地状态因为“加入购物车”和“提交订单”不是同一个页面甚至可能在路由切换后仍需保留状态。用 Pinia 管理后只要不刷新页面购物车数据就一直在内存里再配合 localStorage 持久化刷新也不丢。购物车里展示数量加减和删除很重要每改一次数量都要同步计算总价。计算属性里computed做总价统计就行Vue 的响应式会自动更新。4.4 后台管理页面的实现要点后台管理页面对新手来说最容易困在“表格 弹窗 表单校验”的循环里。用 Element Plus 等于开了个挂el-table绑定数据源el-dialog里放el-form表单校验规则用rules属性声明式配置。菜品管理的核心操作就是页面加载时调用getDishList()接口表格显示。点击“新增”打开 dialog清空表单提交时调用“新增接口”。点击“编辑”打开 dialog回填表单数据提交时调用“更新接口”。点击“删除”弹出确认框调用“删除接口”后刷新列表。一个关键技巧新增和编辑共用一个 dialog 和表单。用dialogType变量区分当前是新增还是编辑提交接口不同回填逻辑相同。这能少写一半代码也不容易把两个表单的状态搞混。5. 联调、部署与常见问题排查实录5.1 本地联调的环境配置联调最怕的就是端口号、跨域、代理配置一股脑全不对。我的标准做法后端启动端口8080在application.yml配置。前端 dev server 端口5173Vite或8081Vue CLI。前端配置 dev 代理把/api开头的请求转发到后端 8080// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端代码里请求地址不需要写绝对路径部署到服务器时只需要在 Nginx 里做同样的转发配置前端代码完全不用改。这一招非常实用。5.2 CORS 跨域的两种解决方式前后端分离一定会遇到跨域问题。解决方式两种方式一后端开启全局跨域适合简单场景Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }方式二用 Nginx 反向代理解决适合线上部署。前端把接口请求发到同域Nginx 将/api代理到后端服务前端和后端之间就没有跨域问题了。前端只和服务器的 80 端口打交道后端地址对浏览器完全透明。我的建议是开发环境用 Vite 代理线上环境用 Nginx 代理CORS 配置作为后端的兜底方案。三层保险稳定性拉满。5.3 常见问题速查表问题表现原因排查/解决方案前端请求提示401 Unauthorizedtoken 过期或未携带检查 axios 请求拦截器是否带了 token检查 token 过期时间过期就重新登录表单提交后端拿不到数据前端提交的字段名和后端 DTO 不匹配打开浏览器 Network看请求 payload 的字段名和后端实体做比对数据库中文乱码连接字符串没指定编码在 JDBC URL 上加characterEncodingutf8并且确认数据库和表是 utf8mb4点保存后数据没刷新前端更新列表接口没重新调用提交成功后调用getList()刷新不要只操作当前行的局部数据金额算出来是浮点误差用了 Float 或 Double后端统一用 BigDecimal前端 if 金额展示用 toFixed(2)端口被占用本地多项目冲突kill -9 pidLinux或netstat -ano找占用进程MyBatis-Plus 查询全部报错实体类字段和数据库列名不符合驼峰/下划线映射开启map-underscore-to-camel-case: true或检查 TableField 注解JWT 拦截器配置后所有接口都要登录拦截器拦截范围没配置排除名单在 addInterceptors 里 excludePathPatterns 放行登录注册和菜品列表等公开接口5.4 几个实际排查案例案例一新增菜品后列表不更新。这是典型的数据没刷新的问题——新增接口调用成功后表格数据还是旧的。解决办法是在提交成功的回调里再次调用getDishList()。很多人会纠结要不要通过“修改本地数组”的方式优化我的建议是别优化保持数据源的单一来源。项目做大了你会发现服务端返回的数据永远是最权威的。案例二下订单时用了不同的金额精度导致数据库保存为 19.999999。这就是 Float 惹的祸。全项目搜索一下把所有float换成BigDecimal数据库字段改成decimal问题就彻底解决。这种问题要全局修不要只修一个接口因为其他地方迟早还会踩。案例三跨域请求 preflight 失败。后端接口明明写了 CORS但前端还被拦截。看看是不是请求头里带了自定义 header比如 Authorization触发了 preflight。解决方式是确认 allowedHeaders 里包含了*或者明确加上Authorization。配置完成后重启后端再试。5.5 部署到服务器的实操步骤部署这一步做到“一个 jar 一个 dist 一份 nginx.conf 就能跑”就算成功了。后端打包mvn clean package -DskipTests # 会在 target 目录生成 jar 包 java -jar restaurant-system.jar --spring.profiles.activeprod前端打包npm run build # 生成 dist 目录里面是纯静态文件服务器上安装 Nginx配置如下server { listen 80; server_name your_domain.com; # 静态资源前端 location / { root /var/www/restaurant/dist; index index.html; try_files $uri $uri/ /index.html; } # 接口转发 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }部署完成后访问服务器域名就能看到前端页面接口通过/api转发到 Java 后端。数据库在服务端安装一份 MySQL导入 sql 脚本然后改掉配置文件里的数据库连接就行。一个容易忽略的点后端项目的application.yml里上传文件大小限制、JWT 密钥等配置部署时要一并检查和调整。尤其是 JWT 密钥我用的是自定义的一段随机字符串一定要设置一个比较复杂的值不要用默认的。6. 配套的源码、文档、调试与答疑服务6.1 交付内容到底包含哪些一个完整的点餐系统项目交付我认为至少包含这几样源码前后端完整代码、数据库脚本建表 初始数据、项目文档设计文档 部署文档、演示视频可选但推荐、答疑服务。标题里写的“源码 文档 调试 基础修改 答疑”基本就是这个意思。源码要明确标注以下信息后端启动方式JDK 版本、Maven 配置、前端启动方式Node 版本、npm 命令、数据库初始账号密码。很多项目拿过来跑不通往往不是代码有问题而是环境没对齐。所以文档里第一步就是列环境要求。6.2 调试服务能帮到什么程度调试服务的目标是“帮你把项目在本机跑起来”。常见的调试内容包括环境问题排查JDK 版本不对、Node 版本不对、依赖下载失败Maven 仓库源换阿里云、数据库连接失败账号密码、端口、库名写错、前端编译报错组件缺失、版本不匹配。但调试不等于“帮你写新功能”。基础修改服务指的是修改系统标题、Logo、背景图、菜品数据、用户角色、部分页面文案等这些不涉及业务逻辑的调整。更深度的定制开发比如增加新的业务模块、对接支付接口、增加小程序端那是另一个工程量的话题。6.3 答疑的价值在哪里我做项目答疑的切身体会是很多同学拿到源码后真正想问的往往不是“这段代码怎么写”而是“这段代码为什么这么写”。答疑恰好能解这些疑惑。比如为什么要用Transactional为什么订单状态要单独建表为什么前端要用 Pinia这些问题的答案不是看代码就能看出来的需要有人把设计思路讲一遍。这也是我在交付文档里会额外加一节“核心难点解析”的原因把最容易被问到的几个点提前讲透。6.4 拿到项目后怎么二次开发如果你的目的是毕业设计或课程设计我的建议是拿到源码后不要直接交而是做几处“痕迹化修改”让项目看起来像自己做的改系统名称和 Logo换成自己的项目名。修改菜品数据和分类数据换成自己的业务场景。找一个你真正想扩展的功能点去动手在哪加、为什么这么加、碰到什么问题写进论文的设计与实现部分。给项目写一份自己的部署教程能一步步截图复现那种。这几步做完你对项目的理解深度完全不一样。答辩时老师问你“这个功能怎么实现的”你能从架构到代码细节讲清楚比任何说明文档都管用。7. 最后一轮项目打磨与文档整理7.1 演示环境的准备给答辩或演示用的环境一定要提前准备好不要现场开 IDE 启动项目。正确姿势是本地把所有服务启动好浏览器打开对应页面数据库预先灌好演示数据。如果需要展示新增功能提前准备好一个新的菜品名称和图片。演示最容易翻车的是网络问题——如果演示环境需要连接远程数据库一定要提前确认网络稳定。否则一卡断前面讲的再好都白搭。最保险的方案是本地装 MySQL导入同样的数据全程离线演示。7.2 文档里必须写清楚的内容项目文档不是把代码贴一遍而是把设计过程讲清楚。我推荐的文档结构是绪论项目背景、开发意义需求分析功能需求、非功能需求系统设计架构设计、功能模块划分、数据库设计系统实现核心功能截图 关键代码说明系统测试测试用例 测试结果部署说明环境要求 部署步骤数据库设计这一章特别重要按我之前说的表结构加上字段说明表和表关系图这部分内容非常扎实。系统实现里核心页面截图 对应的后端接口代码片段是标配但不要整段贴挑关键逻辑说清楚就行。7.3 一些交付后的建议项目交付后我会额外提醒对方几件事源码多备份几份。一个放本地一个放云端私有仓库一个存压缩包。论文查重前把代码和表格整理成自己的语言表述别直接用网上的模板。千万别把数据库密码、JWT 密钥这类信息写进公开文档和演示视频里。这些细节看着小关键时刻能避免很多麻烦。8. 写在最后的几点经验做点餐系统这个项目我最大的感受是技术栈不是越新越好适合业务并且能稳定跑起来才是核心。Spring Boot 3 Vue 3 的组合对新手来说有几个坑Spring Boot 3 要求 JDK 17部分老教程是 JDK 8Vue 3 配合 Element Plus 的用法和 Vue 2 Element UI 差不多但有些组件属性和事件名改了。如果代码报错优先检查版本配套这是我看过最多的报错根源。另外一点很实在的建议拿到项目源码后一定要自己动手把项目从零跑一遍。不是看一遍文档就行而是真的去配环境、启动、点一遍功能。这个过程暴露的问题才是你答辩时最宝贵的素材——因为这些问题是你自己经历的讲出来有底气。最后再分享一个小技巧做项目前先把“用户故事”写清楚比如“小明进入餐厅扫码打开点餐页面选了两份菜提交订单等待上餐”。把这三个动作对应的数据流转画出来用户点菜 - 写入购物车 - 生成订单 - 扣库存 - 后厨接单你会发现整个系统的设计逻辑瞬间清晰了代码写起来也顺很多。如果你正在做这个选题希望这篇东西对你有点帮助。项目本身不难一步步来把每个模块都跑通你收获的绝对不止是一个能答辩的系统。 
长河君 · 2026/10/13 13:31:30 · 阅读 1.2k Spring Boot+Vue点餐系统实战：从架构设计到部署上线全解析
做点餐系统这个选题其实挺有意思的。它不是那种纯教学用的玩具项目——餐厅点餐本身就是真实业务场景涉及商品展示、购物车、订单状态机、支付对接、库存扣减这一整条链路做完以后几乎能把前后端开发的主要知识点都串起来。我前前后后带过不少同学做类似的东西Spring Boot Vue 这套组合是出现频率最高的后端生态成熟前端组件库丰富招人市场上需求量也大更重要的是这套技术栈的资料和踩坑记录足够多真卡住了不至于求告无门。这篇东西就从设计思路、核心模块、实操细节到调试部署完整撸一遍我以为的点餐系统该怎么做以及做的时候哪些地方值得多花心思。1. 项目整体设计与技术选型思路1.1 为什么是 Spring Boot Vue 而不是别的组合先说后端。Spring Boot 在中小型系统里的优势不是“性能最强”而是“约定优于配置”带来的开发效率。点餐系统这种业务谈不上高并发、海量数据核心诉求是业务逻辑清晰、接口稳定、方便扩展。Spring Boot 的自动配置能省掉一堆 XML 配置的工夫内嵌 Tomcat 也让部署变成“一个 jar 包丢上去就跑”特别适合课程设计和中小型商业项目。前端这块Vue 的学习曲线相对平缓组件化开发方式特别贴合点餐系统的界面特征——菜品卡片、购物车、订单列表拆成组件以后复用和维护都很顺畅。加上 Element UI 这样的组件库表格、表单、弹窗这些后台管理页面需要的元素几乎都能直接拿来用能把更多精力放在业务逻辑上。这套组合还有一个隐性优势前后端分离的开发模式。后端专心出接口前端专心做页面两边用 JSON 交互天然适合团队分工——哪怕是一个人做也能把关注点拆开后期调试定位问题会省力很多。1.2 系统功能模块怎么划分才合理一个完整的餐厅点餐系统我习惯分成三个端来设计用户端微信小程序风格或 H5 页面用户注册登录、浏览菜品、按分类筛选、加入购物车、下单、查看订单状态、取消订单。商家端后台管理页面菜品管理增删改查、上下架、分类管理、订单处理接单、出餐、完成、菜品的库存/销量统计。管理端可选扩展用户管理、订单总览、数据看板、权限控制。这种三端划分不是拍脑袋。做系统设计最忌“眉毛胡子一把抓”把用户操作和后台管理混在一个界面里代码很快就会乱。前后端分离架构下三个端共用同一套后端接口只是前端路由和数据权限不同这个思路对后期的扩展非常友好——比如以后想加一个外卖配送模块只需要在用户端加一套地址和骑手接口后端扩展对应的 service 就行。1.3 技术选型时要避免的几个坑第一不要一上来就引入微服务、Redis、消息队列这些重组件。点餐系统的核心是业务闭环不是技术表演。初期老老实实用 MySQL Spring Boot 单应用把业务逻辑做扎实比堆一堆中间件然后跑不起来强得多。第二鉴权方案别用复杂的 Spring Security 全量配置。很多人一看到 Spring Security 的过滤器链就头大配了半天还在 403。实际做这个项目用 JWTJSON Web Token做一个轻量级拦截器就够了——登录后签发 token前端请求时带上后端拦截器校验。逻辑清晰代码量小还方便讲清楚原理。第三前端构建工具统一用 Vue CLI 或者 Vite版本别混着来。Vue 2 和 Vue 3 的生态差异很大Element UI 和 Element Plus 也分别对应不同版本组合错了项目直接跑不起来。我在带项目时最怕听到的就是“我照着网上的教程配怎么报错了”——大概率就是版本组合问题。2. 数据库设计与核心表结构拆解2.1 核心表到底需要哪几张餐厅点餐系统的数据库设计不是我自夸下面这套表结构可以说是我在做了几次类似项目后总结出的最实用方案。一共就这几张核心表表名职责关键字段说明users用户信息id, username, passwordBCrypt 加密, phone, avatar, rolecategory菜品分类id, name, sortdish菜品信息id, category_id, name, price, image, description, status1上架/0下架cart购物车id, user_id, dish_id, quantityorders订单主表id, order_no, user_id, total_amount, status, create_time, pay_timeorder_detail订单明细id, order_id, dish_id, dish_name, dish_image, price, quantityaddress可选配送地址id, user_id, detail, phone, is_default这套表的思路要点在于购物车和订单拆分成了“临时态”和“正式态”。购物车里的数据是可以随便改、随便删的订单一旦生成所有信息必须快照固化。所以 order_detail 里不光存 dish_id还把 dish_name、price 冗余了一份——防止商家改了菜品价格后历史订单的金额跟着变这是新手最容易漏掉的一个设计点。2.2 关键字段设计的细节与原因订单号不能直接用自增 id。对外展示的订单号一般会用“日期 随机数”或“日期 递增序列”的格式比如20250607123456789。这样既方便用户和商家沟通也能从订单号直接看出下单时间。实现上可以在后端生成避免前端伪造。金额字段用 Decimal 而不是 Float/Double。这不是矫情——浮点数运算丢精度的问题在涉及“元”和“分”转换时尤其明显。Java 后端用BigDecimalMySQL 用DECIMAL(10,2)前端展示时再格式化。这个习惯养成了以后做任何涉及钱的系统都不会吃大亏。订单状态用 tinyint 还是 varchar我自己的习惯是用 varchar 存状态描述比如PENDING、ACCEPTED、COMPLETED、CANCELLED。优点是看数据库就知道状态排查问题方便缺点是稍微占点存储。对于点餐系统这种量级的项目可读性远比省那几字节重要。软删除菜品、分类这些基础数据不要物理删除。加一个is_deleted字段查询时默认过滤。原因很简单菜品被下单过以后订单明细里引用了它的 id 和名称物理删了会导致历史数据对不上你的“数据统计”模块就全废了。2.3 下单时库存和菜品状态校验菜品表最好加一个stock字段库存数量-1 表示不限。下单时要校验菜品是否还在上架状态status 1。库存是否足够。通过UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这种乐观更新方式扣减库存。最后一步是关键用条件更新防止超卖。虽然点餐系统并发量不高但这个写法是个好习惯——用数据库的行锁天然避免并发问题比先查出来判断再更新安全得多代码也就多一行。3. 后端核心模块的实现细节与实操要点3.1 项目目录结构与分层后端包结构我用标准的三层架构com.xxx.restaurant ├── controller # 接口层 ├── service # 业务层 │ ├── impl │ ├── UserService │ ├── DishService │ ├── OrderService ├── mapper # 数据访问层MyBatis-Plus ├── entity # 实体类 ├── dto # 数据传输对象 ├── vo # 视图对象 ├── config # 配置CORS、JWT拦截器 ├── common # 通用工具、统一返回结果、异常处理分层最重要的是职责分离。Controller 只做参数接收和结果返回业务逻辑全部放在 Service 层mapper 只管 SQL。这样代码的可读性、可测试性都大幅提升。3.2 统一返回结果与全局异常处理前端和后端约定一套统一的响应格式这点非常重要{ code: 200, message: success, data: { } }用泛型定义一个ResultT类code 为 200 时表示成功其余为各种业务异常。配合RestControllerAdvice写一个全局异常处理器业务代码里抛出带错误码的BusinessException前端统一拦截处理提示信息——这样后端 Controller 里的 try-catch 可以全部去掉代码会清爽很多。这个习惯我几乎在每个项目里都会强调它带来的直接好处是前端只需要在 axios 的响应拦截器里统一处理一次错误提示不需要每个接口单独处理异常场景。3.3 JWT 登录鉴权的完整流程登录流程其实很简单用户提交用户名/密码。后端通过BCryptPasswordEncoder校验密码注意密码不能明文存储。校验通过后用jwt工具类生成 token里面放入用户 id 和用户名设置过期时间一般 7 天。前端把 token 存在 localStorage 或 Pinia/Vuex 中后续请求在请求头加Authorization: Bearer token。后端写一个拦截器HandlerInterceptor对需要登录的接口如购物车、订单操作校验 token。需要注意拦截器要把登录接口、菜品列表这些公开接口排除掉。校验解析后的用户信息怎么传给 Controller我习惯用一个 ThreadLocal 的静态工具类做用户上下文——在拦截器里解析完 token 放进 ThreadLocal后续 Controller 和 Service 都能从这里拿用户 id。注意请求结束后要在拦截器的 afterCompletion 里 remove防止线程池复用导致的数据串号。3.4 下单接口的业务逻辑编排下单是核心接口也是最能体现代码水平的地方。要在一个事务里完成Transactional public Order createOrder(OrderCreateDTO dto) { // 1. 创建订单主表记录计算总金额 // 2. 批量校验菜品状态和库存 // 3. 扣减库存 // 4. 批量插入订单明细 // 5. 清空购物车 // 6. 返回订单详情 }Transactional保证要么全部成功要么全部回滚。其中第 2、3 步要复用 DishMapper 的方法避免在 Service 里通过 for 循环单独查数据库批量查询一次出来再内存标记性能更好代码也更好测。3.5 排行榜和统计怎么实现点餐系统都会加一个“销量排行”或“热销榜单”。这个直接用 SQL 统计就行后端写一个统计接口SELECT dish_id, dish_name, SUM(quantity) AS total FROM order_detail WHERE create_time BETWEEN ? AND ? GROUP BY dish_id, dish_name ORDER BY total DESC LIMIT 10注意点统计的是 order_detail 而不是菜品表的销量字段。这也是为什么前面强调下单时要在明细表里冗余菜品名称——有了快照统计就永远正确。如果把销量冗余在菜品表里每次下单去 update一旦出现并发或事务回滚数据就乱了。4. 前端 Vue 的实现思路与页面拆解4.1 项目结构与路由前端项目结构我习惯按业务模块划分src/ ├── api/ # 接口请求封装 │ ├── user.js │ ├── dish.js │ ├── order.js ├── assets/ ├── components/ # 通用组件 │ ├── DishCard.vue │ ├── CartPanel.vue │ └── ... ├── router/index.js ├── store/ # Pinia/Vuex │ ├── modules/cart.js │ └── modules/user.js ├── views/ │ ├── Home.vue │ ├── DishList.vue │ ├── OrderList.vue │ ├── Login.vue │ └── admin/ # 后台管理页面路由用 Vue Router需要区分两类不需要登录的登录页、菜品浏览页和需要登录的购物车、订单、后台管理。在路由前置守卫里做登录校验判断 localStorage 里有没有 token以及要去的路由是否在免登录白名单里。这里的细节是管理员路由和普通用户路由要区分权限。路由表里通过 meta.roles 标记守卫里解析 token 里的角色信息判断是否有权限。前端只是做展示控制后端的接口权限拦截才是真正的安全防线。4.2 axios 封装与请求拦截不封装 axios 的项目会很痛苦。统一的封装做三件事// api/request.js const service axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器自动携带 token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理 code service.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message) // 401 处理跳转登录页 return Promise.reject(new Error(res.message)) } return res.data }, error { // HTTP 层错误统一处理 ElMessage.error(网络异常) return Promise.reject(error) } )baseURL 设为/api配合后端 CORS 配置或前端 dev server 的代理可以避免开发环境的跨域烦恼。这一步是新手最容易卡壳的点我在常见问题里会单独讲。4.3 点餐核心页面菜品列表 购物车点餐页面我分成两个主要组件左侧分类菜单 菜品卡片列表右侧悬浮购物车栏。菜品卡片用 Element Plus 的el-card 自定义插槽展示图片、名称、价格、销量。加入购物车按钮触发cartStore.add(dish)购物车状态用 Pinia 管理。为什么购物车要放全局 store 而不是组件本地状态因为“加入购物车”和“提交订单”不是同一个页面甚至可能在路由切换后仍需保留状态。用 Pinia 管理后只要不刷新页面购物车数据就一直在内存里再配合 localStorage 持久化刷新也不丢。购物车里展示数量加减和删除很重要每改一次数量都要同步计算总价。计算属性里computed做总价统计就行Vue 的响应式会自动更新。4.4 后台管理页面的实现要点后台管理页面对新手来说最容易困在“表格 弹窗 表单校验”的循环里。用 Element Plus 等于开了个挂el-table绑定数据源el-dialog里放el-form表单校验规则用rules属性声明式配置。菜品管理的核心操作就是页面加载时调用getDishList()接口表格显示。点击“新增”打开 dialog清空表单提交时调用“新增接口”。点击“编辑”打开 dialog回填表单数据提交时调用“更新接口”。点击“删除”弹出确认框调用“删除接口”后刷新列表。一个关键技巧新增和编辑共用一个 dialog 和表单。用dialogType变量区分当前是新增还是编辑提交接口不同回填逻辑相同。这能少写一半代码也不容易把两个表单的状态搞混。5. 联调、部署与常见问题排查实录5.1 本地联调的环境配置联调最怕的就是端口号、跨域、代理配置一股脑全不对。我的标准做法后端启动端口8080在application.yml配置。前端 dev server 端口5173Vite或8081Vue CLI。前端配置 dev 代理把/api开头的请求转发到后端 8080// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端代码里请求地址不需要写绝对路径部署到服务器时只需要在 Nginx 里做同样的转发配置前端代码完全不用改。这一招非常实用。5.2 CORS 跨域的两种解决方式前后端分离一定会遇到跨域问题。解决方式两种方式一后端开启全局跨域适合简单场景Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }方式二用 Nginx 反向代理解决适合线上部署。前端把接口请求发到同域Nginx 将/api代理到后端服务前端和后端之间就没有跨域问题了。前端只和服务器的 80 端口打交道后端地址对浏览器完全透明。我的建议是开发环境用 Vite 代理线上环境用 Nginx 代理CORS 配置作为后端的兜底方案。三层保险稳定性拉满。5.3 常见问题速查表问题表现原因排查/解决方案前端请求提示401 Unauthorizedtoken 过期或未携带检查 axios 请求拦截器是否带了 token检查 token 过期时间过期就重新登录表单提交后端拿不到数据前端提交的字段名和后端 DTO 不匹配打开浏览器 Network看请求 payload 的字段名和后端实体做比对数据库中文乱码连接字符串没指定编码在 JDBC URL 上加characterEncodingutf8并且确认数据库和表是 utf8mb4点保存后数据没刷新前端更新列表接口没重新调用提交成功后调用getList()刷新不要只操作当前行的局部数据金额算出来是浮点误差用了 Float 或 Double后端统一用 BigDecimal前端 if 金额展示用 toFixed(2)端口被占用本地多项目冲突kill -9 pidLinux或netstat -ano找占用进程MyBatis-Plus 查询全部报错实体类字段和数据库列名不符合驼峰/下划线映射开启map-underscore-to-camel-case: true或检查 TableField 注解JWT 拦截器配置后所有接口都要登录拦截器拦截范围没配置排除名单在 addInterceptors 里 excludePathPatterns 放行登录注册和菜品列表等公开接口5.4 几个实际排查案例案例一新增菜品后列表不更新。这是典型的数据没刷新的问题——新增接口调用成功后表格数据还是旧的。解决办法是在提交成功的回调里再次调用getDishList()。很多人会纠结要不要通过“修改本地数组”的方式优化我的建议是别优化保持数据源的单一来源。项目做大了你会发现服务端返回的数据永远是最权威的。案例二下订单时用了不同的金额精度导致数据库保存为 19.999999。这就是 Float 惹的祸。全项目搜索一下把所有float换成BigDecimal数据库字段改成decimal问题就彻底解决。这种问题要全局修不要只修一个接口因为其他地方迟早还会踩。案例三跨域请求 preflight 失败。后端接口明明写了 CORS但前端还被拦截。看看是不是请求头里带了自定义 header比如 Authorization触发了 preflight。解决方式是确认 allowedHeaders 里包含了*或者明确加上Authorization。配置完成后重启后端再试。5.5 部署到服务器的实操步骤部署这一步做到“一个 jar 一个 dist 一份 nginx.conf 就能跑”就算成功了。后端打包mvn clean package -DskipTests # 会在 target 目录生成 jar 包 java -jar restaurant-system.jar --spring.profiles.activeprod前端打包npm run build # 生成 dist 目录里面是纯静态文件服务器上安装 Nginx配置如下server { listen 80; server_name your_domain.com; # 静态资源前端 location / { root /var/www/restaurant/dist; index index.html; try_files $uri $uri/ /index.html; } # 接口转发 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }部署完成后访问服务器域名就能看到前端页面接口通过/api转发到 Java 后端。数据库在服务端安装一份 MySQL导入 sql 脚本然后改掉配置文件里的数据库连接就行。一个容易忽略的点后端项目的application.yml里上传文件大小限制、JWT 密钥等配置部署时要一并检查和调整。尤其是 JWT 密钥我用的是自定义的一段随机字符串一定要设置一个比较复杂的值不要用默认的。6. 配套的源码、文档、调试与答疑服务6.1 交付内容到底包含哪些一个完整的点餐系统项目交付我认为至少包含这几样源码前后端完整代码、数据库脚本建表 初始数据、项目文档设计文档 部署文档、演示视频可选但推荐、答疑服务。标题里写的“源码 文档 调试 基础修改 答疑”基本就是这个意思。源码要明确标注以下信息后端启动方式JDK 版本、Maven 配置、前端启动方式Node 版本、npm 命令、数据库初始账号密码。很多项目拿过来跑不通往往不是代码有问题而是环境没对齐。所以文档里第一步就是列环境要求。6.2 调试服务能帮到什么程度调试服务的目标是“帮你把项目在本机跑起来”。常见的调试内容包括环境问题排查JDK 版本不对、Node 版本不对、依赖下载失败Maven 仓库源换阿里云、数据库连接失败账号密码、端口、库名写错、前端编译报错组件缺失、版本不匹配。但调试不等于“帮你写新功能”。基础修改服务指的是修改系统标题、Logo、背景图、菜品数据、用户角色、部分页面文案等这些不涉及业务逻辑的调整。更深度的定制开发比如增加新的业务模块、对接支付接口、增加小程序端那是另一个工程量的话题。6.3 答疑的价值在哪里我做项目答疑的切身体会是很多同学拿到源码后真正想问的往往不是“这段代码怎么写”而是“这段代码为什么这么写”。答疑恰好能解这些疑惑。比如为什么要用Transactional为什么订单状态要单独建表为什么前端要用 Pinia这些问题的答案不是看代码就能看出来的需要有人把设计思路讲一遍。这也是我在交付文档里会额外加一节“核心难点解析”的原因把最容易被问到的几个点提前讲透。6.4 拿到项目后怎么二次开发如果你的目的是毕业设计或课程设计我的建议是拿到源码后不要直接交而是做几处“痕迹化修改”让项目看起来像自己做的改系统名称和 Logo换成自己的项目名。修改菜品数据和分类数据换成自己的业务场景。找一个你真正想扩展的功能点去动手在哪加、为什么这么加、碰到什么问题写进论文的设计与实现部分。给项目写一份自己的部署教程能一步步截图复现那种。这几步做完你对项目的理解深度完全不一样。答辩时老师问你“这个功能怎么实现的”你能从架构到代码细节讲清楚比任何说明文档都管用。7. 最后一轮项目打磨与文档整理7.1 演示环境的准备给答辩或演示用的环境一定要提前准备好不要现场开 IDE 启动项目。正确姿势是本地把所有服务启动好浏览器打开对应页面数据库预先灌好演示数据。如果需要展示新增功能提前准备好一个新的菜品名称和图片。演示最容易翻车的是网络问题——如果演示环境需要连接远程数据库一定要提前确认网络稳定。否则一卡断前面讲的再好都白搭。最保险的方案是本地装 MySQL导入同样的数据全程离线演示。7.2 文档里必须写清楚的内容项目文档不是把代码贴一遍而是把设计过程讲清楚。我推荐的文档结构是绪论项目背景、开发意义需求分析功能需求、非功能需求系统设计架构设计、功能模块划分、数据库设计系统实现核心功能截图 关键代码说明系统测试测试用例 测试结果部署说明环境要求 部署步骤数据库设计这一章特别重要按我之前说的表结构加上字段说明表和表关系图这部分内容非常扎实。系统实现里核心页面截图 对应的后端接口代码片段是标配但不要整段贴挑关键逻辑说清楚就行。7.3 一些交付后的建议项目交付后我会额外提醒对方几件事源码多备份几份。一个放本地一个放云端私有仓库一个存压缩包。论文查重前把代码和表格整理成自己的语言表述别直接用网上的模板。千万别把数据库密码、JWT 密钥这类信息写进公开文档和演示视频里。这些细节看着小关键时刻能避免很多麻烦。8. 写在最后的几点经验做点餐系统这个项目我最大的感受是技术栈不是越新越好适合业务并且能稳定跑起来才是核心。Spring Boot 3 Vue 3 的组合对新手来说有几个坑Spring Boot 3 要求 JDK 17部分老教程是 JDK 8Vue 3 配合 Element Plus 的用法和 Vue 2 Element UI 差不多但有些组件属性和事件名改了。如果代码报错优先检查版本配套这是我看过最多的报错根源。另外一点很实在的建议拿到项目源码后一定要自己动手把项目从零跑一遍。不是看一遍文档就行而是真的去配环境、启动、点一遍功能。这个过程暴露的问题才是你答辩时最宝贵的素材——因为这些问题是你自己经历的讲出来有底气。最后再分享一个小技巧做项目前先把“用户故事”写清楚比如“小明进入餐厅扫码打开点餐页面选了两份菜提交订单等待上餐”。把这三个动作对应的数据流转画出来用户点菜 - 写入购物车 - 生成订单 - 扣库存 - 后厨接单你会发现整个系统的设计逻辑瞬间清晰了代码写起来也顺很多。如果你正在做这个选题希望这篇东西对你有点帮助。项目本身不难一步步来把每个模块都跑通你收获的绝对不止是一个能答辩的系统。