做了多年的微信小程序开发带过的毕设项目和实战系统不在少数但点餐系统绝对是我见过看着简单、做起来最琐碎的一类。你随便搜一下微信点餐管理系统出来的源码一堆但真正能跑通完整交易链路、能在审核期不被打回来的其实不多。这篇我把一个相对完整的微信点餐管理系统从需求拆解、数据库设计、小程序端核心代码、商家后台、部署上线到避坑清单全部过一遍适合正在做毕设、或者想接餐饮商家外包单的开发者在已有基础上快速落地。项目配套的完整源码和论文说明文件我都会按模块说明结构方便你对照自己的工程做调整。先说清楚这个系统做了什么用户打开微信小程序浏览菜品分类加购物车提交订单选择到店自取或堂食扫码点餐然后支付商家端有一个独立的管理后台网页端可以上架下架菜品、设置每日特价、查看订单、操作接单/出餐/完成以及查看基础的营业统计。用户端和商家端的数据通过云端接口实时同步后厨或者前台能看到新订单提醒。下面直接进入正题我把整个系统的搭建过程按模块拆开讲。1. 需求边界设计先搞清楚点餐系统到底要管哪些事点餐系统听起来功能简单但一旦进入真实业务场景需求边界很容易失控。我在开始写代码前会先把整个系统的用户角色和业务流程画清楚。这套系统的核心角色就两个C端用户和B端商家管理员但在开发时还要考虑一个隐藏的后台运维角色用来处理超时订单、退款异常这类边缘情况。1.1 用户角色与核心业务规则C端用户侧最核心的流程是扫码/搜索进入小程序 - 浏览菜品 - 加入购物车 - 提交订单 - 在线支付 - 等待商家出餐 - 取餐/用餐。这个链路里有一个特别容易忽略的点订单在已支付状态之后不是直接跳到已完成而是中间要经过商家接单、制作、出餐等环节。很多简化版源码在这里直接砍掉了中间态导致商家根本没法操作订单流转这是判断一个点餐系统是否可用的关键分水岭。B端商家側业务规则更细菜品管理需要区分在售和停售状态停售菜品在用户端应该直接隐藏或置灰而不是等用户下单后再说这个没了。订单处理新订单要有提醒接单后进入制作制作完成标记出餐用户取餐后订单完结。营业统计至少要有当日营业额、订单数、热销菜品排行这些数据直接从订单表和订单明细表聚合出来。还有一个被我反复验证过的重要规则用户提交订单时必须校验菜品是否还在售、价格是否发生变化不能直接信任前端传过来的价格。原因往下看这是我在实测中踩过的坑。1.2 数据库设计表结构是这样拆出来的数据模型是整个系统最需要仔细设计的部分后续所有接口的复杂度都由它决定。我用MySQL作为主存储核心表一共9张用户表useropenid唯一索引、昵称、头像、手机号、注册时间菜品分类表category分类名称、排序权重、是否置顶菜品表dish所属分类、名称、描述、图片URL、价格存分为单位、是否停售、月销量购物车表cart用户ID、菜品ID、数量、加入时间小程序端也可用本地存储但服务端保存更稳订单表orders订单号、用户ID、总金额、订单状态、支付状态、支付时间、订单类型堂食/自取、备注订单明细表order_detail订单ID、菜品ID、菜品名称快照、单价快照、数量管理员表admin账号、密码加密存储、角色营业时间表business_hours可灵活配置各时段的营业状态系统配置表config存储起送价、配送费、商家公告等菜品价格我是强烈建议用分存储的不要在数据库里用FLOAT或DECIMAL存元。整型运算没有精度误差前端展示时再做一次除以100的转换。金额这种数据一旦出现0.10.2这类精度问题对账的时候会让你怀疑人生。订单状态我用整数存储定义如下约定0待支付、1已支付待接单、2已接单制作中、3已出餐待取餐、4已完成、5已取消、6退款中、7已退款。这个状态机在商家后台和用户端都要保持一致所以我把它抽成了常量文件前后端各维护一份避免状态码对不上。2. 小程序端登录与用户体系最容易被忽视的隐蔽工程登录模块是点餐系统第一个要做的功能也是问题最多的功能。很多初学者直接把wx.login拿到的code往后台一传就以为登录完成了其实这个过程的完整链路是小程序端调用wx.login获取临时code把code发给自己的后端后端拿着code加上小程序的AppID和AppSecret去微信的接口换openid和session_key然后用openid去查用户表。2.1 静默登录与token续期的设计用户打开小程序时我不希望弹出一个强制授权框那样跳出率太高。所以用户端走的是静默登录逻辑前端先调wx.login拿code后端拿到code换openid后如果用户表里没有记录就自动创建一条并签发一个自定义的登录态token返回给前端。前端把token存到storage里后续所有请求都在header里携带这个token。这个token的有效期我设置的是7天但有个细节小程序可能7天内多次打开所以我做了一个token自动续期策略。后端返回token时同时返回一个expires_in字段小程序在每次请求的响应拦截器里判断如果token快过期了剩余时间少于1天就静默调一次刷新接口把旧token换新的。这样用户完全无感知也不会出现用着用着突然被踢回登录页的情况。2.2 获取手机号与用户信息授权的边界新版微信已经基本废弃了wx.getUserInfo直接弹窗拿昵称头像的方式改成用户主动点击头像昵称填写能力或者用手机号快速验证组件。点餐系统里手机号很重要因为到店自取需要联系用户。但这里有个体验和审核的平衡问题如果一进来就强制要手机号转化率会掉很多。我的做法是手机号获取放在用户第一次提交订单时作为下单流程的一步而不是小程序启动时。这样既不会过度打扰浏览用户又能在真正需要联系用户的时候拿到必要信息。用微信官方提供的button open-typegetPhoneNumber组件后端拿code换手机号整个过程不经过前端明文传递安全性有保障。2.3 用户端接口的异常处理不要只处理成功路径接口设计上除了常规的成功返回我专门设计了一套错误码体系。比如菜品已下架返回2001、库存不足返回2002、订单已关闭返回2003、登录态过期返回401。前端请求封装统一处理这些错误码遇到401就静默重新登录再重放请求遇到2001就刷新购物车并提示用户菜品已售罄已自动移除。这套体系看着不起眼但在真实环境中特别有用。一个小程序上线后你根本无法预判用户会在什么网络环境、什么操作顺序下触发问题。比如用户把小程序切到后台半小时再回来直接点提交订单token可能换了菜品可能下架了价格可能调了没有统一错误处理的话用户只会看到莫名其妙的请求失败。3. 点餐核心链路菜品展示、购物车与订单落库这是整个系统最核心的业务代码区。我会把每个环节的关键实现逻辑讲清楚包括为什么这样设计。3.1 菜品数据与分类的接口设计菜品列表接口我设计成了两个一个获取全部分类含分类下的菜品一个获取单个菜品详情。分类接口返回的数据结构是嵌套的这样小程序端渲染时不需要做二次聚合处理一次性拿到所有数据直接渲染。这里特别注意一个性能问题不能每次用户打开小程序都从数据库实时查全量菜品。菜品的更新频率其实很低半小时、一小时变一次就算频繁了。我在后端给这个接口加了Redis缓存缓存key按菜品分类_店铺ID区分商家后台修改菜品后主动删除对应缓存下次请求自动回源刷新。实测在低配云服务器上接口响应从平均300ms降到了50ms以内。菜品的图片存储我用的云存储返回给前端的是CDN加速过的URL。图片有一个规范必须等比压缩因为小程序端列表图和详情图尺寸要求不一样不能一张原图走天下。我在商家后台上传菜品图片时后端会自动生成多个尺寸的缩略图列表用200x200详情用640x640这样能显著减少流量消耗和首屏加载时间。3.2 购物车的本地状态管理避免服务端频繁读写购物车这块初学者最容易犯的错是把每个加购动作都实时同步到服务端。点餐场景下用户操作购物车是非常高频的而且网络并不总是稳定每次操作都请求后端会让体验变得非常糟糕。我的方案是小程序端本地维护购物车使用全局状态管理小程序里可以用globalData或者引入轻量的状态库数据结构设计成{ items: [ { dishId: 12, name: 招牌牛肉面, price: 2800, qty: 2, specs: 微辣 }, { dishId: 18, name: 冰酸梅汤, price: 600, qty: 1, specs: } ], totalQty: 3, totalAmount: 6200 }这个本地购物车会在用户每次加购时更新同时同步到storage做持久化。真正和服务端交互的节点在提交订单那一刻一次性把购物车数据发送给后端。这样设计还有一个好处就算用户中途退出小程序下次进来购物车还在。购物车本地化有一个必须处理的细节用户打开小程序时要从服务端拉取一遍购物车里所有菜品的实时价格和售罄状态和本地缓存做比对。菜品价格变了以服务端为准并提示用户菜品停售了直接移除并提示。这个校验我放在进入购物车页面的时机执行保证下单前用户看到的一定是准确信息。下单接口再做一次兜底校验双重保险。3.3 下单接口的服务端校验与幂等处理服务端的下单接口是整个系统最需要谨慎的接口因为它直接涉及钱。前端提交的请求里只传这些字段订单类型、备注、购物车明细列表菜品ID和数量。后端要做的事情如下第一步根据用户token解析出用户ID然后查询用户信息是否存在不存在直接拒绝。 第二步将购物车明细里的菜品ID批量查库拿出每个菜品的当前价格、在售状态和前端传的数量重新计算总金额。这里绝对不信任前端传过来的totalAmount而是以后端计算的为准。前端显示的总金额只是参考展示。 第三步用数据库事务把订单主表记录和订单明细表记录写入同时扣减菜品销量字段清空用户服务端的购物车记录。这期间如果任何一步失败整个事务回滚。 第四步生成业务订单号并返回给前端前端拿到订单号后调用微信支付接口。下单接口还有一个隐藏需求幂等处理。用户可能在网络波动时多次点击提交按钮如果每次都生成新订单就会出问题。我的方案是给下单请求加一个前端生成的请求唯一标识后端以这个标识做去重判断。同一标识的重复请求直接返回第一次的订单结果不会重复建立订单。实测这个设计在真实场景下几乎必然会被触发非常重要。3.4 支付流程微信支付接入的几个关键细节微信支付接入是点餐系统最劝退初学者的环节。我快速过一遍完整流程和需要注意的配置点第一步申请微信支付商户号。注意主体要和小程序的主体一致不然很多支付功能没法开。第二步在小程序后台开通微信支付并配置支付目录、回调域名。第三步后端引入微信支付v3的SDK我用的是官方sdk不要自己造轮子去拼签名配置商户号、API证书、APIv3密钥。第四步后端统一下单接口返回给前端5个核心参数时间戳、随机字符串、订单详情扩展字符串、签名方式、签名。前端用wx.requestPayment发起支付。支付回调是这里最容易出问题的环节。微信服务器会异步通知你的回调地址通知里带签名和订单状态。你要做的是验签 - 判断订单状态是SUCCESS - 更新本地订单状态为已支付 - 返回处理成功给微信服务器。这里有一个坑微信会重试通知如果业务处理成功但你没有正确返回微信会一直重复通知造成订单状态被重复更新的问题。所以支付成功的回调处理必须做幂等先查订单当前状态如果已经是已支付就不要再重复更新了直接返回成功。关于支付证书很多源码包里的证书是明文的安全性堪忧。你在真实部署时一定不要把商户号和证书机密提交到代码仓库里要用环境变量或者单独的配置文件管理并且配置文件要加进.gitignore。4. 看板式的实时订单提醒别用轮询用WebSocket长连接这是用户堂食场景的刚需也是我在毕设评估里最看重的功能点之一。用户下单后商家端需要几乎实时地看到新订单并处理用户端在等待出餐时也需要看到订单状态的实时变化不能老盯着屏幕手动刷新。4.1 为什么最终选了WebSocket而不是定时轮询不少简化版源码用的是前端定时器每5秒拉一次订单状态接口。在小并发场景下这样确实能用但有两个硬伤第一订单状态更新不是瞬时的最坏情况下用户要等5秒才能看到新状态第二用户量稍微上来一点服务端的查询压力会被无意义的轮询请求放大很多倍。这个系统里我用了WebSocket长连接小程序端通过WebSocket连接服务器服务端在订单状态变化时主动推送消息给对应连接。用户端和商家端都依赖于这个通道。我用的方案是服务端在订单状态变更的代码逻辑处主动向对应角色的WebSocket连接推送一条消息消息内容是订单ID和新的状态码。前端收到后如果当前正停留在订单详情页就自动刷新页面数据如果在首页就弹出一个轻量提示您的订单已出餐。接入过程有几个实际经验分享。小程序端原生代码直接这样写wx.connectSocket({ url: wss://api.yourshop.com/ws, header: { Authorization: token } }) wx.onSocketMessage(function (res) { const data JSON.parse(res.data) // data.type ORDER_STATUS_CHANGED // data.orderId, data.status handleOrderStatus(data) }) wx.onSocketClose(function () { // 心跳断了做重连最多重试5次 retryConnect() })后端我用的是Netty实现WebSocket服务如果你用Java系后端的话每台机器维护一份userId到Channel的映射用ConcurrentHashMap存储。如果是单体应用这样完全够用如果你的装机量比较大需要用Redis的Pub/Sub做跨节点广播不然A机器收到订单变更B机器上的用户连接收不到消息。小程序端的WebSocket有些老坑比如切后台后连接会被系统断掉需要在前端实现重连机制和心跳保活。我一般用每30秒发一个ping包服务器端60秒内没收到ping就主动断开连接前端检测到断线后自动重连。4.2 商家端实时订单墙的实现商家端我用的是一个独立的Web管理后台界面其中最重要的页面是订单看板它的核心是一个实时更新的订单列表。每个订单卡片展示订单号、用户取餐号、菜品清单、备注、金额、倒计时从接单开始计时超过15分钟变红提醒、操作按钮。新订单到达时WebSocket推送消息触发列表头部插入一张新卡片并播放提示音。商家点击接单状态变成制作中点击出餐状态变成已出餐待取餐用户取餐后用户端点击确认取餐订单状态变成已完成。每一步操作都同步推送状态给用户端。取餐号的设计可以在这里说一下它是店内自取的标识我用的是一个3位数字编号每天从1开始递增。这样商家和用户喊号方便不会暴露用户真实订单号。生成逻辑是在下单接口里取当天最大取餐号1用Redis的INCR命令实现原子递增一天一重置。5. 数据统计模块让商家看到营业情况的真实全貌很多点餐系统做完了点餐、支付、订单管理就结束了但商家真正长期使用的是数据统计功能。一个餐饮老板每天最关心的几个数据今天卖了多少单、营业额多少、哪个菜品卖得最多、哪个时段是高峰期。这部分我用SQL聚合实现不引入额外的大数据组件性价比很高。5.1 营业日报的SQL实现思路当日总营业额和总订单数SELECT COUNT(*) AS order_count, SUM(total_amount) AS total_revenue FROM orders WHERE pay_status 1 AND pay_time CURDATE() AND pay_time CURDATE() INTERVAL 1 DAY;热销菜品排行按销量倒序SELECT d.id, d.name, SUM(od.qty) AS sale_quantity FROM order_detail od LEFT JOIN dish d ON od.dish_id d.id LEFT JOIN orders o ON od.order_id o.id WHERE o.pay_time CURDATE() AND o.pay_time CURDATE() INTERVAL 1 DAY AND o.pay_status 1 GROUP BY d.id, d.name ORDER BY sale_quantity DESC LIMIT 10;小时维度订单分布用于判断忙闲时段SELECT HOUR(pay_time) AS hour, COUNT(*) AS order_count FROM orders WHERE pay_time CURDATE() AND pay_time CURDATE() INTERVAL 1 DAY AND pay_status 1 GROUP BY HOUR(pay_time) ORDER BY hour;这三个SQL基本覆盖了我的统计需求。如果你需要更细的维度可以额外维护一张日汇总表每天凌晨用定时任务把前一天的数据聚合写入报表查询时直接读汇总表而不是实时跑原始订单表。数据量上来之后这个优化会非常重要。5.2 经营看板的可视化呈现后端提供统计接口后商家后台前端用轻量图表库渲染趋势折线图、菜品排行条形图、时段分布柱状图。我做的是一个可切换时间的维度今日、近7日、近30日对应的SQL只是把时间范围参数改一下聚合逻辑完全复用。数据刷新策略是打开页面时拉取一次之后每5分钟自动拉取一次。实时性要求不高的场景完全够用也没必要为这个专门接WebSocket。6. 部署上线与微信生态配置审核期反复踩坑的避坑全集功能全部写完、本地自测通过并不代表可以上线。微信小程序的审核、域名配置、HTTPS证书、类目选择每一步都有坑。我把自己踩过的和帮别人解决过的高频问题集中列一下。6.1 前后端联调与真机预览的必备设置开发阶段用微信开发者工具中的不校验合法域名选项很爽但上线前一定要做三件事第一小程序后台配置request合法域名、socket合法域名、uploadFile合法域名。这里要注意域名必须是HTTPS且不能带端口默认443而且ICP备案一定要完成。我见过很多项目卡在域名备案上一等就是好几天。第二本地开发环境联调时我发现一个效率提升的技巧用微信开发者工具自带的自定义条件编译功能根据编译模式动态切换API的baseURL。开发环境指向本地局域网IP加后端端口生产环境指向正式域名。在代码里做一个环境判断不要每次发版前手动改一堆请求地址。第三尽可能用真机预览。开发者工具的模拟器里很多能力跟真机有差异特别是网络请求的TLS版本兼容性、微信支付的拉起表现、WebSocket在弱网环境的断线重连。这些只有真机测过才敢放心提审。6.2 审核被拒的常见原因与解决办法餐饮点餐小程序在提审时最常遇到的是类目审核问题。如果小程序涉及餐饮服务或点餐平台可能需要对应的资质文件。一个规避思路如果你的系统是给单一商家使用的可以走餐饮商家自营类目需要的资质比平台型要少如果你做的是多商家入驻的聚合点餐平台类目要求会严格很多通常需要食品经营许可证等资质。这一点在项目规划和论文说明里都要写清楚别等到提审被拒了再调整方向。另一个高频被拒原因是用户隐私保护指引没有配置完整。小程序的隐私协议里必须明确声明收集了哪些用户信息微信昵称、头像、手机号、位置信息以及用途。我在前端弹窗收集用户信息前先调了wx.getPrivacySetting接口判断用户是否同意过隐私协议不同意则用官方提供的隐私弹窗组件引导用户同意。关于虚拟支付千万别碰餐饮实体商品走微信支付商户通道没有问题但如果你在系统里加了会员卡充值虚拟优惠券购买这类项目就涉及虚拟支付小程序平台对这类管控极严动不动就封禁支付能力。我这个系统里只做线下商品的在线支付不做虚拟商品交易。6.3 服务器部署与上线后的日常运维部署这块我建议用轻量云服务器加Docker Compose编排把后端服务、MySQL、Redis、WebSocket服务分别做成容器然后用Nginx做反向代理和HTTPS终结。Nginx配置文件里记得把WebSocket的Upgrade头配置好不然长连接会被Nginx截断server { listen 443 ssl; server_name api.yourshop.com; ssl_certificate /your/path/fullchain.pem; ssl_certificate_key /your/path/privkey.pem; location /api/ { proxy_pass http://backend-server:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /ws/ { proxy_pass http://backend-server:9090; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; } }数据库备份我直接用mysqldump加crontab每天凌晨两点执行一次全量备份保留最近7天。上线一个月后你的数据会变成最宝贵的资产订单记录、用户信息、营业数据一旦丢失就是事故级别的损失。系统上线后还有一个不能漏的动作申请小程序订单管理相关的消息订阅模板。比如用户下单成功后给用户推送一条商家已接单的模板消息这种通知能明显提升用户体验。订阅消息的申请要在小程序后台的订阅消息里选模板审核也需要一点时间所以尽量提前申请。7. 压测与稳定性一个容易被毕设忽视、但真实项目必须面对的问题如果你只是交个毕设可能压测不是必须的但如果你想把这个项目作为求职项目经历放进简历或者你真的打算给商家部署使用稳定性是你必须面对的。我在这套系统上做过一轮并发压测工具用的JMeter场景是模拟50个用户同时提交订单。第一次压测结果问题很明显下单接口在数据库层面有大量的行锁竞争订单表插入和明细表插入是两笔操作虽然放在了一个事务里但在高并发下还是会因为锁等待出现超时。优化措施如下订单号生成从数据库自增ID改成了时间戳商户ID随机数的后端生成策略另外写了一个专门的号段生成器用Redis的INCR提前取号段降低对订单表的插入争用。菜品销量字段的扣减改成先查Redis缓存再异步批量回写数据库。这样用户端看到的是实时销量数据库的写入压力则小很多。数据库连接池参数根据压测结果做了调整初始连接数调到5最大连接数调到50连接等待超时时间设置为500ms。下单接口的幂等Redis key设置了2小时的过期时间防止Redis内存无限增长。优化后重新压测50并发下单接口的平均响应时间稳定在200ms以内无超时无数据错乱。如果你用云数据库记得在压测前把实例规格临时调大一点压完再调回来这样能省不少钱。我自己是直接在本地服务器压的配置就是2核4G压测结果作为论文里性能测试章节的数据支撑完全够用。关于稳定性还要注意小程序端的请求超时时间设置。默认的wx.request超时时间是60秒对于点餐场景来说太长了。如果用户网络不好用户会一直卡在提交中的加载状态。我把超时时间统一设成10秒并且加了失败重试机制请求超时后自动重试一次如果还是失败就明确提示用户网络异常让用户检查网络后再试。同时在下单按钮上做了防重复提交的loading状态控制点击后立刻禁用按钮避免用户因为焦躁连点导致多个订单。8. 踩坑实录几个看似不起眼但足以让你熬夜的细节问题这些是我在实际开发和上线过程中真实遇到过的问题每一个都花了不少时间排查。写出来给你省点力气。坑一时间字段的类型选择小程序端和后端联调时时间字段如果返回的是2025-01-12T10:30:00.000Z这种ISO格式前端 new Date() 解析是没问题的但如果你直接在页面里做字符串截取展示容易出现8小时时差。因为ISO格式默认是UTC时间中国时区要加8小时。我最后统一的做法是后端接口返回的所有时间字段都转成时间戳字符串毫秒级前端统一用自己封装的时间格式化函数处理。这样彻底避开时区解析混乱的问题。坑二微信支付金额的单位微信支付金额的单位是分这是文档明确写的但真的很容易忽略。如果你传了28.00而不是2800微信支付接口会直接报错金额不合法。我在下单接口的后端代码里写了一个统一转换函数接收前端传入的元金额字符串内部转成整数分所有跟金额相关的计算都用分只有返回前端展示时才转回元。这个约定同时写进了项目文档前端对接的时候也会少踩这个坑。坑三小程序冷启动时的登录竞态小程序冷启动时首页多个组件会同时开始请求数据但这些请求依赖登录态token。如果token还没拿到就发请求后端会返回401然后各个请求各自触发重新登录造成请求风暴。我的解法是前端封装的request方法里做一个登录中间态处理。第一个请求发现没有token时先发起登录流程其他请求进入等待队列登录完成后把队列里的请求全部带token重放。这样整个启动过程只会触发一次登录后续请求全部复用同一个token。坑四菜品图片的OSS防盗链如果你用了云存储的图片C端小程序请求图片时如果带了Referer头比如从某个网页跳转过来而云存储设置了防盗链规则图片会加载失败。微信小程序的web-view里打开页面时Referer是小程序域名一般没问题但如果有人在浏览器里直接访问你的小程序H5版页面图片就可能全部裂开。我的做法是云存储统一开启白名单Referer把小程序域名、商家后台域名加进白名单同时配置图片URL签名有效期防止被人盗刷流量。9. 项目源码结构与论文说明你拿到手的到底有什么最后说下整套项目源码的目录结构方便你拿到之后快速定位代码。wx-restaurant/ ├── miniprogram/ # 小程序前端项目 │ ├── pages/ │ │ ├── index/ # 首页分类菜品列表 │ │ ├── cart/ # 购物车页 │ │ ├── order/ # 订单列表、订单详情 │ │ ├── profile/ # 个人中心 │ │ └── checkout/ # 确认下单页 │ ├── utils/ # request封装、工具函数 │ └── app.js # 全局逻辑、登录状态管理 ├── admin-web/ # 商家后台网页端 │ ├── pages/dashboard # 营业看板 │ ├── pages/dish # 菜品管理 │ ├── pages/order # 订单处理 │ └── pages/settings # 商家设置 ├── server/ # 后端服务Java Spring Boot │ ├── controller/ # 接口层 │ ├── service/ # 业务逻辑层 │ ├── mapper/ # 数据访问层 │ ├── config/ # 微信配置、Redis配置 │ └── websocket/ # 实时推送服务 ├── sql/ # 数据库初始化脚本 └── docs/ # 论文说明文档、接口文档、部署文档论文说明部分我建议至少包含这几章选题背景与意义、需求分析用例图、功能需求、非功能需求、系统设计架构图、数据库ER图、接口设计、系统实现核心代码与逻辑说明、系统测试功能测试用例、性能测试结果、总结与展望。我这里准备的文档里提供了一套完整的论文框架和每个章节的写作素材你可以按自己学校要求调整格式。论文里的架构图我建议自己用Visio或者draw.io画一遍不要直接贴别人的因为导师可能会问细节。源码的使用方式很简单先按sql目录里的脚本建库再改后端配置文件里的数据库连接、微信小程序AppID与Secret、商户号与证书路径然后分别启动后端服务和前端项目用微信开发者工具导入miniprogram目录即可看到效果。商家后台是独立的Web项目npm install之后npm run dev就能跑起来。个人在折腾这套系统的过程中最大的体会是点餐系统不算难但它是麻雀虽小五脏俱全的典型。你在这里面做的每一个决策——从状态机的设计、金额精度的处理、接口是否幂等、实时通知选什么方案——都在悄悄决定这个系统是不是真的能拿去给人用。很多毕设项目能演示但不敢上线往往就是缺在这些细节上。如果你按这篇的思路把每个模块都做扎实这套系统不管是用来毕业还是用来接单都拿得出手。
微信点餐管理系统开发实战：从数据库设计到部署上线
做了多年的微信小程序开发带过的毕设项目和实战系统不在少数但点餐系统绝对是我见过看着简单、做起来最琐碎的一类。你随便搜一下微信点餐管理系统出来的源码一堆但真正能跑通完整交易链路、能在审核期不被打回来的其实不多。这篇我把一个相对完整的微信点餐管理系统从需求拆解、数据库设计、小程序端核心代码、商家后台、部署上线到避坑清单全部过一遍适合正在做毕设、或者想接餐饮商家外包单的开发者在已有基础上快速落地。项目配套的完整源码和论文说明文件我都会按模块说明结构方便你对照自己的工程做调整。先说清楚这个系统做了什么用户打开微信小程序浏览菜品分类加购物车提交订单选择到店自取或堂食扫码点餐然后支付商家端有一个独立的管理后台网页端可以上架下架菜品、设置每日特价、查看订单、操作接单/出餐/完成以及查看基础的营业统计。用户端和商家端的数据通过云端接口实时同步后厨或者前台能看到新订单提醒。下面直接进入正题我把整个系统的搭建过程按模块拆开讲。1. 需求边界设计先搞清楚点餐系统到底要管哪些事点餐系统听起来功能简单但一旦进入真实业务场景需求边界很容易失控。我在开始写代码前会先把整个系统的用户角色和业务流程画清楚。这套系统的核心角色就两个C端用户和B端商家管理员但在开发时还要考虑一个隐藏的后台运维角色用来处理超时订单、退款异常这类边缘情况。1.1 用户角色与核心业务规则C端用户侧最核心的流程是扫码/搜索进入小程序 - 浏览菜品 - 加入购物车 - 提交订单 - 在线支付 - 等待商家出餐 - 取餐/用餐。这个链路里有一个特别容易忽略的点订单在已支付状态之后不是直接跳到已完成而是中间要经过商家接单、制作、出餐等环节。很多简化版源码在这里直接砍掉了中间态导致商家根本没法操作订单流转这是判断一个点餐系统是否可用的关键分水岭。B端商家側业务规则更细菜品管理需要区分在售和停售状态停售菜品在用户端应该直接隐藏或置灰而不是等用户下单后再说这个没了。订单处理新订单要有提醒接单后进入制作制作完成标记出餐用户取餐后订单完结。营业统计至少要有当日营业额、订单数、热销菜品排行这些数据直接从订单表和订单明细表聚合出来。还有一个被我反复验证过的重要规则用户提交订单时必须校验菜品是否还在售、价格是否发生变化不能直接信任前端传过来的价格。原因往下看这是我在实测中踩过的坑。1.2 数据库设计表结构是这样拆出来的数据模型是整个系统最需要仔细设计的部分后续所有接口的复杂度都由它决定。我用MySQL作为主存储核心表一共9张用户表useropenid唯一索引、昵称、头像、手机号、注册时间菜品分类表category分类名称、排序权重、是否置顶菜品表dish所属分类、名称、描述、图片URL、价格存分为单位、是否停售、月销量购物车表cart用户ID、菜品ID、数量、加入时间小程序端也可用本地存储但服务端保存更稳订单表orders订单号、用户ID、总金额、订单状态、支付状态、支付时间、订单类型堂食/自取、备注订单明细表order_detail订单ID、菜品ID、菜品名称快照、单价快照、数量管理员表admin账号、密码加密存储、角色营业时间表business_hours可灵活配置各时段的营业状态系统配置表config存储起送价、配送费、商家公告等菜品价格我是强烈建议用分存储的不要在数据库里用FLOAT或DECIMAL存元。整型运算没有精度误差前端展示时再做一次除以100的转换。金额这种数据一旦出现0.10.2这类精度问题对账的时候会让你怀疑人生。订单状态我用整数存储定义如下约定0待支付、1已支付待接单、2已接单制作中、3已出餐待取餐、4已完成、5已取消、6退款中、7已退款。这个状态机在商家后台和用户端都要保持一致所以我把它抽成了常量文件前后端各维护一份避免状态码对不上。2. 小程序端登录与用户体系最容易被忽视的隐蔽工程登录模块是点餐系统第一个要做的功能也是问题最多的功能。很多初学者直接把wx.login拿到的code往后台一传就以为登录完成了其实这个过程的完整链路是小程序端调用wx.login获取临时code把code发给自己的后端后端拿着code加上小程序的AppID和AppSecret去微信的接口换openid和session_key然后用openid去查用户表。2.1 静默登录与token续期的设计用户打开小程序时我不希望弹出一个强制授权框那样跳出率太高。所以用户端走的是静默登录逻辑前端先调wx.login拿code后端拿到code换openid后如果用户表里没有记录就自动创建一条并签发一个自定义的登录态token返回给前端。前端把token存到storage里后续所有请求都在header里携带这个token。这个token的有效期我设置的是7天但有个细节小程序可能7天内多次打开所以我做了一个token自动续期策略。后端返回token时同时返回一个expires_in字段小程序在每次请求的响应拦截器里判断如果token快过期了剩余时间少于1天就静默调一次刷新接口把旧token换新的。这样用户完全无感知也不会出现用着用着突然被踢回登录页的情况。2.2 获取手机号与用户信息授权的边界新版微信已经基本废弃了wx.getUserInfo直接弹窗拿昵称头像的方式改成用户主动点击头像昵称填写能力或者用手机号快速验证组件。点餐系统里手机号很重要因为到店自取需要联系用户。但这里有个体验和审核的平衡问题如果一进来就强制要手机号转化率会掉很多。我的做法是手机号获取放在用户第一次提交订单时作为下单流程的一步而不是小程序启动时。这样既不会过度打扰浏览用户又能在真正需要联系用户的时候拿到必要信息。用微信官方提供的button open-typegetPhoneNumber组件后端拿code换手机号整个过程不经过前端明文传递安全性有保障。2.3 用户端接口的异常处理不要只处理成功路径接口设计上除了常规的成功返回我专门设计了一套错误码体系。比如菜品已下架返回2001、库存不足返回2002、订单已关闭返回2003、登录态过期返回401。前端请求封装统一处理这些错误码遇到401就静默重新登录再重放请求遇到2001就刷新购物车并提示用户菜品已售罄已自动移除。这套体系看着不起眼但在真实环境中特别有用。一个小程序上线后你根本无法预判用户会在什么网络环境、什么操作顺序下触发问题。比如用户把小程序切到后台半小时再回来直接点提交订单token可能换了菜品可能下架了价格可能调了没有统一错误处理的话用户只会看到莫名其妙的请求失败。3. 点餐核心链路菜品展示、购物车与订单落库这是整个系统最核心的业务代码区。我会把每个环节的关键实现逻辑讲清楚包括为什么这样设计。3.1 菜品数据与分类的接口设计菜品列表接口我设计成了两个一个获取全部分类含分类下的菜品一个获取单个菜品详情。分类接口返回的数据结构是嵌套的这样小程序端渲染时不需要做二次聚合处理一次性拿到所有数据直接渲染。这里特别注意一个性能问题不能每次用户打开小程序都从数据库实时查全量菜品。菜品的更新频率其实很低半小时、一小时变一次就算频繁了。我在后端给这个接口加了Redis缓存缓存key按菜品分类_店铺ID区分商家后台修改菜品后主动删除对应缓存下次请求自动回源刷新。实测在低配云服务器上接口响应从平均300ms降到了50ms以内。菜品的图片存储我用的云存储返回给前端的是CDN加速过的URL。图片有一个规范必须等比压缩因为小程序端列表图和详情图尺寸要求不一样不能一张原图走天下。我在商家后台上传菜品图片时后端会自动生成多个尺寸的缩略图列表用200x200详情用640x640这样能显著减少流量消耗和首屏加载时间。3.2 购物车的本地状态管理避免服务端频繁读写购物车这块初学者最容易犯的错是把每个加购动作都实时同步到服务端。点餐场景下用户操作购物车是非常高频的而且网络并不总是稳定每次操作都请求后端会让体验变得非常糟糕。我的方案是小程序端本地维护购物车使用全局状态管理小程序里可以用globalData或者引入轻量的状态库数据结构设计成{ items: [ { dishId: 12, name: 招牌牛肉面, price: 2800, qty: 2, specs: 微辣 }, { dishId: 18, name: 冰酸梅汤, price: 600, qty: 1, specs: } ], totalQty: 3, totalAmount: 6200 }这个本地购物车会在用户每次加购时更新同时同步到storage做持久化。真正和服务端交互的节点在提交订单那一刻一次性把购物车数据发送给后端。这样设计还有一个好处就算用户中途退出小程序下次进来购物车还在。购物车本地化有一个必须处理的细节用户打开小程序时要从服务端拉取一遍购物车里所有菜品的实时价格和售罄状态和本地缓存做比对。菜品价格变了以服务端为准并提示用户菜品停售了直接移除并提示。这个校验我放在进入购物车页面的时机执行保证下单前用户看到的一定是准确信息。下单接口再做一次兜底校验双重保险。3.3 下单接口的服务端校验与幂等处理服务端的下单接口是整个系统最需要谨慎的接口因为它直接涉及钱。前端提交的请求里只传这些字段订单类型、备注、购物车明细列表菜品ID和数量。后端要做的事情如下第一步根据用户token解析出用户ID然后查询用户信息是否存在不存在直接拒绝。 第二步将购物车明细里的菜品ID批量查库拿出每个菜品的当前价格、在售状态和前端传的数量重新计算总金额。这里绝对不信任前端传过来的totalAmount而是以后端计算的为准。前端显示的总金额只是参考展示。 第三步用数据库事务把订单主表记录和订单明细表记录写入同时扣减菜品销量字段清空用户服务端的购物车记录。这期间如果任何一步失败整个事务回滚。 第四步生成业务订单号并返回给前端前端拿到订单号后调用微信支付接口。下单接口还有一个隐藏需求幂等处理。用户可能在网络波动时多次点击提交按钮如果每次都生成新订单就会出问题。我的方案是给下单请求加一个前端生成的请求唯一标识后端以这个标识做去重判断。同一标识的重复请求直接返回第一次的订单结果不会重复建立订单。实测这个设计在真实场景下几乎必然会被触发非常重要。3.4 支付流程微信支付接入的几个关键细节微信支付接入是点餐系统最劝退初学者的环节。我快速过一遍完整流程和需要注意的配置点第一步申请微信支付商户号。注意主体要和小程序的主体一致不然很多支付功能没法开。第二步在小程序后台开通微信支付并配置支付目录、回调域名。第三步后端引入微信支付v3的SDK我用的是官方sdk不要自己造轮子去拼签名配置商户号、API证书、APIv3密钥。第四步后端统一下单接口返回给前端5个核心参数时间戳、随机字符串、订单详情扩展字符串、签名方式、签名。前端用wx.requestPayment发起支付。支付回调是这里最容易出问题的环节。微信服务器会异步通知你的回调地址通知里带签名和订单状态。你要做的是验签 - 判断订单状态是SUCCESS - 更新本地订单状态为已支付 - 返回处理成功给微信服务器。这里有一个坑微信会重试通知如果业务处理成功但你没有正确返回微信会一直重复通知造成订单状态被重复更新的问题。所以支付成功的回调处理必须做幂等先查订单当前状态如果已经是已支付就不要再重复更新了直接返回成功。关于支付证书很多源码包里的证书是明文的安全性堪忧。你在真实部署时一定不要把商户号和证书机密提交到代码仓库里要用环境变量或者单独的配置文件管理并且配置文件要加进.gitignore。4. 看板式的实时订单提醒别用轮询用WebSocket长连接这是用户堂食场景的刚需也是我在毕设评估里最看重的功能点之一。用户下单后商家端需要几乎实时地看到新订单并处理用户端在等待出餐时也需要看到订单状态的实时变化不能老盯着屏幕手动刷新。4.1 为什么最终选了WebSocket而不是定时轮询不少简化版源码用的是前端定时器每5秒拉一次订单状态接口。在小并发场景下这样确实能用但有两个硬伤第一订单状态更新不是瞬时的最坏情况下用户要等5秒才能看到新状态第二用户量稍微上来一点服务端的查询压力会被无意义的轮询请求放大很多倍。这个系统里我用了WebSocket长连接小程序端通过WebSocket连接服务器服务端在订单状态变化时主动推送消息给对应连接。用户端和商家端都依赖于这个通道。我用的方案是服务端在订单状态变更的代码逻辑处主动向对应角色的WebSocket连接推送一条消息消息内容是订单ID和新的状态码。前端收到后如果当前正停留在订单详情页就自动刷新页面数据如果在首页就弹出一个轻量提示您的订单已出餐。接入过程有几个实际经验分享。小程序端原生代码直接这样写wx.connectSocket({ url: wss://api.yourshop.com/ws, header: { Authorization: token } }) wx.onSocketMessage(function (res) { const data JSON.parse(res.data) // data.type ORDER_STATUS_CHANGED // data.orderId, data.status handleOrderStatus(data) }) wx.onSocketClose(function () { // 心跳断了做重连最多重试5次 retryConnect() })后端我用的是Netty实现WebSocket服务如果你用Java系后端的话每台机器维护一份userId到Channel的映射用ConcurrentHashMap存储。如果是单体应用这样完全够用如果你的装机量比较大需要用Redis的Pub/Sub做跨节点广播不然A机器收到订单变更B机器上的用户连接收不到消息。小程序端的WebSocket有些老坑比如切后台后连接会被系统断掉需要在前端实现重连机制和心跳保活。我一般用每30秒发一个ping包服务器端60秒内没收到ping就主动断开连接前端检测到断线后自动重连。4.2 商家端实时订单墙的实现商家端我用的是一个独立的Web管理后台界面其中最重要的页面是订单看板它的核心是一个实时更新的订单列表。每个订单卡片展示订单号、用户取餐号、菜品清单、备注、金额、倒计时从接单开始计时超过15分钟变红提醒、操作按钮。新订单到达时WebSocket推送消息触发列表头部插入一张新卡片并播放提示音。商家点击接单状态变成制作中点击出餐状态变成已出餐待取餐用户取餐后用户端点击确认取餐订单状态变成已完成。每一步操作都同步推送状态给用户端。取餐号的设计可以在这里说一下它是店内自取的标识我用的是一个3位数字编号每天从1开始递增。这样商家和用户喊号方便不会暴露用户真实订单号。生成逻辑是在下单接口里取当天最大取餐号1用Redis的INCR命令实现原子递增一天一重置。5. 数据统计模块让商家看到营业情况的真实全貌很多点餐系统做完了点餐、支付、订单管理就结束了但商家真正长期使用的是数据统计功能。一个餐饮老板每天最关心的几个数据今天卖了多少单、营业额多少、哪个菜品卖得最多、哪个时段是高峰期。这部分我用SQL聚合实现不引入额外的大数据组件性价比很高。5.1 营业日报的SQL实现思路当日总营业额和总订单数SELECT COUNT(*) AS order_count, SUM(total_amount) AS total_revenue FROM orders WHERE pay_status 1 AND pay_time CURDATE() AND pay_time CURDATE() INTERVAL 1 DAY;热销菜品排行按销量倒序SELECT d.id, d.name, SUM(od.qty) AS sale_quantity FROM order_detail od LEFT JOIN dish d ON od.dish_id d.id LEFT JOIN orders o ON od.order_id o.id WHERE o.pay_time CURDATE() AND o.pay_time CURDATE() INTERVAL 1 DAY AND o.pay_status 1 GROUP BY d.id, d.name ORDER BY sale_quantity DESC LIMIT 10;小时维度订单分布用于判断忙闲时段SELECT HOUR(pay_time) AS hour, COUNT(*) AS order_count FROM orders WHERE pay_time CURDATE() AND pay_time CURDATE() INTERVAL 1 DAY AND pay_status 1 GROUP BY HOUR(pay_time) ORDER BY hour;这三个SQL基本覆盖了我的统计需求。如果你需要更细的维度可以额外维护一张日汇总表每天凌晨用定时任务把前一天的数据聚合写入报表查询时直接读汇总表而不是实时跑原始订单表。数据量上来之后这个优化会非常重要。5.2 经营看板的可视化呈现后端提供统计接口后商家后台前端用轻量图表库渲染趋势折线图、菜品排行条形图、时段分布柱状图。我做的是一个可切换时间的维度今日、近7日、近30日对应的SQL只是把时间范围参数改一下聚合逻辑完全复用。数据刷新策略是打开页面时拉取一次之后每5分钟自动拉取一次。实时性要求不高的场景完全够用也没必要为这个专门接WebSocket。6. 部署上线与微信生态配置审核期反复踩坑的避坑全集功能全部写完、本地自测通过并不代表可以上线。微信小程序的审核、域名配置、HTTPS证书、类目选择每一步都有坑。我把自己踩过的和帮别人解决过的高频问题集中列一下。6.1 前后端联调与真机预览的必备设置开发阶段用微信开发者工具中的不校验合法域名选项很爽但上线前一定要做三件事第一小程序后台配置request合法域名、socket合法域名、uploadFile合法域名。这里要注意域名必须是HTTPS且不能带端口默认443而且ICP备案一定要完成。我见过很多项目卡在域名备案上一等就是好几天。第二本地开发环境联调时我发现一个效率提升的技巧用微信开发者工具自带的自定义条件编译功能根据编译模式动态切换API的baseURL。开发环境指向本地局域网IP加后端端口生产环境指向正式域名。在代码里做一个环境判断不要每次发版前手动改一堆请求地址。第三尽可能用真机预览。开发者工具的模拟器里很多能力跟真机有差异特别是网络请求的TLS版本兼容性、微信支付的拉起表现、WebSocket在弱网环境的断线重连。这些只有真机测过才敢放心提审。6.2 审核被拒的常见原因与解决办法餐饮点餐小程序在提审时最常遇到的是类目审核问题。如果小程序涉及餐饮服务或点餐平台可能需要对应的资质文件。一个规避思路如果你的系统是给单一商家使用的可以走餐饮商家自营类目需要的资质比平台型要少如果你做的是多商家入驻的聚合点餐平台类目要求会严格很多通常需要食品经营许可证等资质。这一点在项目规划和论文说明里都要写清楚别等到提审被拒了再调整方向。另一个高频被拒原因是用户隐私保护指引没有配置完整。小程序的隐私协议里必须明确声明收集了哪些用户信息微信昵称、头像、手机号、位置信息以及用途。我在前端弹窗收集用户信息前先调了wx.getPrivacySetting接口判断用户是否同意过隐私协议不同意则用官方提供的隐私弹窗组件引导用户同意。关于虚拟支付千万别碰餐饮实体商品走微信支付商户通道没有问题但如果你在系统里加了会员卡充值虚拟优惠券购买这类项目就涉及虚拟支付小程序平台对这类管控极严动不动就封禁支付能力。我这个系统里只做线下商品的在线支付不做虚拟商品交易。6.3 服务器部署与上线后的日常运维部署这块我建议用轻量云服务器加Docker Compose编排把后端服务、MySQL、Redis、WebSocket服务分别做成容器然后用Nginx做反向代理和HTTPS终结。Nginx配置文件里记得把WebSocket的Upgrade头配置好不然长连接会被Nginx截断server { listen 443 ssl; server_name api.yourshop.com; ssl_certificate /your/path/fullchain.pem; ssl_certificate_key /your/path/privkey.pem; location /api/ { proxy_pass http://backend-server:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /ws/ { proxy_pass http://backend-server:9090; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; } }数据库备份我直接用mysqldump加crontab每天凌晨两点执行一次全量备份保留最近7天。上线一个月后你的数据会变成最宝贵的资产订单记录、用户信息、营业数据一旦丢失就是事故级别的损失。系统上线后还有一个不能漏的动作申请小程序订单管理相关的消息订阅模板。比如用户下单成功后给用户推送一条商家已接单的模板消息这种通知能明显提升用户体验。订阅消息的申请要在小程序后台的订阅消息里选模板审核也需要一点时间所以尽量提前申请。7. 压测与稳定性一个容易被毕设忽视、但真实项目必须面对的问题如果你只是交个毕设可能压测不是必须的但如果你想把这个项目作为求职项目经历放进简历或者你真的打算给商家部署使用稳定性是你必须面对的。我在这套系统上做过一轮并发压测工具用的JMeter场景是模拟50个用户同时提交订单。第一次压测结果问题很明显下单接口在数据库层面有大量的行锁竞争订单表插入和明细表插入是两笔操作虽然放在了一个事务里但在高并发下还是会因为锁等待出现超时。优化措施如下订单号生成从数据库自增ID改成了时间戳商户ID随机数的后端生成策略另外写了一个专门的号段生成器用Redis的INCR提前取号段降低对订单表的插入争用。菜品销量字段的扣减改成先查Redis缓存再异步批量回写数据库。这样用户端看到的是实时销量数据库的写入压力则小很多。数据库连接池参数根据压测结果做了调整初始连接数调到5最大连接数调到50连接等待超时时间设置为500ms。下单接口的幂等Redis key设置了2小时的过期时间防止Redis内存无限增长。优化后重新压测50并发下单接口的平均响应时间稳定在200ms以内无超时无数据错乱。如果你用云数据库记得在压测前把实例规格临时调大一点压完再调回来这样能省不少钱。我自己是直接在本地服务器压的配置就是2核4G压测结果作为论文里性能测试章节的数据支撑完全够用。关于稳定性还要注意小程序端的请求超时时间设置。默认的wx.request超时时间是60秒对于点餐场景来说太长了。如果用户网络不好用户会一直卡在提交中的加载状态。我把超时时间统一设成10秒并且加了失败重试机制请求超时后自动重试一次如果还是失败就明确提示用户网络异常让用户检查网络后再试。同时在下单按钮上做了防重复提交的loading状态控制点击后立刻禁用按钮避免用户因为焦躁连点导致多个订单。8. 踩坑实录几个看似不起眼但足以让你熬夜的细节问题这些是我在实际开发和上线过程中真实遇到过的问题每一个都花了不少时间排查。写出来给你省点力气。坑一时间字段的类型选择小程序端和后端联调时时间字段如果返回的是2025-01-12T10:30:00.000Z这种ISO格式前端 new Date() 解析是没问题的但如果你直接在页面里做字符串截取展示容易出现8小时时差。因为ISO格式默认是UTC时间中国时区要加8小时。我最后统一的做法是后端接口返回的所有时间字段都转成时间戳字符串毫秒级前端统一用自己封装的时间格式化函数处理。这样彻底避开时区解析混乱的问题。坑二微信支付金额的单位微信支付金额的单位是分这是文档明确写的但真的很容易忽略。如果你传了28.00而不是2800微信支付接口会直接报错金额不合法。我在下单接口的后端代码里写了一个统一转换函数接收前端传入的元金额字符串内部转成整数分所有跟金额相关的计算都用分只有返回前端展示时才转回元。这个约定同时写进了项目文档前端对接的时候也会少踩这个坑。坑三小程序冷启动时的登录竞态小程序冷启动时首页多个组件会同时开始请求数据但这些请求依赖登录态token。如果token还没拿到就发请求后端会返回401然后各个请求各自触发重新登录造成请求风暴。我的解法是前端封装的request方法里做一个登录中间态处理。第一个请求发现没有token时先发起登录流程其他请求进入等待队列登录完成后把队列里的请求全部带token重放。这样整个启动过程只会触发一次登录后续请求全部复用同一个token。坑四菜品图片的OSS防盗链如果你用了云存储的图片C端小程序请求图片时如果带了Referer头比如从某个网页跳转过来而云存储设置了防盗链规则图片会加载失败。微信小程序的web-view里打开页面时Referer是小程序域名一般没问题但如果有人在浏览器里直接访问你的小程序H5版页面图片就可能全部裂开。我的做法是云存储统一开启白名单Referer把小程序域名、商家后台域名加进白名单同时配置图片URL签名有效期防止被人盗刷流量。9. 项目源码结构与论文说明你拿到手的到底有什么最后说下整套项目源码的目录结构方便你拿到之后快速定位代码。wx-restaurant/ ├── miniprogram/ # 小程序前端项目 │ ├── pages/ │ │ ├── index/ # 首页分类菜品列表 │ │ ├── cart/ # 购物车页 │ │ ├── order/ # 订单列表、订单详情 │ │ ├── profile/ # 个人中心 │ │ └── checkout/ # 确认下单页 │ ├── utils/ # request封装、工具函数 │ └── app.js # 全局逻辑、登录状态管理 ├── admin-web/ # 商家后台网页端 │ ├── pages/dashboard # 营业看板 │ ├── pages/dish # 菜品管理 │ ├── pages/order # 订单处理 │ └── pages/settings # 商家设置 ├── server/ # 后端服务Java Spring Boot │ ├── controller/ # 接口层 │ ├── service/ # 业务逻辑层 │ ├── mapper/ # 数据访问层 │ ├── config/ # 微信配置、Redis配置 │ └── websocket/ # 实时推送服务 ├── sql/ # 数据库初始化脚本 └── docs/ # 论文说明文档、接口文档、部署文档论文说明部分我建议至少包含这几章选题背景与意义、需求分析用例图、功能需求、非功能需求、系统设计架构图、数据库ER图、接口设计、系统实现核心代码与逻辑说明、系统测试功能测试用例、性能测试结果、总结与展望。我这里准备的文档里提供了一套完整的论文框架和每个章节的写作素材你可以按自己学校要求调整格式。论文里的架构图我建议自己用Visio或者draw.io画一遍不要直接贴别人的因为导师可能会问细节。源码的使用方式很简单先按sql目录里的脚本建库再改后端配置文件里的数据库连接、微信小程序AppID与Secret、商户号与证书路径然后分别启动后端服务和前端项目用微信开发者工具导入miniprogram目录即可看到效果。商家后台是独立的Web项目npm install之后npm run dev就能跑起来。个人在折腾这套系统的过程中最大的体会是点餐系统不算难但它是麻雀虽小五脏俱全的典型。你在这里面做的每一个决策——从状态机的设计、金额精度的处理、接口是否幂等、实时通知选什么方案——都在悄悄决定这个系统是不是真的能拿去给人用。很多毕设项目能演示但不敢上线往往就是缺在这些细节上。如果你按这篇的思路把每个模块都做扎实这套系统不管是用来毕业还是用来接单都拿得出手。
