简介面向餐饮场景的微信扫码点餐/订餐系统毕业设计完整资源包采用uni-app开发小程序端、SpringBoot实现后端接口、Vue搭建管理后台适合Java方向毕业生或需要快速搭建点餐项目的开发者。在快节奏生活下传统人工点餐常需排队或等待服务员效率较低本系统通过餐桌二维码让顾客自助点餐并备注留言商家在管理端统一维护菜品与订单可显著提升用餐体验和餐厅运营效率。资源包含完整前后端源码、MySQL数据库SQL脚本、毕业论文文档及运行截图覆盖扫码桌号点餐、菜品管理、订单管理、分类管理等核心模块。压缩包共455个文件主要类型包括Java与class后端代码、Vue/JS前端逻辑、XML配置文件、SQL数据库脚本、jpg/png图片素材及doc论文文档整体约7.05MB目录结构清晰便于按模块查阅。目前已有1292人学习浏览适合Java毕业设计、课程实训或小型餐饮点餐项目二次开发可帮助掌握微信小程序对接SpringBoot的完整流程、JWT权限校验及前后端分离项目部署等关键技能。1. 微信小程序扫码点餐系统看起来是点餐实际是订单状态机的三端闭环微信小程序扫码点餐这个选题做过的都知道把菜单搬进小程序只是表面真正的难点在三处——扫码之后怎么确定是哪家店哪个桌、订单从待支付到已完成的状态怎么流转不丢、以及微信登录怎么在现在的接口规则下拿到用户身份。这套 uni-app SpringBoot Vue 的扫码点餐源码恰好把这三件事串成一条完整链路小程序端负责扫码进店和下单SpringBoot 后端统一处理菜品查询与订单状态机Vue 管理端负责菜品上架和订单处理。适合准备点餐、订餐类毕业设计的人也适合想快速复用一个前后端分离小程序项目的开发者。2. 系统拆解uni-app点餐端、SpringBoot后端、Vue管理端的分工与数据流这套系统拆开看是三个独立工程跑起来是一条数据链。小程序端只负责把用户的操作翻译成HTTP请求后端把业务规则全部收口菜品查得到、订单建得成、状态改得对管理端是给商家用的后台只做菜品和订单的管理。三者之间没有硬耦合全靠接口约定所以就算你想把管理端从Vue换成别的框架只要后端接口不动小程序端完全不受影响。2.1 前端选型为什么是uni-app而不是原生小程序这类毕设源码里小程序端用uni-app写的比例很高。原因是它用Vue语法前端不用专门学一套WXML和WXSS编译一次就能同时产出微信小程序、H5和App三端代码。对这个点餐项目来说uni-app还有一个实际好处答辩演示时可以直接用H5形态在电脑浏览器里跑不用现场把手机和电脑用微信开发者工具连起来。代价就是它比原生小程序多一层编译遇到界面渲染异常时先得判断是框架问题还是自己的代码问题。点餐端的目录结构一般长这样order-app/ ├── pages/ │ ├── index/ # 扫码落地页与店铺首页 │ ├── menu/ # 菜品列表与分类 │ ├── cart/ # 购物车页面 │ ├── order/ # 订单列表与详情 │ └── mine/ # 我的页面 ├── api/ │ ├── request.js # 统一封装uni.request集中管理baseUrl │ ├── dish.js # 菜品相关接口 │ └── order.js # 订单相关接口 ├── store/ # 购物车、用户信息的全局状态 └── App.vue # 应用入口逻辑说明pages下的每个子目录对应一个页面api目录把HTTP请求按业务拆成模块store目录放跨页面共享状态。这里最需要关注的是api/request.js之后改后端地址只需要动一个文件。购物车和用户信息必须放store否则跳转一次页面数据就丢。参数说明request.js里核心看两个参数baseUrl默认写成localhost联调时必须改成电脑的局域网IPtimeout建议设10秒以上扫码点餐场景里用户经常在弱网环境下使用。选uni-app还有一个长远考虑微信小程序的接口规则和用户授权方式这两年变动频繁uni-app的社区跟进往往比单人项目快遇到接口变更时搜索解决方案更容易命中。2.2 后端分层SpringBoot MyBatis Plus 的经典结构后端的技术栈是SpringBoot MyBatis Plus这是Java毕设里最常见的组合。分层上遵循Controller → Service → Mapper → Entity每层各司其职。Controller只管接收HTTP参数和返回JSONService写业务规则Mapper是数据访问层Entity对应数据库表。以菜品查询为例Controller层典型写法RestController RequestMapping(/api/dish) public class DishController { Autowired private DishService dishService; GetMapping(/list) public Result getDishList(RequestParam Long shopId, RequestParam(required false) Long categoryId) { ListDish list dishService.getDishList(shopId, categoryId); return Result.success(list); } }逻辑说明RestController声明这是一个接口类类上的RequestMapping给所有接口统一加前缀。getDishList接收两个参数shopId必传用来区分店铺categoryId可传用来按分类过滤。返回体统一包一层前端拿到的一律是code、message、data三段结构判断code就知道请求是否成功。参数说明shopId是整个系统里最关键的业务参数扫码点餐场景中一个小程序往往对应多个店铺甚至多个门店所有核心查询都要按shopId过滤。如果源码里没有这个字段说明是单店版后面自己有需求时可以扩展。Service层查询通常用MyBatis Plus的LambdaQueryWrapperpublic ListDish getDishList(Long shopId, Long categoryId) { LambdaQueryWrapperDish wrapper new LambdaQueryWrapper(); wrapper.eq(Dish::getShopId, shopId) .eq(categoryId ! null, Dish::getCategoryId, categoryId) .orderByAsc(Dish::getSort); return dishMapper.selectList(wrapper); }逻辑说明eq的第一个参数是条件开关categoryId为null时这段条件就自动跳过省得写多个if分支。orderByAsc按sort字段升序sort就是后台管理端设置菜品排序时写入的数字。参数说明MyBatis Plus默认开启驼峰转下划线实体类里的shopId自动对应数据库表的shop_id列除非列名确实异常否则不要手动加TableField去覆盖写多了反而乱。2.3 管理端Vue 2 Element UI 的菜品与订单管理管理端用的是Vue 2搭配Element UI目录里包含路由配置、API封装和页面组件。核心页面就两个菜品管理页做增删改查订单管理页处理状态流转。菜品管理页的表格操作列几乎都要用插槽来放编辑和下架按钮Vue 2里最典型的写法el-table :datadishList v-loadingloading el-table-column propname label菜品名称/el-table-column el-table-column propprice label价格/el-table-column el-table-column label操作 width180 template slot-scopescope el-button typetext clickhandleEdit(scope.row.id)编辑/el-button el-button typetext stylecolor:red clickhandleDelete(scope.row.id)下架/el-button /template /el-table-column /el-table逻辑说明slot-scope是Vue 2里获取当前行数据的方式scope.row就是当前遍历的行数据对象取它的id传给编辑或下架方法。这是管理端表格操作列最常见的写法掌握这一个插槽语法基本能应付所有表格按钮场景——这也聊到了Vue面试题里总爱追问的插槽用法。参数说明width固定为180避免两个按钮换行影响布局handleDelete只是在前端调用接口真正的删除逻辑在后端前端不应该直接操作数据。管理端路由就是Vue Router的标准用法没有太多花活。倒是有个实际细节如果管理端要部署到服务器子路径下router要配置base这是部署阶段才会踩的坑。3. 把项目跑起来环境准备、数据库初始化、双端启动与联调拿到源码包之后我一般会先干三件事查README如果有、打开application.yml、看小程序端api目录下的request.js。这三处能暴露90%的坑数据库连不上、接口地址不对、依赖版本冲突。先把这些确认了再启动比直接点IDE的启动按钮效率高得多。下面按实际操作顺序说。3.1 环境准备JDK、Node、微信开发者工具的版本匹配环境版本是第一个翻车点。后端SpringBoot项目建议用JDK 8别看到JDK 17就往上装。源码的pom.xml如果写的是spring-boot-starter-parent 2.xJDK 8是最稳的搭配。管理端是Vue 2项目时Node建议装14或16Node 18以上跑npm install经常报OpenSSL冲突这是第一次启动失败的高频原因。java -version node -v npm -v逻辑说明三条命令分别确认JDK、Node和npm版本。java -version输出1.8.x说明是JDK 8node -v显示v14或v16最合适。版本不合适时硬跑下去要改不少依赖配置代价远高于重装一个版本。参数说明注意不要只看Node主版本npm版本随Node一起变化如果npm install时提示npm版本过旧用npm install -g npm升级npm本身就行。3.2 数据库初始化SQL脚本导入与自动建表源码包里一般带db目录或SQL脚本。常见做法是先用Navicat或命令行建库建表再改application.yml里的账号密码。如果源码没给脚本后端又是MyBatis Plus 3.5.3以上还有另一个省事的办法让MyBatis Plus根据实体类自动生成建表SQL这个功能在补表时很实用。# 命令行方式导入SQL注意把路径换成实际位置 mysql -uroot -p source /home/demo/order_system.sql;逻辑说明source后面跟SQL脚本的绝对路径。执行前先确认MySQL服务已启动root账号能正常登录。导入完成后检查表名是否和数据访问层里的实体对应比如dish、orders、category脚本执行到一半报错时不要直接跳过往往后面还会连锁报错。参数说明如果脚本里已经包含CREATE DATABASE order_system导入后无需再手工建库如果只有CREATE TABLE需要先用CREATE DATABASE建库再use进入否则表会建到默认库里。3.3 后端启动application.yml中三个关键配置启动后端前必须检查application.yml里的三块内容数据源、文件上传路径、微信小程序配置。这三样直接决定后面联调是否会翻车。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/order_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver file: upload-path: /home/demo/upload/ # Windows下改成 D:/upload/ wx: appid: your_appid secret: your_secret逻辑说明三块配置分别对接MySQL、图片磁盘目录、微信登录接口。数据源URL里的serverTimezoneAsia/Shanghai是必备参数不加的话日期字段会报时区错误。file.upload-path是图片上传落盘目录这个路径必须和返回图片URL的前缀对应否则管理端上传成功、小程序端访问时却404。wx.appid和wx.secret要换成自己的小程序账号信息否则微信登录一定失败。参数说明密码一行的123456只是示例以源码包里为准upload-path不要放在target或编译目录下mvn clean之后图片会被全部清掉。后端启动命令mvn spring-boot:run逻辑说明开发阶段用这一行改动代码后重启速度快。它会在Maven编译后直接启动SpringBoot应用控制台会打印端口等信息看到Spring Boot Started就说明启动成功。mvn clean package -DskipTests java -jar target/order-system-0.0.1-SNAPSHOT.jar逻辑说明第一行打包跳过测试以节省时间第二行运行打出来的jar包。jar包名以pom.xml里的artifactId和version为准如果找不到去target目录下ls一下就知道。参数说明两个命令要在同一目录下执行否则target路径对不上。3.4 小程序端启动HBuilderX导入与request地址修改小程序端是uni-app工程用HBuilderX导入即可。导入后先别急着点编译打开api/request.js把baseUrl改成后端电脑的局域网IP。const request (options) { return new Promise((resolve, reject) { uni.request({ url: http://192.168.1.100:8080 options.url, method: options.method || GET, data: options.data || {}, header: { token: uni.getStorageSync(token) || }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else { reject(res.data); } }, fail: (err) reject(err) }); }); };逻辑说明url直接拼了局域网IP这是微信开发者工具联调阶段的常规做法。微信小程序的正式环境要求接口必须是HTTPS但开发阶段可以在工具里勾选“不校验合法域名”所以http协议可以直接用。header里带token从本地存储读取登录接口返回的token就存在这里。参数说明192.168.1.100是示例要替换成本机实际IP。特别注意两点真机预览时不能用127.0.0.1必须用电脑在局域网里能访问到的IP手机和电脑要连同一个WiFi。提示如果你在真机上发现请求全部超时先ping一下这个局域网IP通不通很多时候是防火墙没放行8080端口。图片路径也是这里的高频坑如果小程序里的菜品图片是相对路径图片前缀同样要拼上这个IP否则进入菜单页面会全是裂图。3.5 管理端启动npm install、代理与源码分发管理端是Vue 2工程启动顺序是先装依赖、再起dev服务。把源码发给别人的时候记得删掉node_modules目录只发源码不然压缩包体积会大十几倍。对方拿到后自己npm install就行这也是“Vue项目源码怎么发给别人”这个问题的标准答案。npm install --registryhttps://registry.npmmirror.com npm run dev逻辑说明第一行指定npm镜像源很多人在npm install这一步卡很久就是因为默认源下载慢或个别包拉不下来。第二行启动开发服务器Vue 2项目默认跑在8080端口如果和后端端口冲突在package.json里改dev脚本。参数说明镜像源按需添加如果默认源速度正常不加这一行也能装完。Vue 2项目的npm install如果报了OpenSSL相关的ERR_OSSL_EVP_UNSUPPORTED基本就是Node版本太高切回Node 16解决。管理端接口地址一般写在vue.config.js的proxy里这是前后端联调的关键一环devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }逻辑说明proxy的意思是管理端页面发起的/api路径请求都被转发到后端localhost:8080。管理端代码里写相对路径即可不用把后端IP写死。后端换机器后只需要改target一处。参数说明changeOrigin必须为true作用是把请求头里的Host改成target域名部分后端校验了Host头不改会报跨域错误或直接被拒。4. 关键链路扫码进店、购物车、订单状态机与微信登录跑通三端之后这套系统真正核心的业务链路就剩四条扫码进店、购物车、订单状态机、微信登录。前三条是点餐业务的命脉第四条是小程序端所有用户识别的基础。下面拆开说每条链路代码怎么走以及哪些地方容易漏。4.1 扫码进店scene参数与shopId的传递微信小程序扫码进店信息是通过小程序码的scene参数带进来的。常规做法是每个桌台生成一个带参数的小程序码参数里编码shopId和tableNo用户扫码后小程序冷启动在onLoad里解析scene字段。onLoad(options) { let scene decodeURIComponent(options.scene || ); // scene格式: shopId1tableNo12 let params {}; scene.split().forEach(item { let parts item.split(); params[parts[0]] parts[1]; }); this.shopId params.shopId; this.tableNo params.tableNo; this.getDishList(this.shopId); }逻辑说明扫码进入小程序时scene参数会经过URL编码所以第一步是decodeURIComponent然后按拆成键值对。拿到shopId后立刻调用菜品列表接口用户是无感的不会看到空白等待页。tableNo在提交订单时一起回传后端后端通过它知道这张订单是哪一桌下的。参数说明生成小程序码时scene有长度限制实际约32个可见字符所以只能传shopId和tableNo这类短ID不要放中文字符串或长描述。另外同一个用户扫同一张码多次onLoad每次都会执行要注意不要重复创建订单。4.2 购物车本地缓存还是后端暂存购物车的实现方式要去看源码的store目录。常见做法是前端本地缓存因为点餐购物车的特点是增删改非常频繁、用户可能中途退出、只有最终提交订单时数据才需要同步给后端。用本地缓存能降低后端压力也省了设计购物车过期策略的麻烦。const state { items: uni.getStorageSync(cartItems) || [] }; const mutations { addItem(state, dish) { let found state.items.find(item item.dishId dish.id); if (found) { found.count; } else { state.items.push({ dishId: dish.id, name: dish.name, price: dish.price, count: 1 }); } uni.setStorageSync(cartItems, state.items); } };逻辑说明addItem先检查购物车是否已存在这道菜存在就数量加一不存在就追加一条新记录。每次变更后立刻写回storage用户就算杀掉小程序进程再重进购物车数据还在。价格在加入购物车那一刻就做快照后续后台改了价格这一单仍以加购时价格为准这也是点餐系统的行业习惯。参数说明storage的key统一用cartItems提交订单时也从这里读。如果源码支持多店铺这个key要加上shopId后缀比如cartItems_1、cartItems_2否则用户在不同店铺间切换时购物车会串。4.3 订单状态机从待支付到已完成订单状态是这套源码里业务含量最高的地方。常规状态流转是待支付(0) → 已支付/制作中(1) → 已完成(2)中间还穿插已取消(-1)和退款中(3)。后端Service层通常维护一个带校验的状态更新方法public boolean updateOrderStatus(Long orderId, Integer fromStatus, Integer toStatus) { Order order orderMapper.selectById(orderId); if (order.getStatus() ! fromStatus) { return false; } order.setStatus(toStatus); return orderMapper.updateById(order) 0; }逻辑说明fromStatus和toStatus是成对出现的调用方必须说清楚“我希望从哪个状态变成哪个状态”。如果当前状态已经不是fromStatus说明请求已经失效直接拒绝。这个写法可以挡掉大量重复提交和乱序请求比无脑setStatus安全得多。参数说明实际业务中已支付状态是后端收到微信支付回调后更新的不是前端拿到支付成功就改。前端改状态只是界面显示真正状态变更必须以支付回调为准。这一点答辩时讲清楚会显得对业务链路有真实理解。4.4 微信登录wx.login换openid手机号授权的新姿势微信登录是踩坑高发区。老代码里常见的wx.getUserInfo拿用户昵称头像的方式在新版微信里已经不再返回真实数据。正规做法是wx.login拿到code后端拿code去微信服务端接口换openid然后由后端自己生成业务token返回给小程序。手机号获取也改了现在用button的open-typegetPhoneNumber触发再由后端解密回调参数拿到手机号。PostMapping(/wx/login) public Result wxLogin(RequestBody MapString, String body) { String code body.get(code); // 后端用code调微信服务端接口换openid和session_key String openid wxService.code2Session(code); String token jwtService.createToken(openid); return Result.success(token); }逻辑说明code2Session是对微信服务端接口的封装内部需要传appid和secret换取成功后拿到openid。后端再用JWT生成业务token返回给小程序小程序端后续所有请求都带这个token后端解析token拿到openid就知道当前请求是哪个用户发出的。参数说明手机号获取现在有门槛个人主体的小程序开通不了获取手机号的能力这是很多人测试时发现手机号一直拿不到的原因。如果源码里有手机号绑定逻辑发布前先确认账号主体是否有权限没有权限就改成手机号验证码方案或者降级成“用户手动填写手机号”。5. 避坑指南跑通这套点餐源码的五个典型翻车现场下面这五个坑是不同电脑上跑同一套点餐源码时真实遇到过的。统一按“现象、原因、解决”三步写方便对照排查。每一个都附了当时定位问题用的关键操作。5.1 翻车一springboot版本太高MyBatis Plus starter拉不下来现象pom.xml里引入mybatis-plus-boot-starter后要么mvn compile直接报找不到类要么启动时报ClassNotFoundException。原因SpringBoot 3.x把javax包体系换成了jakarta而老版本的MyBatis Plus starter还是按javax编译的版本直接冲突。这种毕设源码大多是针对SpringBoot 2.x设计的强行用3.x自然跑不动。解决优先切回SpringBoot 2.7.x配合MyBatis Plus 3.5.x。确实想用SpringBoot 3.x就换mybatis-plus-spring-boot3-starter同时检查druid数据源分页插件等配套依赖是否也有对应版本只是改动面会变大很多。5.2 翻车二微信小程序顶部导航栏高度适配按钮被顶出屏幕现象点餐页自定义了返回按钮和店铺名在真机上打开按钮紧贴状态栏甚至被系统时间覆盖。原因自定义导航栏时没有考虑状态栏高度。iPhone刘海屏状态栏约44pxAndroid一般20dp以上前端硬编码一个固定高度必然适配失败。解决通过uni.getSystemInfoSync()动态读取statusBarHeight把它作为导航栏padding-top的值。const systemInfo uni.getSystemInfoSync(); this.statusBarHeight systemInfo.statusBarHeight;逻辑说明页面加载时读一次状态栏高度存进data模板里绑定到导航栏容器。不同机型高度不同必须实时获取不能写死。这个属于微信小程序自定义导航栏的必修课遇到导航按钮顶出去先看这个值。5.3 翻车三管理端图片上传了小程序端却404现象管理端上传菜品图后回显正常小程序端菜品列表图片全白。原因图片返回的URL是绝对路径比如http://localhost:8080/upload/xxx.jpg。管理端跑在开发机上localhost没问题但小程序端在开发者工具或真机里这个地址指向的并不是后端服务器。解决图片上传保存路径和返回URL的base前缀都做成服务器地址配置项。小程序端访问图片时前缀要拼后端所在机器的局域网IP或线上域名。还要注意上传目录别放在target里重新打包后目录会被清空。5.4 翻车四订单超时未支付定时任务没生效现象下了单不支付等了很久订单还是待支付自动取消完全没有触发。原因常见的三种。启动类上没加EnableScheduling导致定时任务注解没被扫描到。cron表达式写错把每30分钟写成了每30秒资源白白消耗。定时任务方法里只查了status等于待支付但没判断订单创建时间是否超过15分钟把刚新下的单也一起处理了。解决先确认启动类上有EnableScheduling再验cron表达式的执行频率。更稳的习惯是不完全依赖定时任务下单后把过期时间作为参数支付回调或用户查询订单时做懒判断超时的自动置为已取消这样即使定时任务挂掉也不会出现死订单。5.5 翻车五微信开发者工具里request域名校验卡住现象小程序端所有请求都报“不在以下request合法域名列表中”接口全挂。原因微信开发者工具默认开启合法域名校验开发阶段用的是http加局域网IP肯定不在域名白名单里。解决在开发者工具右上角“详情”里的“本地设置”中勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。开发阶段一律勾选上线前再把配置换成正式的HTTPS域名。6. 进阶改造从可用到好用值得动手的三个小方向源码跑通只是开始。如果你想在答辩演示或者简历项目描述里多两个亮点我建议优先改这三个方向菜品排序、订单语音播报、多门店支持。它们都不复杂但每一个都能让系统看起来更像正式上线过的产品。6.1 菜品排序管理端拖拽排序与后端sort字段菜品管理页目前大概率是按上架时间排列。升级方式是加一个sort字段管理端用拖拽组件调整排序后端更新sort值小程序端查询时按sort升序返回。菜品排序在餐牌场景里几乎是刚需招牌菜必须排在最前面。wrapper.orderByAsc(Dish::getSort, Dish::getUpdateTime);逻辑说明sort相同时再按更新时间倒序这样同一天手动调过的菜能保持相对顺序稳定。只需要在管理端加一个排序拖拽功能数据库加一列接口排序规则改一行改动范围很小但演示效果很直观。6.2 订单语音播报小程序端订阅消息与管理端轮询餐厅场景里后厨需要听到新订单提醒。最简单的方式是管理端用一个轮询接口每隔10秒查一次是否有新订单查到后播放一段本地音频提示。不要一上来就做WebSocket轮询够用且不容易出问题。如果想做到小程序端通知顾客取餐可以接入订阅消息但订阅消息有一次性模板限制需要用户主动订阅实际转化率不高演示场景里慎用。6.3 多门店扩展把shopId从写死改成上下文参数源码里如果shopId只是常量扩展多门店会非常痛苦。建议把所有涉及shopId的接口和数据库查询都改成从请求参数或登录token中获取并确保购物车缓存键带上shopId。多门店支持之后管理端也可以按门店过滤订单和菜品这个扩展会让项目在架构层面的评语好看很多。从那以后我每次拿到带小程序的毕设源码都会强制先看三样东西application.yml里的数据源和上传路径、request.js里的baseUrl、以及数据库脚本里的表名是否和实体对得上。三样看完再启动翻车的概率能少一半。希望帮到你。本文还有配套的精品资源点击获取
简介面向餐饮场景的微信扫码点餐/订餐系统毕业设计完整资源包采用uni-app开发小程序端、SpringBoot实现后端接口、Vue搭建管理后台适合Java方向毕业生或需要快速搭建点餐项目的开发者。在快节奏生活下传统人工点餐常需排队或等待服务员效率较低本系统通过餐桌二维码让顾客自助点餐并备注留言商家在管理端统一维护菜品与订单可显著提升用餐体验和餐厅运营效率。资源包含完整前后端源码、MySQL数据库SQL脚本、毕业论文文档及运行截图覆盖扫码桌号点餐、菜品管理、订单管理、分类管理等核心模块。压缩包共455个文件主要类型包括Java与class后端代码、Vue/JS前端逻辑、XML配置文件、SQL数据库脚本、jpg/png图片素材及doc论文文档整体约7.05MB目录结构清晰便于按模块查阅。目前已有1292人学习浏览适合Java毕业设计、课程实训或小型餐饮点餐项目二次开发可帮助掌握微信小程序对接SpringBoot的完整流程、JWT权限校验及前后端分离项目部署等关键技能。1. 微信小程序扫码点餐系统看起来是点餐实际是订单状态机的三端闭环微信小程序扫码点餐这个选题做过的都知道把菜单搬进小程序只是表面真正的难点在三处——扫码之后怎么确定是哪家店哪个桌、订单从待支付到已完成的状态怎么流转不丢、以及微信登录怎么在现在的接口规则下拿到用户身份。这套 uni-app SpringBoot Vue 的扫码点餐源码恰好把这三件事串成一条完整链路小程序端负责扫码进店和下单SpringBoot 后端统一处理菜品查询与订单状态机Vue 管理端负责菜品上架和订单处理。适合准备点餐、订餐类毕业设计的人也适合想快速复用一个前后端分离小程序项目的开发者。2. 系统拆解uni-app点餐端、SpringBoot后端、Vue管理端的分工与数据流这套系统拆开看是三个独立工程跑起来是一条数据链。小程序端只负责把用户的操作翻译成HTTP请求后端把业务规则全部收口菜品查得到、订单建得成、状态改得对管理端是给商家用的后台只做菜品和订单的管理。三者之间没有硬耦合全靠接口约定所以就算你想把管理端从Vue换成别的框架只要后端接口不动小程序端完全不受影响。2.1 前端选型为什么是uni-app而不是原生小程序这类毕设源码里小程序端用uni-app写的比例很高。原因是它用Vue语法前端不用专门学一套WXML和WXSS编译一次就能同时产出微信小程序、H5和App三端代码。对这个点餐项目来说uni-app还有一个实际好处答辩演示时可以直接用H5形态在电脑浏览器里跑不用现场把手机和电脑用微信开发者工具连起来。代价就是它比原生小程序多一层编译遇到界面渲染异常时先得判断是框架问题还是自己的代码问题。点餐端的目录结构一般长这样order-app/ ├── pages/ │ ├── index/ # 扫码落地页与店铺首页 │ ├── menu/ # 菜品列表与分类 │ ├── cart/ # 购物车页面 │ ├── order/ # 订单列表与详情 │ └── mine/ # 我的页面 ├── api/ │ ├── request.js # 统一封装uni.request集中管理baseUrl │ ├── dish.js # 菜品相关接口 │ └── order.js # 订单相关接口 ├── store/ # 购物车、用户信息的全局状态 └── App.vue # 应用入口逻辑说明pages下的每个子目录对应一个页面api目录把HTTP请求按业务拆成模块store目录放跨页面共享状态。这里最需要关注的是api/request.js之后改后端地址只需要动一个文件。购物车和用户信息必须放store否则跳转一次页面数据就丢。参数说明request.js里核心看两个参数baseUrl默认写成localhost联调时必须改成电脑的局域网IPtimeout建议设10秒以上扫码点餐场景里用户经常在弱网环境下使用。选uni-app还有一个长远考虑微信小程序的接口规则和用户授权方式这两年变动频繁uni-app的社区跟进往往比单人项目快遇到接口变更时搜索解决方案更容易命中。2.2 后端分层SpringBoot MyBatis Plus 的经典结构后端的技术栈是SpringBoot MyBatis Plus这是Java毕设里最常见的组合。分层上遵循Controller → Service → Mapper → Entity每层各司其职。Controller只管接收HTTP参数和返回JSONService写业务规则Mapper是数据访问层Entity对应数据库表。以菜品查询为例Controller层典型写法RestController RequestMapping(/api/dish) public class DishController { Autowired private DishService dishService; GetMapping(/list) public Result getDishList(RequestParam Long shopId, RequestParam(required false) Long categoryId) { ListDish list dishService.getDishList(shopId, categoryId); return Result.success(list); } }逻辑说明RestController声明这是一个接口类类上的RequestMapping给所有接口统一加前缀。getDishList接收两个参数shopId必传用来区分店铺categoryId可传用来按分类过滤。返回体统一包一层前端拿到的一律是code、message、data三段结构判断code就知道请求是否成功。参数说明shopId是整个系统里最关键的业务参数扫码点餐场景中一个小程序往往对应多个店铺甚至多个门店所有核心查询都要按shopId过滤。如果源码里没有这个字段说明是单店版后面自己有需求时可以扩展。Service层查询通常用MyBatis Plus的LambdaQueryWrapperpublic ListDish getDishList(Long shopId, Long categoryId) { LambdaQueryWrapperDish wrapper new LambdaQueryWrapper(); wrapper.eq(Dish::getShopId, shopId) .eq(categoryId ! null, Dish::getCategoryId, categoryId) .orderByAsc(Dish::getSort); return dishMapper.selectList(wrapper); }逻辑说明eq的第一个参数是条件开关categoryId为null时这段条件就自动跳过省得写多个if分支。orderByAsc按sort字段升序sort就是后台管理端设置菜品排序时写入的数字。参数说明MyBatis Plus默认开启驼峰转下划线实体类里的shopId自动对应数据库表的shop_id列除非列名确实异常否则不要手动加TableField去覆盖写多了反而乱。2.3 管理端Vue 2 Element UI 的菜品与订单管理管理端用的是Vue 2搭配Element UI目录里包含路由配置、API封装和页面组件。核心页面就两个菜品管理页做增删改查订单管理页处理状态流转。菜品管理页的表格操作列几乎都要用插槽来放编辑和下架按钮Vue 2里最典型的写法el-table :datadishList v-loadingloading el-table-column propname label菜品名称/el-table-column el-table-column propprice label价格/el-table-column el-table-column label操作 width180 template slot-scopescope el-button typetext clickhandleEdit(scope.row.id)编辑/el-button el-button typetext stylecolor:red clickhandleDelete(scope.row.id)下架/el-button /template /el-table-column /el-table逻辑说明slot-scope是Vue 2里获取当前行数据的方式scope.row就是当前遍历的行数据对象取它的id传给编辑或下架方法。这是管理端表格操作列最常见的写法掌握这一个插槽语法基本能应付所有表格按钮场景——这也聊到了Vue面试题里总爱追问的插槽用法。参数说明width固定为180避免两个按钮换行影响布局handleDelete只是在前端调用接口真正的删除逻辑在后端前端不应该直接操作数据。管理端路由就是Vue Router的标准用法没有太多花活。倒是有个实际细节如果管理端要部署到服务器子路径下router要配置base这是部署阶段才会踩的坑。3. 把项目跑起来环境准备、数据库初始化、双端启动与联调拿到源码包之后我一般会先干三件事查README如果有、打开application.yml、看小程序端api目录下的request.js。这三处能暴露90%的坑数据库连不上、接口地址不对、依赖版本冲突。先把这些确认了再启动比直接点IDE的启动按钮效率高得多。下面按实际操作顺序说。3.1 环境准备JDK、Node、微信开发者工具的版本匹配环境版本是第一个翻车点。后端SpringBoot项目建议用JDK 8别看到JDK 17就往上装。源码的pom.xml如果写的是spring-boot-starter-parent 2.xJDK 8是最稳的搭配。管理端是Vue 2项目时Node建议装14或16Node 18以上跑npm install经常报OpenSSL冲突这是第一次启动失败的高频原因。java -version node -v npm -v逻辑说明三条命令分别确认JDK、Node和npm版本。java -version输出1.8.x说明是JDK 8node -v显示v14或v16最合适。版本不合适时硬跑下去要改不少依赖配置代价远高于重装一个版本。参数说明注意不要只看Node主版本npm版本随Node一起变化如果npm install时提示npm版本过旧用npm install -g npm升级npm本身就行。3.2 数据库初始化SQL脚本导入与自动建表源码包里一般带db目录或SQL脚本。常见做法是先用Navicat或命令行建库建表再改application.yml里的账号密码。如果源码没给脚本后端又是MyBatis Plus 3.5.3以上还有另一个省事的办法让MyBatis Plus根据实体类自动生成建表SQL这个功能在补表时很实用。# 命令行方式导入SQL注意把路径换成实际位置 mysql -uroot -p source /home/demo/order_system.sql;逻辑说明source后面跟SQL脚本的绝对路径。执行前先确认MySQL服务已启动root账号能正常登录。导入完成后检查表名是否和数据访问层里的实体对应比如dish、orders、category脚本执行到一半报错时不要直接跳过往往后面还会连锁报错。参数说明如果脚本里已经包含CREATE DATABASE order_system导入后无需再手工建库如果只有CREATE TABLE需要先用CREATE DATABASE建库再use进入否则表会建到默认库里。3.3 后端启动application.yml中三个关键配置启动后端前必须检查application.yml里的三块内容数据源、文件上传路径、微信小程序配置。这三样直接决定后面联调是否会翻车。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/order_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver file: upload-path: /home/demo/upload/ # Windows下改成 D:/upload/ wx: appid: your_appid secret: your_secret逻辑说明三块配置分别对接MySQL、图片磁盘目录、微信登录接口。数据源URL里的serverTimezoneAsia/Shanghai是必备参数不加的话日期字段会报时区错误。file.upload-path是图片上传落盘目录这个路径必须和返回图片URL的前缀对应否则管理端上传成功、小程序端访问时却404。wx.appid和wx.secret要换成自己的小程序账号信息否则微信登录一定失败。参数说明密码一行的123456只是示例以源码包里为准upload-path不要放在target或编译目录下mvn clean之后图片会被全部清掉。后端启动命令mvn spring-boot:run逻辑说明开发阶段用这一行改动代码后重启速度快。它会在Maven编译后直接启动SpringBoot应用控制台会打印端口等信息看到Spring Boot Started就说明启动成功。mvn clean package -DskipTests java -jar target/order-system-0.0.1-SNAPSHOT.jar逻辑说明第一行打包跳过测试以节省时间第二行运行打出来的jar包。jar包名以pom.xml里的artifactId和version为准如果找不到去target目录下ls一下就知道。参数说明两个命令要在同一目录下执行否则target路径对不上。3.4 小程序端启动HBuilderX导入与request地址修改小程序端是uni-app工程用HBuilderX导入即可。导入后先别急着点编译打开api/request.js把baseUrl改成后端电脑的局域网IP。const request (options) { return new Promise((resolve, reject) { uni.request({ url: http://192.168.1.100:8080 options.url, method: options.method || GET, data: options.data || {}, header: { token: uni.getStorageSync(token) || }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else { reject(res.data); } }, fail: (err) reject(err) }); }); };逻辑说明url直接拼了局域网IP这是微信开发者工具联调阶段的常规做法。微信小程序的正式环境要求接口必须是HTTPS但开发阶段可以在工具里勾选“不校验合法域名”所以http协议可以直接用。header里带token从本地存储读取登录接口返回的token就存在这里。参数说明192.168.1.100是示例要替换成本机实际IP。特别注意两点真机预览时不能用127.0.0.1必须用电脑在局域网里能访问到的IP手机和电脑要连同一个WiFi。提示如果你在真机上发现请求全部超时先ping一下这个局域网IP通不通很多时候是防火墙没放行8080端口。图片路径也是这里的高频坑如果小程序里的菜品图片是相对路径图片前缀同样要拼上这个IP否则进入菜单页面会全是裂图。3.5 管理端启动npm install、代理与源码分发管理端是Vue 2工程启动顺序是先装依赖、再起dev服务。把源码发给别人的时候记得删掉node_modules目录只发源码不然压缩包体积会大十几倍。对方拿到后自己npm install就行这也是“Vue项目源码怎么发给别人”这个问题的标准答案。npm install --registryhttps://registry.npmmirror.com npm run dev逻辑说明第一行指定npm镜像源很多人在npm install这一步卡很久就是因为默认源下载慢或个别包拉不下来。第二行启动开发服务器Vue 2项目默认跑在8080端口如果和后端端口冲突在package.json里改dev脚本。参数说明镜像源按需添加如果默认源速度正常不加这一行也能装完。Vue 2项目的npm install如果报了OpenSSL相关的ERR_OSSL_EVP_UNSUPPORTED基本就是Node版本太高切回Node 16解决。管理端接口地址一般写在vue.config.js的proxy里这是前后端联调的关键一环devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }逻辑说明proxy的意思是管理端页面发起的/api路径请求都被转发到后端localhost:8080。管理端代码里写相对路径即可不用把后端IP写死。后端换机器后只需要改target一处。参数说明changeOrigin必须为true作用是把请求头里的Host改成target域名部分后端校验了Host头不改会报跨域错误或直接被拒。4. 关键链路扫码进店、购物车、订单状态机与微信登录跑通三端之后这套系统真正核心的业务链路就剩四条扫码进店、购物车、订单状态机、微信登录。前三条是点餐业务的命脉第四条是小程序端所有用户识别的基础。下面拆开说每条链路代码怎么走以及哪些地方容易漏。4.1 扫码进店scene参数与shopId的传递微信小程序扫码进店信息是通过小程序码的scene参数带进来的。常规做法是每个桌台生成一个带参数的小程序码参数里编码shopId和tableNo用户扫码后小程序冷启动在onLoad里解析scene字段。onLoad(options) { let scene decodeURIComponent(options.scene || ); // scene格式: shopId1tableNo12 let params {}; scene.split().forEach(item { let parts item.split(); params[parts[0]] parts[1]; }); this.shopId params.shopId; this.tableNo params.tableNo; this.getDishList(this.shopId); }逻辑说明扫码进入小程序时scene参数会经过URL编码所以第一步是decodeURIComponent然后按拆成键值对。拿到shopId后立刻调用菜品列表接口用户是无感的不会看到空白等待页。tableNo在提交订单时一起回传后端后端通过它知道这张订单是哪一桌下的。参数说明生成小程序码时scene有长度限制实际约32个可见字符所以只能传shopId和tableNo这类短ID不要放中文字符串或长描述。另外同一个用户扫同一张码多次onLoad每次都会执行要注意不要重复创建订单。4.2 购物车本地缓存还是后端暂存购物车的实现方式要去看源码的store目录。常见做法是前端本地缓存因为点餐购物车的特点是增删改非常频繁、用户可能中途退出、只有最终提交订单时数据才需要同步给后端。用本地缓存能降低后端压力也省了设计购物车过期策略的麻烦。const state { items: uni.getStorageSync(cartItems) || [] }; const mutations { addItem(state, dish) { let found state.items.find(item item.dishId dish.id); if (found) { found.count; } else { state.items.push({ dishId: dish.id, name: dish.name, price: dish.price, count: 1 }); } uni.setStorageSync(cartItems, state.items); } };逻辑说明addItem先检查购物车是否已存在这道菜存在就数量加一不存在就追加一条新记录。每次变更后立刻写回storage用户就算杀掉小程序进程再重进购物车数据还在。价格在加入购物车那一刻就做快照后续后台改了价格这一单仍以加购时价格为准这也是点餐系统的行业习惯。参数说明storage的key统一用cartItems提交订单时也从这里读。如果源码支持多店铺这个key要加上shopId后缀比如cartItems_1、cartItems_2否则用户在不同店铺间切换时购物车会串。4.3 订单状态机从待支付到已完成订单状态是这套源码里业务含量最高的地方。常规状态流转是待支付(0) → 已支付/制作中(1) → 已完成(2)中间还穿插已取消(-1)和退款中(3)。后端Service层通常维护一个带校验的状态更新方法public boolean updateOrderStatus(Long orderId, Integer fromStatus, Integer toStatus) { Order order orderMapper.selectById(orderId); if (order.getStatus() ! fromStatus) { return false; } order.setStatus(toStatus); return orderMapper.updateById(order) 0; }逻辑说明fromStatus和toStatus是成对出现的调用方必须说清楚“我希望从哪个状态变成哪个状态”。如果当前状态已经不是fromStatus说明请求已经失效直接拒绝。这个写法可以挡掉大量重复提交和乱序请求比无脑setStatus安全得多。参数说明实际业务中已支付状态是后端收到微信支付回调后更新的不是前端拿到支付成功就改。前端改状态只是界面显示真正状态变更必须以支付回调为准。这一点答辩时讲清楚会显得对业务链路有真实理解。4.4 微信登录wx.login换openid手机号授权的新姿势微信登录是踩坑高发区。老代码里常见的wx.getUserInfo拿用户昵称头像的方式在新版微信里已经不再返回真实数据。正规做法是wx.login拿到code后端拿code去微信服务端接口换openid然后由后端自己生成业务token返回给小程序。手机号获取也改了现在用button的open-typegetPhoneNumber触发再由后端解密回调参数拿到手机号。PostMapping(/wx/login) public Result wxLogin(RequestBody MapString, String body) { String code body.get(code); // 后端用code调微信服务端接口换openid和session_key String openid wxService.code2Session(code); String token jwtService.createToken(openid); return Result.success(token); }逻辑说明code2Session是对微信服务端接口的封装内部需要传appid和secret换取成功后拿到openid。后端再用JWT生成业务token返回给小程序小程序端后续所有请求都带这个token后端解析token拿到openid就知道当前请求是哪个用户发出的。参数说明手机号获取现在有门槛个人主体的小程序开通不了获取手机号的能力这是很多人测试时发现手机号一直拿不到的原因。如果源码里有手机号绑定逻辑发布前先确认账号主体是否有权限没有权限就改成手机号验证码方案或者降级成“用户手动填写手机号”。5. 避坑指南跑通这套点餐源码的五个典型翻车现场下面这五个坑是不同电脑上跑同一套点餐源码时真实遇到过的。统一按“现象、原因、解决”三步写方便对照排查。每一个都附了当时定位问题用的关键操作。5.1 翻车一springboot版本太高MyBatis Plus starter拉不下来现象pom.xml里引入mybatis-plus-boot-starter后要么mvn compile直接报找不到类要么启动时报ClassNotFoundException。原因SpringBoot 3.x把javax包体系换成了jakarta而老版本的MyBatis Plus starter还是按javax编译的版本直接冲突。这种毕设源码大多是针对SpringBoot 2.x设计的强行用3.x自然跑不动。解决优先切回SpringBoot 2.7.x配合MyBatis Plus 3.5.x。确实想用SpringBoot 3.x就换mybatis-plus-spring-boot3-starter同时检查druid数据源分页插件等配套依赖是否也有对应版本只是改动面会变大很多。5.2 翻车二微信小程序顶部导航栏高度适配按钮被顶出屏幕现象点餐页自定义了返回按钮和店铺名在真机上打开按钮紧贴状态栏甚至被系统时间覆盖。原因自定义导航栏时没有考虑状态栏高度。iPhone刘海屏状态栏约44pxAndroid一般20dp以上前端硬编码一个固定高度必然适配失败。解决通过uni.getSystemInfoSync()动态读取statusBarHeight把它作为导航栏padding-top的值。const systemInfo uni.getSystemInfoSync(); this.statusBarHeight systemInfo.statusBarHeight;逻辑说明页面加载时读一次状态栏高度存进data模板里绑定到导航栏容器。不同机型高度不同必须实时获取不能写死。这个属于微信小程序自定义导航栏的必修课遇到导航按钮顶出去先看这个值。5.3 翻车三管理端图片上传了小程序端却404现象管理端上传菜品图后回显正常小程序端菜品列表图片全白。原因图片返回的URL是绝对路径比如http://localhost:8080/upload/xxx.jpg。管理端跑在开发机上localhost没问题但小程序端在开发者工具或真机里这个地址指向的并不是后端服务器。解决图片上传保存路径和返回URL的base前缀都做成服务器地址配置项。小程序端访问图片时前缀要拼后端所在机器的局域网IP或线上域名。还要注意上传目录别放在target里重新打包后目录会被清空。5.4 翻车四订单超时未支付定时任务没生效现象下了单不支付等了很久订单还是待支付自动取消完全没有触发。原因常见的三种。启动类上没加EnableScheduling导致定时任务注解没被扫描到。cron表达式写错把每30分钟写成了每30秒资源白白消耗。定时任务方法里只查了status等于待支付但没判断订单创建时间是否超过15分钟把刚新下的单也一起处理了。解决先确认启动类上有EnableScheduling再验cron表达式的执行频率。更稳的习惯是不完全依赖定时任务下单后把过期时间作为参数支付回调或用户查询订单时做懒判断超时的自动置为已取消这样即使定时任务挂掉也不会出现死订单。5.5 翻车五微信开发者工具里request域名校验卡住现象小程序端所有请求都报“不在以下request合法域名列表中”接口全挂。原因微信开发者工具默认开启合法域名校验开发阶段用的是http加局域网IP肯定不在域名白名单里。解决在开发者工具右上角“详情”里的“本地设置”中勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。开发阶段一律勾选上线前再把配置换成正式的HTTPS域名。6. 进阶改造从可用到好用值得动手的三个小方向源码跑通只是开始。如果你想在答辩演示或者简历项目描述里多两个亮点我建议优先改这三个方向菜品排序、订单语音播报、多门店支持。它们都不复杂但每一个都能让系统看起来更像正式上线过的产品。6.1 菜品排序管理端拖拽排序与后端sort字段菜品管理页目前大概率是按上架时间排列。升级方式是加一个sort字段管理端用拖拽组件调整排序后端更新sort值小程序端查询时按sort升序返回。菜品排序在餐牌场景里几乎是刚需招牌菜必须排在最前面。wrapper.orderByAsc(Dish::getSort, Dish::getUpdateTime);逻辑说明sort相同时再按更新时间倒序这样同一天手动调过的菜能保持相对顺序稳定。只需要在管理端加一个排序拖拽功能数据库加一列接口排序规则改一行改动范围很小但演示效果很直观。6.2 订单语音播报小程序端订阅消息与管理端轮询餐厅场景里后厨需要听到新订单提醒。最简单的方式是管理端用一个轮询接口每隔10秒查一次是否有新订单查到后播放一段本地音频提示。不要一上来就做WebSocket轮询够用且不容易出问题。如果想做到小程序端通知顾客取餐可以接入订阅消息但订阅消息有一次性模板限制需要用户主动订阅实际转化率不高演示场景里慎用。6.3 多门店扩展把shopId从写死改成上下文参数源码里如果shopId只是常量扩展多门店会非常痛苦。建议把所有涉及shopId的接口和数据库查询都改成从请求参数或登录token中获取并确保购物车缓存键带上shopId。多门店支持之后管理端也可以按门店过滤订单和菜品这个扩展会让项目在架构层面的评语好看很多。从那以后我每次拿到带小程序的毕设源码都会强制先看三样东西application.yml里的数据源和上传路径、request.js里的baseUrl、以及数据库脚本里的表名是否和实体对得上。三样看完再启动翻车的概率能少一半。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
