简介：一套微信小程序扫码点餐系统的完整毕业设计源码，后端采用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必须加唯一索引，因为它是用户身份的唯一依据，重复会导致登录错乱。
店铺表（shop）：id、店铺名称、地址、联系电话、营业状态。扫码点餐属于多商户模式，虽然毕设演示时通常只配一个店铺，但表结构上把店铺维度预留出来，后续扩展就不伤筋动骨。
菜品分类表（category）：id、店铺id、分类名称、排序值。这里的排序值是个小细节，没有它你会发现前端菜单分类的显示顺序不可控，总是乱序，很多教程不会提这个。
桌面上的二维码就带两个核心参数：shopId和tableNo，比如pages/index/index?shopId=1&tableNo=A12。用户扫码进入小程序页面，onLoad里解析这两个参数放到全局，这个设计是整个扫码场景的入口，非常重要。
2.2 订单相关表的设计要点
购物车表（cart）：id、用户id、店铺id、菜品id、数量、加购时间。购物车设计成后端存储而不是本地存储，好处是用户换手机或退出小程序重进，购物车数据不丢，体验更完整。
订单主表（orders）：id、订单编号、用户id、店铺id、桌号、订单金额、支付状态（0未支付/1已支付）、订单状态（0待接单/1已接单/2已完成/3已取消）、创建时间、支付时间。这里订单编号我推荐用时间戳 + 随机数生成，避免并发下重复。
订单明细表（order_detail）：id、订单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_type=authorization_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批量查出菜品信息 List<Dish> 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) { // 从小程序码中解析参数，形如 ?shopId=1&tableNo=A12 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配JDK8，SpringBoot 3.x配JDK17及以上，不要瞎配 |
| 跨域请求被拦截 | 后端没有配置跨域 | 在SpringBoot中写一个CorsFilter或在Controller加@CrossOrigin |
| 订单金额精度丢失 | 数据库用了Double/Float | 金融字段一律用decimal类型，Java对应BigDecimal |
| MyBatis-Plus自动填充的时间为null | 没有配置MetaObjectHandler | 写一个类实现MetaObjectHandler，统一填充createTime和updateTime |
| 管理端页面能打开，接口全部401 | token过期或未携带 | 检查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或JDK11，SpringBoot 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，每写完一个接口就顺手写好文档，字段名、类型、含义都标清楚。这样前后端联调的时候省了无数时间去猜字段，也避免了很多沟通成本。项目里我放的部署说明和论文文档，都是在这个基础上整理出来的，你要是拿这个项目做参考，建议也养成这个习惯。
本文还有配套的精品资源，点击获取
