微信小程序扫码点餐系统实战：从订单状态机到微信支付全解析

1. 项目背景与需求拆解1.1 为什么是烧烤店小程序点餐微信小程序扫码点餐是这几年做毕业设计和实战项目里出现频率最高的题材之一。烧烤店又是个很有意思的落点——它不像快餐店那样追求极致的出餐速度也不像正餐店那样依赖服务员全程引导烧烤店的特点是SKU多、规格杂、高峰期集中在晚上而且大部分顾客习惯先点一轮吃一半再加菜。这种业务模式天然适合小程序引导用户自己下单把服务员从拿着菜单站在桌边等的工作里解放出来。我最早接触这个项目是帮一家做烧烤夜宵的餐饮店做数字化改造。对方当时最头疼两件事晚上8点到11点客人集中到店服务员记单靠手写经常出现辣度写错、漏菜、加菜找不到人的情况后厨出菜全靠嗓子喊前台叫号、后厨做菜完全是两张皮。听完这些我才意识到点餐系统难的不是页面而是把一桌多人分批次点菜、后厨按制作顺序出菜、加菜要插单这套真实流程抽象成系统逻辑。所以这个项目最终定型的定位是给中小型烧烤门店做一套顾客扫码自助点餐 商家后台订单管理的轻量级小程序系统重点解决下单链路乱、订单状态不可追踪、库存靠人工记这三类问题。1.2 三类角色与核心需求系统不是只给顾客用的一块完整的点餐业务至少涉及三个视角角色使用场景核心诉求顾客扫码进入小程序浏览菜品、加购物车、下单支付、加菜流程顺畅下单快口味备注不丢商家收银/后厨在后台查看新订单、确认制作、标记出餐、调整菜品上下架实时看到订单操作简单不容易漏单管理员管理用户、菜品分类、统计经营数据权限清晰数据准确实际调研下来发现每个角色对系统的容忍度完全不同。顾客可以接受页面稍微朴素但不能接受下单之后不知道状态后厨最关心的不是设计美感而是新单提醒是否及时老板最在意的是库存和营业额数据能不能对得上。这三类诉求会直接影响后面的数据库设计和接口设计所以动手之前必须把角色理清楚。1.3 功能清单最终版在写代码之前我把功能列表过了一遍最终保留了下面这些模块顾客端扫码进店、菜单浏览、分类筛选、规格选择、购物车管理、提交订单、微信支付、订单状态跟踪、历史订单、桌台识别商家端待接单列表、订单详情、确认制作、出餐标记、菜品上下架、库存调整、桌台状态管理端用户管理、菜品分类管理、基础数据配置、营业额报表做功能裁剪的依据是最小可用闭环。比如会员积分、优惠券这些对核心流程没有决定性的影响第一版就没做但库存管理和状态流转属于点餐系统的地基必须有。否则系统就算跑起来也撑不过真实门店的一天运营。2. 技术选型与整体架构设计2.1 前端为什么直接用原生小程序很多新人纠结要不要上 uni-app 或 Taro。我的建议是这个项目别折腾跨端框架直接用微信原生小程序。理由不复杂。第一这个系统只有微信一个终端不存在一套代码多端复用的需求跨端框架的优势发挥不出来第二原生小程序在生命周期管理、组件通信、wx.login、wx.requestPayment 这些底层 API 的对接上最直接出了问题也好排查第三原生语法本身不复杂页面结构、事件绑定、数据绑定学一遍就能上手没必要为框架本身增加学习成本。可能有人会说 uni-app 能顺便发布到支付宝小程序。但真实业务场景里烧烤店根本用不到支付宝端多一分框架抽象就多一分不确定性尤其支付流程这种关键链路原生最稳。2.2 后端接口服务与目录结构后端选型我用的 Node.js 加 Express。原因也简单前后端都是 JavaScript心智负担小Express 生态成熟中间件拿来即用对于这种查询密集但逻辑不算深的应用完全顶得住。当然如果学校要求必须用 Java Spring Boot也完全可行无非是把接口层换成 Controller、服务层换成 Service业务逻辑本身是一样的。选型上没有绝对的对错只有适不适合你手头的时间和技术积累。后端目录大致这样组织/server ├── routes // 路由层只负责参数校验和分发 │ ├── menu.js │ ├── order.js │ ├── payment.js │ └── admin.js ├── models // 数据模型 ├── services // 业务逻辑层 │ ├── orderService.js │ └── inventoryService.js ├── middleware // 鉴权、日志等中间件 └── app.js这里要强调一点路由层尽量只做参数接收和响应封装业务判断放 service 层。在点餐场景里订单的金额计算、库存扣减、状态校验都属于业务逻辑如果全堆在路由里后面商家后台要复用相同逻辑时代码会非常痛苦维护成本直接翻倍。2.3 数据库设计核心表结构表结构我设计了三类账号与基础资料、菜单与库存、订单与明细。表名主要字段职责说明useropenid, nickname, avatar, phone顾客信息以 openid 作为唯一标识menu_categoryid, name, sort, status菜品分类比如烧烤、凉菜、酒水menu_itemid, category_id, name, price, stock, status, image菜品主数据price 以分为单位tableid, table_no, status桌台状态支持开台、结账orderid, table_no, status, total_amount, remark, pay_time, create_time订单主表order_itemid, order_id, menu_item_id, name, spec, price, quantity订单明细冗余菜品名和单价订单明细表冗余菜品名和单价是我特别想强调的实践细节。假设你卖烤羊肉串10块钱一串后来老板想改名成炭烤羊肉串、价格调到12块。如果不做冗余用户历史订单里显示的就会是改名之后的信息看起来很奇怪也容易惹纠纷。在订单快照里存一份名称和单价虽然占用一点存储但对账单可追溯性帮助很大。金额一律用分存储。这个也是我用浮点数踩过坑之后改的。数据库里 float 类型在累加扣减时会出现精度误差你永远不希望订单金额出现 99.999999 这种数字。整数分单位前端展示时转成元后端计算时全部按分处理清清楚楚。2.4 接口清单与鉴权设计后端接口围绕三个端来设计接口方法路径功能GET/api/menu/list获取启用状态的菜单分类和菜品POST/api/order/create顾客下单GET/api/order/detail查询订单详情PUT/api/order/cancel取消订单未支付状态下POST/api/payment/prepay微信支付统一下单POST/api/payment/callback微信支付回调GET/api/admin/orders商家端订单列表POST/api/admin/order/confirm商家确认订单POST/api/admin/order/serve商家标记出餐POST/api/admin/menu/upsert新增/修改菜品GET/api/admin/stat/today当日营业统计鉴权方面小程序端用 openid 识别用户。顾客首次进入前端调 wx.login 拿到临时 code后端用 code 换 openid存进 user 表并返回自定义 token。后续请求带 token中间件解析后把 openid 放进请求对象。商家端和管理端用独立的账号体系和顾客不混在一起这样权限边界更清晰也避免出现顾客误入管理后台的风险。3. 核心功能模块的落地实现3.1 购物车模块状态必须全局化购物车是实现体验的第一个关键点。小程序页面切换时页面实例不会被销毁但如果你把购物车数组放某个页面的 data 里切走再切回来就得重新初始化用户选好的菜就全没了。所以我把购物车状态挂到 app.globalData 上组件和页面都能直接访问。核心逻辑是合并同类项。同一道菜同一种规格再次加入时累加数量不同规格分开存。举个例子用户先加了一份微辣烤茄子又加了一份加辣烤茄子那购物车里是两条记录各自数量独立。这个逻辑如果做错会出现一个很尴尬的画面顾客选了两种辣度结算时下单失败。购物车数据结构大致长这样// app.js 中维护 cart: [ { menuItemId: 1001, name: 烤茄子, spec: 微辣, price: 1200, // 单位分 quantity: 1, image: https://xxx/xxx.jpg } ]加购操作放到全局方法里// app.js addToCart(item) { const cart this.globalData.cart; const found cart.find(i i.menuItemId item.menuItemId i.spec item.spec); if (found) { found.quantity item.quantity; } else { cart.push({ ...item }); } wx.setStorageSync(cart, cart); }每个商品条目带上 menuItemId是给后端算钱用的带上 name、price 这些字段是给购物车渲染用的真正结算时后端以 menuItemId 和 quantity 为准重新从数据库里取价。这么做的目的是防止用户通过篡改请求参数把价格改成1分钱这个安全习惯要尽早养成。我还做了本地存储持久化。wx.setStorageSync 把购物车写进缓存即使用户切到后台、小程序被系统回收重新打开后购物车还在。这个体验细节很加分是我在真机上反复验证过的建议后续的同类项目都保留这个设计。3.2 订单状态机整个系统的地基订单状态是整个项目里最值得花时间设计的部分。我把状态拆成六个每一个都有明确含义状态值含义触发动作pending待支付用户提交订单后进入库存被预占paid已支付微信支付回调成功confirmed商家已确认制作中商家后台点击确认served已出餐上桌商家标记出餐completed已完成用户结账离桌商家标记完成cancelled已取消超时未支付/用户主动取消这里有个容易被忽略的点为什么要有 pending 状态。如果没有 pending用户提交订单直接扣库存要是15分钟都没付款库存就一直被占着晚上高峰期烤串卖完了但账上还挂着没付款的单子损失很大。所以我在下单接口里设置了15分钟支付时限超过时限后由定时任务把 pending 订单改成 cancelled同时回补库存。状态流转的校验也严格。cancelled 的订单永远不能再改成 paid否则后厨会看到一笔已经取消的订单又出现在制作列表里这种错误在实操里是灾难。所有状态校验统一在 service 层实现前端只是状态展示的入口不承载任何判断逻辑。用户加菜场景下的状态流转我单独处理了同一桌已有已支付、制作中的主订单时加菜会生成一条追加明细后厨端能看到3号桌加菜的独立提醒而不是把原来的订单整体推翻重做。这个设计是我在跟烧烤店老板聊需求时发现的——烧烤场景几乎桌上坐得越久点得越多加菜是常态不是意外系统必须为此设计独立路径。3.3 订单创建与金额计算的正确姿势用户点击结算时前端把购物车内容整理成 items 数组传给后端后端不能直接信前端算出来的总价必须重新从数据库取值计算。对应的服务端核心逻辑async function createOrder(orderData) { const { tableNo, remark, items } orderData; let total 0; for (const item of items) { const dbItem await findMenuItem(item.menuItemId); if (!dbItem || dbItem.status ! on) { throw new BusinessError(菜品已下架: item.menuItemId); } const price dbItem.salePrice; // 数据库中的售价单位分 total price * item.quantity; // 同时做库存预占见 3.4 } // 桌台的折扣、满减在这里统一计算 return await saveOrder(...) }接口字段设计上我把辣度、去掉香菜、不要葱这类口味偏好统一塞进 remark 里。不要把五花八门的口味偏好做成几十个字段那是给自己找麻烦。备注字段天然适合烧烤这种高定制化的场景既灵活又不会把表结构撑爆。3.4 控制并发库存条件更新加事务烧烤店的高峰时段几个客人同时下同一道菜是很常见的事。如果库存只有10串两个请求同时扣用常规的先查库存够就扣一定会出问题可能两个请求都查到剩余10串然后都扣库存就变成负数了这在烧烤店的实际运营里是绝对不能接受的。解决办法是条件更新把扣库存和检查库存合到一条 SQL 里UPDATE menu_item SET stock stock - #{quantity} WHERE id #{menuItemId} AND stock #{quantity}只要受影响行数是1说明扣减成功是0说明库存不足。加上订单创建放在同一个数据库事务里要么订单和扣减同时成功要么都回滚避免出现单下了但库存没扣或者库存扣了但单没下成的中间状态。3.5 微信支付绕不开的关键链路支付流程我拆成五步用户提交订单成功得到 pending 状态订单前端调 /api/payment/prepay后端用订单金额调用微信统一下单接口微信返回 prepay_id后端把它封装成支付参数返回给小程序小程序端调 wx.requestPayment 拉起收银台用户支付成功后微信服务器回调地址通知后端后端更新订单状态为 paid两个最容易踩的坑在这里说清楚。第一是金额单位微信支付接口要求的金额单位是分如果你按元传过去实际支付金额会差100倍这是新手最容易踩的事故级错误。第二是回调的幂等性微信回调有重试机制同一个支付成功事件可能推送多次后端必须判断当前订单状态已经处理过的回调直接忽略不能重复更新否则订单金额会被覆盖或者状态被错误改写。开发阶段没有微信商户号时可以把支付流程做成模拟支付也就是后端点一个按钮直接模拟支付成功。这样不影响联调等真正上线前再换正式商户号整体成本是最低的。4. 实操中的关键细节与避坑经验4.1 小程序审核与账号资质提前确认如果这个项目打算真正上线第一步要确认的是主体资质不是写代码。扫码点餐类小程序在微信生态里有明确的类目要求通常需要餐饮行业的相关资质。个人主体大部分情况下办不下来得用个体工商户或企业主体注册。这个前置条件没搞定代码写得再好也提交不了审核我见过太多人写完代码才发现主体资质不对只好去借朋友公司的资质流程全乱。很多同学第一次提交审核被驳回往往是下面几个原因类目选择与页面实际展示内容不一致登录页强制索要手机号但页面上没有用于订单通知这类说明文字页面里出现测试数据、硬编码的 IP 地址缺少用户隐私保护指引我的建议是在开发阶段就把隐私政策页面和用户协议做好登录页放上登录即代表同意用户协议和隐私政策的勾选组件避免上线前返工。4.2 开发环境与合法域名的那些事微信小程序请求后端接口正式环境强制要求 HTTPS 域名而且域名必须在小程序管理后台配置为 request 合法域名。开发阶段可以在开发者工具里勾选不校验合法域名来绕过但真机预览时如果没开调试模式照样被拦。我第一次部署时遇到过很尴尬的情况前端页面和数据渲染都好就是所有接口请求失败。检查半天发现是后端用了 HTTP没配 SSL 证书。后来配了 HTTPS 证书又在管理后台加了域名白名单才跑通。提醒一句本地开发时用 http://127.0.0.1:3000 做接口调试没问题在开发者工具中勾选不校验域名即可但一旦要用手机真机预览就必须确保服务端地址能被公网访问且是 HTTPS。4.3 商家后台和新单提醒怎么设计商家端我建议做成网页后台不要也做成小程序。原因有两个一是小程序后台审核流程慢商家修改菜单、调整库存这种高频操作走小程序体验并不好二是商家核心场景是后厨看单PC 或大屏浏览器比手机更常用。新订单提醒这块最稳的做法是前端每几秒轮询一次订单列表接口。对一个小型烧烤店的订单量来说3到5秒轮询完全够用实现简单可靠。WebSocket 确实是更优雅的方案但对这个项目量级属于过度设计还会引入连接管理和断线重连的复杂度出了问题排查也更费劲。轮询时注意接口要按状态过滤只返回商家关心的待确认和制作中订单已完成的订单单独分页查询。否则数据量一上来轮询接口会越跑越慢影响整个后台的使用体验。4.4 性能优化菜单列表缓存点餐系统访问最密集的接口是菜单列表。顾客一扫码进来就调高峰期一分钟几百次。每次请求都去查数据库虽然 MySQL 能扛得住但没必要。我加了一层简单的内存缓存菜单列表加载后缓存30分钟商家在后台更新菜品时主动清掉缓存。这样数据库查询量能降一个量级。如果以后数据量大了可以换成 Redis 统一缓存。对现在这个项目内存缓存已经够用还能少维护一个中间件部署和运维都更省心。5. 测试与上线要点5.1 全链路功能测试清单我在项目交付前整理了一份测试清单照着跑一遍基本能把主要 bug 都滤出来扫码进入小程序确认桌号参数传递正确菜单加载、分类切换、规格选择是否正常加菜、减菜、清空购物车金额联动是否正确下单成功进入待支付状态倒计时显示是否正确真机环境测试微信支付模拟器不支持真实的 wx.requestPayment商家后台新订单提醒、确认制作、出餐标记同一桌加菜后商家端能看到独立的加菜提醒某菜品库存设为0顾客端是否还能正常下单历史订单列表与订单详情金额、明细展示断网/弱网下提交订单系统是否给出可理解的错误提示这一套跑完再重点测一下金额算法。多道菜合计、修改数量、删除菜品后合计口径要一致任何一个环节不对都要回头查。5.2 部署与 HTTPS 配置后端部署我用了一台云服务器用 Nginx 做反向代理把 HTTPS 流量转到 Node 服务端口。HTTPS 证书用的免费云证书配上 Nginx 的证书路径几分钟就能搞定成本几乎为零。小程序后台的域名配置一定要提前做request 合法域名、uploadFile 合法域名如果你用到了图片上传也要把对应的 downloadFile 域名配进去。提示部署在国内云服务商的服务器域名需要先完成备案才能正常对外提供服务否则 HTTP/HTTPS 请求会被拦截。备案流程建议提前两周启动别等代码写完才想起那会白白等很久。5.3 日志和监控上线后出过一回问题商家反馈有漏单但订单表里就是查不到记录。后来检查日志发现是用户支付成功回调到达时网络短暂异常导致后端处理抛了错订单停在 pending商家端看不到。这种问题最好的解决办法是补日志再加一个定时补偿任务。我加了一个简单的补偿任务每分钟扫描一次 pending 状态超过5分钟的订单主动去微信查单接口确认支付状态如果已支付就补更新为 paid。这也是为什么日志比代码更重要的原因——没有日志出问题的现场就是黑的你想排查都无从下手。6. 常见问题与排查技巧实录6.1 扫码打开小程序提示页面不存在真机扫码预览时偶尔会弹页面不存在。大部分情况是二维码里的 scene 参数解析失败。微信的 scene 参数是限制长度的而且需要 decodeURIComponent 解码。我踩过一次坑把桌号1写成 table1结果参数太长被截断解析直接失败扫码页面就一直报错。解决方案是 scene 里只放短的标识比如 desk001不要放中文和特殊符号。前端拿到场景值后先 decode 再解析成桌号解析失败时要兜底跳转到默认桌台不能白屏。6.2 接口报 request:fail这个错误的原因十有八九是域名问题。先看后端地址是不是 HTTPS再看微信开发者工具是否勾选了不校验合法域名最后看小程序后台有没有配 request 合法域名。三样都没问题还报错就在 onShow 里打个日志看完整报错信息不要盲猜。6.3 微信支付回调一直不成功排查顺序很重要用 Postman 直接调回调接口确认接口返回的格式是微信要求的 success 字符串而不是 JSON确认回调地址公网可达且返回 HTTP 200检查证书和密钥是否和商户号匹配核对订单号是否和统一下单时一致大部分回调失败是第1条和第2条。很多人回调处理完习惯返回 JSON但微信那边解析不到 success 字符串就会一直重试直到你觉得回调坏了其实后端早就处理完业务了。6.4 订单并发下的状态错乱商家后台同时打开两个页面都点了确认订单会导致订单状态重复更新。我在订单表加了一个 version 字段做乐观锁更新时带上版本号条件更新失败就提示订单状态已变化请刷新。这个办法简单有效基本杜绝了状态互相覆盖也不用引入复杂的分布式锁。6.5 小程序包体积超了小程序的包体积限制很严格图片是最大元凶。菜品图片一多几张高清图就能把几MB的包撑爆。正确的做法是图片传到对象存储或云存储代码里只留 URL。另外开启开发者工具的代码压缩也能省不少体积。7. 项目复盘与后续扩展方向7.1 这套系统锻炼了什么回头看这个项目给我的价值不在会用小程序本身而在于逼我把完整的业务链路走了一遍用户身份、菜单数据、订单状态机、支付回调、库存事务、部署上线、线上排查。任何一个环节没打通整个系统就是半成品。和同行聊这个项目时最有分量的话是能讲明白状态机为什么 pending 后会超时取消回调幂等怎么做的加菜怎么处理这些问题比我会写小程序给人的印象深得多面试官通常也更愿意听这类业务细节。7.2 还能扩展什么如果你做完基础版还有余力下面这些方向都可以自然扩展会员系统充值、积分、消费记录让复购有抓手优惠券满减券、折扣券在订单金额计算环节加入多门店加一张门店表菜单和库存按门店隔离数据统计按菜品销量、时段客流、桌均消费做图表展示后厨打印接入云打印机下单后自动出小票7.3 一点个人体会做了这么多套同类项目我最大的体会是点餐系统的复杂度不在页面数量而在订单状态和异常流程。你把状态机设计稳了支付、加菜、超时取消、库存回补都理顺了系统就立住了。相反页面再炫状态一乱商家用两天就会骂人。还有一个我以前容易忽略的点真实烧烤店的网络环境不一定好高峰期 WiFi 拥堵下单请求可能有延迟。所以前端发送下单请求时要做防重复提交按钮禁用加 loading 状态避免用户多点几下生成几笔重复订单。这个细节在演示环境里看不出来到了店里一定会暴露。真机测试永远是标准。之前帮店家调试时WEB管理后台页面总是点不动查了很久才发现是旧浏览器不兼容 ES6 语法后来我统一编译到 ES5 才解决。这类跟模拟器无关的真实环境问题只有到现场才能遇到。最后分享一个实用的小技巧把商家后台的订单列表接口设置成只返回最近7天数据再加个状态筛选。数据量小的时候看不出区别等门店开了半年订单量上来之后这个设计能省掉你大量分页和查询优化的麻烦。很多项目就是因为没提前考虑数据增长半年后接口慢到没法用被迫重构。希望这篇拆解能帮到正在做同类项目的朋友有问题欢迎在评论区一起交流。