简介一套微信小程序扫码点餐系统的完整毕业设计源码后端采用SpringBoot小程序端基于uni-app管理端使用Vue面向Java方向毕业生、初学者或需要快速搭建餐饮点餐应用的开发者。针对传统排队点餐和人工记录效率低、高峰时段服务员不足等痛点系统支持顾客扫码浏览菜品、下单备注商家端可管理菜品与店铺。资源共455个文件压缩包约7.05MB主要包含Java后端代码、XML配置、Vue/JS前端页面及SQL脚本等SQL脚本可快速初始化MySQL数据库。目前该资源已有1290人学习下载。除可运行的完整源码外还附带配套论文、运行截图和数据库设计有助于理解前后端分离架构、扫码点餐完整业务流及Vue管理后台的开发技巧既可用于毕业设计也可作为二次开发基础。 扫码点餐这套东西说实话已经成为餐饮行业的标配了。我刚接手这个毕业设计项目时也没想到一套看着不起眼的微信小程序扫码点餐系统背后覆盖的技术面居然这么宽——小程序端、管理后台、后端接口、数据库建模、微信授权登录甚至支付流程几乎把Java全栈该踩的坑都踩了一遍。这个项目用到的核心组合是uni-app SpringBoot Vue分别承担用户端小程序、服务端接口和管理后台三个角色典型的毕业设计完整闭环。如果你正在找java毕业设计题目或者打算自己从零写一套带完整前后端的实战项目这个扫码点餐系统值得好好研究。它不只是一个“点餐页面”而是把微信生态、移动端跨平台开发、后端接口设计、后台管理系统这几个方向全串起来了技术广度和深度都够写进简历也拿得出手。这篇就把我的完整设计思路、踩坑记录和复现要点整理出来给打算做同类项目的同学一个参考。1. 系统整体设计与技术选型解析1.1 为什么是uni-app SpringBoot Vue这套组合先说技术选型。微信小程序原生的WXML/WXSS写起来其实不复杂但有个问题——代码只能跑在微信里将来想上支付宝小程序、抖音小程序或者H5就得全部重写。uni-app好就好在它基于Vue语法一套代码可以同时编译到微信小程序、H5、App等多个平台这一点对于毕设来说性价比非常高工作量几乎减半还能展示跨端开发的能力。后端选SpringBoot没什么好犹豫的。它是当前Java后端开发事实上的标准内嵌Tomcat、自动配置、生态成熟配合MyBatis-Plus操作数据库非常顺手。毕设答辩时老师问“为什么用SpringBoot”标准答案就是简化配置、快速启动、社区资料多、企业主流。管理端用Vue就更直观了。Vue的双向数据绑定和组件化开发写后台管理系统非常贴合——商品列表、订单表格、图表统计全是组件堆出来的。搭配Element UI组件库页面效果和交互都不差。这套组合最大的优势是小程序端和Vue管理端都用Vue语法上手成本低一个人能Hold住三条线。做毕设最怕的就是技术栈太杂比如小程序用原生、后台用React调试起来精神分裂。1.2 业务模块全景视图扫码点餐系统从用户视角看很简单进店、扫码、点菜、支付、等餐。但拆成系统模块就没那么简单了至少包含四个端侧能力用户小程序端微信授权登录、扫码识别桌台、浏览菜品分类、加购、下单、在线支付、订单状态查看商家管理端菜品管理增删改查/上架下架、分类管理、订单处理接单/出餐/完成、营业数据统计后端接口服务用户身份认证、商品接口、购物车接口、订单接口、微信支付回调、文件上传数据库层用户表、菜品表、分类表、购物车表、订单表、订单明细表这个闭环设计其实点出了整个系统的核心思路小程序端不直接操作数据库所有请求走后端接口管理端也不直接读写核心业务表——三方通过RESTful接口协作分工清楚出了问题也好排查。1.3 端与端之间的数据流转逻辑我画系统架构图的时候最头疼的就是怎么把这几端的关系讲清楚后来用一句话总结小程序负责展示和收集用户操作后端负责业务处理和状态流转管理端负责经营管理和数据查看。一次完整的点餐流程数据是这样流转的用户扫描桌台二维码小程序解析出店铺ID和桌号参数小程序调用wx.login()拿到临时code传给后端后端拿着code去微信接口换openid完成静默登录小程序请求菜品接口按分类展示菜单用户加购、提交订单后端校验库存并生成订单记录用户发起支付后端生成预支付单支付成功回调更新订单状态管理端实时看到新订单商家接单出餐用户在“我的订单”里看到状态变化这个流程里最容易忽略的是上下文传递——桌号、店铺ID这些参数从扫码那一刻起就要跟着整个订单链路走否则订单落库后不知道是哪桌点的商家就没法送餐了。2. 数据库设计与核心表结构2.1 用户端和店铺端的基础表数据库设计是整个系统的地基地基没打好后面写代码会各种别扭。我已经把完整SQL脚本放到了项目里这里把核心表结构挑出来讲一讲。用户表user主键id、openid微信用户唯一标识这是整个系统的登录凭证、昵称、头像、手机号、创建时间。openid必须加唯一索引因为它是用户身份的唯一依据重复会导致登录错乱。店铺表shopid、店铺名称、地址、联系电话、营业状态。扫码点餐属于多商户模式虽然毕设演示时通常只配一个店铺但表结构上把店铺维度预留出来后续扩展就不伤筋动骨。菜品分类表categoryid、店铺id、分类名称、排序值。这里的排序值是个小细节没有它你会发现前端菜单分类的显示顺序不可控总是乱序很多教程不会提这个。桌面上的二维码就带两个核心参数shopId和tableNo比如pages/index/index?shopId1tableNoA12。用户扫码进入小程序页面onLoad里解析这两个参数放到全局这个设计是整个扫码场景的入口非常重要。2.2 订单相关表的设计要点购物车表cartid、用户id、店铺id、菜品id、数量、加购时间。购物车设计成后端存储而不是本地存储好处是用户换手机或退出小程序重进购物车数据不丢体验更完整。订单主表ordersid、订单编号、用户id、店铺id、桌号、订单金额、支付状态0未支付/1已支付、订单状态0待接单/1已接单/2已完成/3已取消、创建时间、支付时间。这里订单编号我推荐用时间戳 随机数生成避免并发下重复。订单明细表order_detailid、订单id、菜品id、菜品名称、菜品图片、单价、数量、小计金额。为什么订单明细要单独一张表而且要把菜品名称和单价冗余进去因为菜品表和分类表一样是会变的——商家改了价格或者删了菜品历史订单里不该跟着变。把下单时的快照存进明细表这是订单系统的经典做法答辩论据充分。表关系订单主表与明细表是一对多关系用户与订单是一对多店铺与菜品是一对多。如果用了MyBatis-Plus用TableId(type IdType.ASSIGN_ID)自动生成雪花ID或用自增ID都行毕设场景自增就够用还能少踩雪花ID转前端精度丢失的坑——JSON序列化时记得把Long转String不然前端拿到的ID末尾几位会变成0别问我怎么知道的。3. 后端核心代码与关键流程实现3.1 微信登录接口的完整实现微信小程序登录是整套系统的第一道关卡。前端调用wx.login()拿到临时code后端拿这个code去微信接口换openid和session_key。核心代码在UserController里PostMapping(/login) public Result login(RequestBody LoginRequest request) { // 1. 用code换openid String url https://api.weixin.qq.com/sns/jscode2session?appid appId secret appSecret js_code request.getCode() grant_typeauthorization_code; String result restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(result); String openid json.getString(openid); // 2. 查数据库没有就注册新用户 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setNickname(微信用户 openid.substring(0, 6)); userMapper.insert(user); } // 3. 生成token给前端 String token JwtUtil.createToken(user.getId()); return Result.ok().data(token, token).data(user, user); }这段逻辑看起来简单实际操作有两个坑。第一appId和appSecret不要硬编码在代码里至少放到application.yml配置文件中管理保护配置信息是安全底线。第二jscode2session接口调用是网络IO比较慢前端要处理loading状态避免用户重复点击。3.2 扫码点餐与下单事务处理下单接口是整个系统业务逻辑最重的地方我用了Transactional事务保证数据一致性。核心流程是三步前端传来菜品列表 → 后端计算金额 → 生成订单和明细。Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateDTO dto) { // 1. 根据菜品id批量查出菜品信息 ListDish dishes dishMapper.selectBatchIds(dto.getDishIds()); // 2. 计算总金额不能直接信任前端传的金额要后端自己算 BigDecimal totalAmount BigDecimal.ZERO; for (Dish dish : dishes) { totalAmount totalAmount.add(dish.getPrice()); } // 3. 生成订单主表记录 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setShopId(dto.getShopId()); order.setTableNo(dto.getTableNo()); order.setTotalAmount(totalAmount); order.setStatus(0); orderMapper.insert(order); // 4. 生成订单明细 for (Dish dish : dishes) { OrderDetail detail new OrderDetail(); detail.setOrderId(order.getId()); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); detail.setPrice(dish.getPrice()); detail.setQuantity(1); orderDetailMapper.insert(detail); } return order; }这里有一个重要的设计原则后端必须重新计算订单金额不能直接信任前端传过来的金额字段。如果有人抓包把金额改成0.01元你直接存库就惨了。另一个细节是事务——如果明细插入失败主订单也要回滚不能出现“有订单没明细”的脏数据。3.3 SpringBoot目录结构与分层规范后端工程我严格按经典三层架构来组织答辩时这部分很加分com.example.restaurant ├── controller // 接口层只做参数接收和结果封装 ├── service // 业务层处理核心业务逻辑 ├── mapper // 数据访问层继承BaseMapper ├── entity // 实体类对应数据库表 ├── config // 全局配置如跨域、拦截器 ├── common // 通用类如结果封装、异常处理 ├── utils // 工具类如JwtUtil、订单号生成所有接口统一返回Result对象——包含code、message、data三个字段。前端拿到code为200就处理data否则弹错误提示这个模式在真实项目中很常见。接口地址统一以/api开头这个习惯能让你少踩很多跨域环境下的坑。4. 前端双端实现与联调细节4.1 uni-app小程序端核心功能实现uni-app项目的目录结构上pages里主要配置五个页面首页扫码落地、菜单页点餐、购物车页确认订单、订单页我的订单、个人中心页。扫码进入的落地逻辑在首页的onLoad里处理onLoad(options) { // 从小程序码中解析参数形如 ?shopId1tableNoA12 if (options.scene) { // 使用微信扫普通链接二维码时参数在scene中 const scene decodeURIComponent(options.scene); // 解析scene为shopId和tableNo } else if (options.shopId) { this.shopId options.shopId; this.tableNo options.tableNo; } }菜单页我用的是左右布局——左侧分类列表右侧菜品列表。分类滚动联动用的是uni-app的scroll-view组件左侧scroll-y右侧动态计算高度。这里有个性能优化点图片懒加载。菜品图片多的时候不懒加载会让页面卡顿明显uni-app的image标签直接加lazy-load属性就行。购物车数据存在Vuex里还是后端接口管理我的设计是两种结合加购时先调后端接口写入购物车表同时本地Vuex存一份用于界面实时显示。这样数据可靠交互也流畅但要注意同步问题——接口失败时要回滚本地状态。4.2 Vue管理端功能拆解管理端我用的是Vue2 Element UI Axios ECharts的技术组合几个核心页面登录页账号密码登录后端返回token存到localStorage路由守卫拦截未登录跳转菜品管理页el-table展示菜品列表支持搜索、分页、上架/下架切换图片上传用el-upload订单管理页待接单/已接单/已完成 Tab切换操作按钮实现接单、出餐数据统计页ECharts按日展示营业额折线图和菜品销量排行管理端开发时最容易忽略的是接口鉴权——如果管理端接口不校验登录状态任何人都能调接口改数据。我在后端加了一个简单的HandlerInterceptor校验请求头里的token校验失败返回401前端Axios响应拦截器统一处理跳登录页。4.3 HBuilderX打包发布要点如果你用HBuilderX运行和打包uni-app项目有几个细节值得注意。运行到微信开发者工具时需要在manifest.json里正确配置微信小程序的appid不然预览和真机调试都是白扯。打包之前的uni-app编译模式要选“微信小程序”这个选项在HBuilderX的运行菜单里。还有一个经验之谈写uni-app时获取用户手机号、调用支付这类能力**必须在微信开发者工具里勾选“不校验合法域名”**才能调试不然请求会被拦截一片空白。上线时再在微信公众平台配置合法域名否则正式版请求直接失败。5. 常见问题与排查技巧实录这部分是真正实践出来的经验很多问题不是看文档能预判的列出我实际踩过的坑和解决办法做成一个速查表。问题现象可能原因解决方案小程序请求接口一直报“不在以下合法域名列表中”微信公众平台没有配置request合法域名开发环境勾选“不校验合法域名”上线前在公众平台添加域名获取不到微信用户信息报错wx1cb4398e1413dce7相关appid配置错误或code2session接口调用失败检查小程序appid和密钥是否匹配检查后端请求微信接口的地址和参数SpringBoot启动失败提示版本相关错误SpringBoot版本和JDK版本不匹配SpringBoot 2.x配JDK8SpringBoot 3.x配JDK17及以上不要瞎配跨域请求被拦截后端没有配置跨域在SpringBoot中写一个CorsFilter或在Controller加CrossOrigin订单金额精度丢失数据库用了Double/Float金融字段一律用decimal类型Java对应BigDecimalMyBatis-Plus自动填充的时间为null没有配置MetaObjectHandler写一个类实现MetaObjectHandler统一填充createTime和updateTime管理端页面能打开接口全部401token过期或未携带检查Axios请求拦截器是否加了Authorization头后端拦截器是否放行login接口5.1 微信登录失败问题详解开发过程中遇到最多的就是登录问题现象是小程序端一直拿不到用户的openid。排查思路是这样的先确认appid和appSecret是否配置正确再去微信公众平台确认服务器域名已配置最后看后端日志中jscode2session接口有没有返回错误码。常见错误码40029是code无效通常是code已被使用或过期40163是code已被使用过前端wx.login()每次都要重新获取不能缓存。还有个小程序登录常见的坑——获取到openid后前端把openid存到本地下次直接传openid登录。这个做法不推荐安全性差。正确做法是后端返回自制的token前端本地只存token每次请求带token识别用户身份。5.2 SpringBoot版本与JDK版本兼容性网上很多教程用的是SpringBoot 2.x如果你跟着教程敲代码却启动失败八成是版本问题。SpringBoot 2.x要求JDK8或JDK11SpringBoot 3.x要求JDK17。毕设环境里我建议直接用JDK8 SpringBoot 2.7.x因为大部分网上的博客、视频教程都是这个版本组合遇到问题容易找到参考而且JDK8依然是目前企业使用的绝对主流版本写进简历也不会被质疑。如果你用了SpringBoot 3.x还要注意javax.servlet改成了jakarta.servlet很多老代码导入会报错排查起来很费时间没必要给自己添堵。5.3 管理端接口鉴权与跨域细节管理端和后端联调时遇到两个高频问题。第一个是跨域——前端地址是localhost:8080后端接口是localhost:9090浏览器直接拦截。解决办法是在后端写一个全局CORS配置类放行所有来源毕设阶段这样够用。生产环境里需要更严格的白名单配置但你如果做到这一步答辩老师反而会觉得你考虑周全。第二个是路由守卫拦截。Vue Router的beforeEach里判断有没有token没有就跳登录页。这里有个小坑登录页本身也要放行不然会死循环跳转。写法是判断to.path /login就next()否则才校验token。这个细节我在第一次实现时就踩了印象很深。6. 复盘思考与扩展方向回到项目的整体复盘。这套扫码点餐系统最强的优势在于它完整覆盖了一个真实商业项目的全部链路从扫码进入、点餐支付、订单管理到数据统计每个环节都有明确的业务价值和对应的技术实现。对做毕设的同学来说这样的完整度是非常有说服力的。我个人做下来最大的体会是这个系统真正的复杂度不在某个单点技术上而在于端与端之间的协作一致性——小程序的状态管理、后端的事务保障、管理端的实时反馈三个端各管一段串起来才是一个能跑通的核心业务闭环。不要小看这个闭环很多同学做毕业设计容易陷入“重前端轻后端”或“重后端轻前端”的偏科状态导致演示的时候半天走不通一个完整流程。后续如果有精力扩展有几个方向值得考虑一是接入微信支付真正跑通支付回调——这个功能上线价值非常高也能让毕设的完整度再上一个台阶二是增加打印机对接订单过来自动打印小票这是餐饮系统非常核心的硬件集成场景三是在管理端加数据看板用ECharts展示实时营业额和菜品排行视觉效果好答辩时讲起来也有话说。最后再分享一个实战小技巧做这种多端项目时从一开始就把接口文档维护好。我用的Apifox每写完一个接口就顺手写好文档字段名、类型、含义都标清楚。这样前后端联调的时候省了无数时间去猜字段也避免了很多沟通成本。项目里我放的部署说明和论文文档都是在这个基础上整理出来的你要是拿这个项目做参考建议也养成这个习惯。本文还有配套的精品资源点击获取