简介微信点餐小程序开发资源包面向希望快速上手小程序开发的初中级开发者与餐饮行业技术从业者。内容覆盖从工具搭建、前端页面到后端接口与数据库设计的完整链路提炼了微信开发者工具使用、WXML/WXSS框架、数据绑定与事件处理、微信支付及分享API调用、后端RESTful接口规划、数据库表结构设计、UI适配、测试发布与安全防护等关键知识点。压缩包共1129个文件约28.87MB其中包含427个PHP后端文件、138个HTML页面、113个JS脚本、38个CSS样式表、129个PNG与113个JPG图片资源、9个Markdown文档及2个SQL数据文件等便于对照完整项目结构进行学习。已有1258人学习下载。通过源码阅读和资源内文档可了解点餐系统中菜品管理、购物车、订单提交与支付流程等模块的实现思路并为二次开发或课程设计提供可直接借鉴的工程参考。1. 微信点餐小程序的工程骨架不只是换皮的前端页面很多人拿到微信点餐小程序源码时第一反应是打开开发者工具把页面跑起来却发现根目录是一堆bootstrap.css、ueditor.css、video-js.css之类后台管理端静态资源。这说明项目并不是一个纯前端模板而是“商家管理后台 小程序端 后端 API”三层结构。点餐业务的核心难点也不在样式而在微信登录态、支付回调、订单状态流转这三条链路是否打通。如果你正在做毕业设计或接商用点餐项目先理解这份资源里哪些文件属于服务端渲染的后台、哪些属于小程序端才不会在后面联调时被 404 和wx.request失败反复打断。2. 小程序端结构层与样式层WXML/WXSS 的差异落地2.1 微信开发者工具里初始化点餐项目结构、目录和调试技巧微信开发者工具是绕不开的第一站。导入项目后我建议先把基础库版本调到 2.30.0 以上因为后续分享朋友圈、canvas 2d 绘制海报这些能力对基础库有要求。初始化后的典型目录结构如下├── app.js ├── app.json ├── app.wxss ├── pages │ ├── index │ ├── menu │ ├── cart │ └── order ├── components │ └── dish-card └── utils ├── request.js └── config.js说明pages下每个页面由.js、.json、.wxml、.wxss四个同名文件组成这是微信小程序的基础约定。app.json里注册页面路径pages/index/index作为入口页面。utils/config.js建议统一维护baseURL避免在几十个页面里写死开发地址。调试技巧在开发者工具的“详情-本地设置”里勾选“不校验合法域名”开发阶段可以跳过域名校验。但上线前必须在 mp.weixin.qq.com 的“开发管理-服务器域名”里配置request合法域名且必须是 HTTPS 协议。支付回调的域名也要提前加白否则模拟器里没问题真机上会静默失败。提示拿到项目源码后第一件事是全局搜索http://把所有开发环境地址改成https://并统一收敛到utils/config.js。很多学员在这里踩坑个别页面写死了 IP 地址换环境后只有部分接口能用。如果你更习惯 Vue 语法用 uni-app 配合 HBuilderX 也能把点餐业务跑起来但原生 WXML 暴露的细节更多排查问题时你能看到微信框架底层的编译产物所以我下面用原生语法讲实现这样不同技术栈的人都能理解数据是怎么从接口流转到渲染层的。2.2 页面搭建从菜品卡片到购物车角标的 WXML 片段以菜品列表页为例卡片需要展示图片、名称、价格、销量以及右下角的“加入购物车”按钮。核心 WXML 结构如下view classmenu-item wx:for{{dishList}} wx:keyid image src{{item.cover}} modeaspectFill / view classinfo text classname{{item.name}}/text text classsales已售 {{item.sales}}/text text classprice¥{{item.price}}/text /view button classadd-btn>Page({ data: { dishList: [], }, async onLoad() { await this.fetchDishList(); }, async fetchDishList() { const { data } await wx.request({ url: ${getApp().globalData.baseURL}/api/dishes, }); const list data.map((d) ({ id: d.id, name: d.dish_name, cover: d.cover_url, price: Number(d.price).toFixed(2), sales: d.sold_count, })); this.setData({ dishList: list }); }, onAddToCart(e) { const id e.currentTarget.dataset.id; // 这里可以派发一个全局事件让购物车角标更新 console.log(add dish:, id); }, });说明这里把后端字段dish_name映射成前端字段name是一种低成本防御。如果数据库字段变化只需要改这一处 map如果后端字段重复也不会把脏数据直接渲染到页面。setData更新数据是异步的有大小限制购物车数量这种高频变化应该增量更新不要每次把整个列表塞进 setData。2.3 WXSS 样式与事件绑定让按钮“可点”的核心参数WXSS 和 CSS 大部分语法一致但有一些差异会直接影响点餐页面的布局。下面是我常用的一张对比表能力HTML/CSSWXML/WXSS差异影响基础组件div/spanview/texttext内不能嵌套 view会影响富文本排版尺寸单位px/remrpx2rpx 等于 1px以 750 设计稿为基准适配不同屏宽事件绑定onclickbindtap / catchtapcatchtap阻止冒泡用于阻止点击购物车触发卡片跳转条件渲染v-ifwx:if / wx:elif组件是直接编译成不同节点不能做动态组件其中 rpx 的换算规则是在任何屏幕宽度下750rpx等于屏幕宽度。所以设计稿如果是 750 宽直接按标注的 px 尺寸写 rpx 值即可。事件绑定方面bindtap是冒泡事件catchtap会阻止冒泡。点餐场景里菜品卡片本身bindtap跳转详情而加号按钮必须用catchtaponAddToCart否则点击加号会同时触发卡片跳转体验非常糟糕。按钮还有一个容易忽略的属性hover-class设置成button-hover能提供按压反馈默认样式下很多开发者以为按钮坏了其实只是没有按态效果。样式重置也是点餐项目的必备动作。小程序button自带边框和默认背景通常我会在app.wxss里统一覆盖.add-btn { width: 56rpx; height: 56rpx; line-height: 56rpx; padding: 0; border-radius: 50%; background: #ff6a00; color: #ffffff; font-size: 36rpx; text-align: center; border: none; } .add-btn::after { border: none; }说明button::after是微信框架生成的伪元素边框不重置的话即使设置了border: none真机上仍会有一条细边。这个问题在表单类组件里同样存在属于小程序样式体系里最容易踩的坑之一。掌握上述差异后前端页面基本不会出现“样式对不上”和“事件重复触发”的低级问题。3. 后端接口与数据库建模订单和菜品的数据存取怎么设计才不别扭3.1 选型Node.js Express MySQL 的点餐接口为什么够用点餐业务的数据模型稳定但对订单一致性和库存准确性要求高。我一般选择 Node.js Express MySQL 这套组合原因是微信支付回调的报文是 XML 格式Node.js 在处理异步回调签名时比 PHP 顺手Express 路由组织简单接口数量在 20 个以内时完全够用MySQL 的事务能力可以保证下单不超卖。如果你的团队更熟 Python用 Django 也能做但下面的 API 设计思路是通用的。后端接口规划如下方法路径功能请求参数GET/api/dishes获取菜品列表category 可选POST/api/orders创建订单openid, tableNo, dishListGET/api/orders/:id查询订单详情idPUT/api/orders/:id/status更新订单状态statusPOST/api/pay/notify微信支付回调XML 报文说明openid来自小程序登录态tableNo是用户扫描桌台码获得的桌号。创建订单时后端必须校验dishList非空、数量为整数、价格以数据库为准不能信任前端传入的totalAmount。这张 API 表也可以直接作为前后端联调时的工作清单。3.2 建表与初始化数据SQL 里的字段约束和索引取舍订单和菜品直接相关的表至少有四张菜品表、订单表、订单明细表、用户表。下面的 SQL 是核心部分CREATE TABLE dishes ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, dish_name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL, cover_url VARCHAR(255) DEFAULT , stock INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, openid VARCHAR(64) NOT NULL, table_no VARCHAR(16) DEFAULT , total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2制作中 3已完成 4已取消, paid_at DATETIME NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_openid (openid), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;说明order_no必须唯一后续微信支付查询订单和退款都要靠它。金额使用DECIMAL(10,2)不用 FLOAT/DOUBLE否则累计金额会出现精度误差。status使用 TINYINT 并写注释查询性能和可读性都要比字符串好。索引方面openid和status是高频筛选项各建一个普通索引即可不要给文本字段建索引会导致写入变慢。订单明细表需要联合外键但物理外键我一般不加因为点餐系统在删除菜品时需要降级处理物理外键会让运营操作变得耗时。逻辑外键配合索引就够。3.3 RESTful 接口实现点餐、查单、改状态的关键代码创建订单是所有接口里最需要写清楚的一个。下面是一段 Express 路由示例const express require(express); const router express.Router(); const db require(../db); // 创建订单 router.post(/api/orders, async (req, res) { const { openid, tableNo, dishList } req.body; const conn await db.getConnection(); try { await conn.beginTransaction(); let total 0; for (const item of dishList) { const [rows] await conn.query( SELECT price, stock FROM dishes WHERE id ? AND status 1 FOR UPDATE, [item.id] ); if (!rows.length) return res.status(404).json({ success: false, message: 菜品不存在 }); const dish rows[0]; if (dish.stock item.count) { await conn.rollback(); return res.json({ success: false, message: 菜品 ${item.id} 库存不足 }); } total dish.price * item.count; } const orderNo PO Date.now() Math.random().toString(36).slice(2, 6).toUpperCase(); const [result] await conn.query( INSERT INTO orders (order_no, openid, table_no, total_amount) VALUES (?, ?, ?, ?), [orderNo, openid, tableNo, total] ); await conn.commit(); res.json({ success: true, orderId: result.insertId, orderNo, totalAmount: total }); } catch (err) { await conn.rollback(); res.status(500).json({ success: false, message: err.message }); } finally { conn.release(); } });说明这里用conn.getConnection()拿到的连接才能调beginTransaction。注意SELECT ... FOR UPDATE会对菜品行加锁防止两个用户同时下单导致超卖。?占位符是参数化查询不需要手动拼接字符串从根源上避免 SQL 注入。orderNo用时间戳加随机串演示够用并发量高的场景建议用 Redisincr生成连续序号再拼接日期前缀。3.4 联调时常见的状态码与参数错误排查前后端联调时最多的报错集中在三类第一openid为空导致创建订单失败。原因是登录接口没有先跑或者 token 过期。前端需要在request.js里统一判断登录态过期后重新走wx.login。第二金额不一致。前端展示的价格和后端计算的价格差 1 分钱常见原因是前端用toFixed(2)后端用Math.round(total * 100)四舍五入时机不一致。解决方案是前端只展示后端做最终计算。第三支付回调不触发。先检查微信支付商户平台是否配置了回调域名再看 Nginx 日志有没有收到微信服务器的 POST 请求。如果收到但返回 500多半是回调里数据库更新失败。我会在回调接口里加一个order_no查重的逻辑保证重复通知时幂等。// 回调通知处理 const payDone await db.query(UPDATE orders SET status 1, paid_at NOW() WHERE order_no ? AND status 0, [orderNo]); if (payDone.affectedRows 0) { // 已经处理过或订单不存在直接返回成功 res.end(xmlreturn_code![CDATA[SUCCESS]]/return_code/xml); }说明affectedRows为 0 说明订单状态不是待支付可能是重复回调或者订单不存在。此时同样返回 SUCCESS避免微信服务器反复重试。这是支付回调最常见的幂等处理。4. 微信登录、支付与分享 API 对接的完整链路4.1 wx.login 获取 code后端 code2Session 换 openid小程序端获得用户身份的标准流程是wx.login拿到临时code后端拿到code去微信服务器换取openid。前端示例wx.login({ success: async (res) { const { data } await wx.request({ url: https://your.domain.com/api/wx/login, method: POST, data: { code: res.code }, }); if (data.success) { wx.setStorageSync(token, data.token); wx.setStorageSync(openid, data.openid); } }, });对应后端实现const axios require(axios); router.post(/api/wx/login, async (req, res) { const { code } req.body; const { appid, secret } config.wx; const { data } await axios.get( https://api.weixin.qq.com/sns/jscode2session?appid${appid}secret${secret}js_code${code}grant_typeauthorization_code ); if (data.errcode) { return res.status(401).json({ success: false, message: data.errmsg }); } // 生产环境应使用 JWT 生成 token并设置过期时间 res.json({ success: true, openid: data.openid, token: createJwt(data.openid) }); });说明code2Session必须由后端发起secret一旦暴露任何人都能冒充用户身份。返回的openid是用户在本小程序内的唯一标识但不包含用户头像、昵称等资料这些信息需要在获取用户信息时单独授权。注意微信在基础库更新后不再推荐通过wx.getUserInfo直接拿个人信息点餐场景非必须时建议不采集。4.2 微信支付统一下单与 wx.requestPayment 的参数映射支付链路最容易出错的部分是签名。后端需要按微信支付规则生成paySign并在前端调起收银台。核心逻辑如下const crypto require(crypto); function makeSign(params, mchKey) { const str Object.keys(params) .filter((k) params[k] ! k ! sign) .sort() .map((k) ${k}${params[k]}) .join() key${mchKey}; return crypto.createHash(md5).update(str).digest(hex).toUpperCase(); } router.post(/api/pay/unifiedorder, async (req, res) { const { orderNo } req.body; const order await db.getOrderByNo(orderNo); const params { appid: config.wx.appid, mch_id: config.wx.mchId, nonce_str: Math.random().toString(36).slice(2), body: 微信点餐- orderNo, out_trade_no: orderNo, total_fee: Math.round(order.total_amount * 100), spbill_create_ip: req.ip, notify_url: config.wx.notifyUrl, trade_type: JSAPI, openid: order.openid, }; params.sign makeSign(params, config.wx.mchKey); // 将 params 转 XML 后 POST 到 https://api.mch.weixin.qq.com/pay/unifiedorder const payParams { appId: params.appid, timeStamp: String(Math.floor(Date.now() / 1000)), nonceStr: params.nonce_str, package: prepay_id${prepayId}, signType: MD5, }; payParams.paySign makeSign(payParams, config.wx.mchKey); res.json({ success: true, payParams }); });说明total_fee单位是分后端从数据库查出元金额后必须乘 100 并取整。前端拿到payParams后这样调起支付wx.requestPayment({ timeStamp: payParams.timeStamp, nonceStr: payParams.nonceStr, package: payParams.package, signType: MD5, paySign: payParams.paySign, success: () { wx.navigateTo({ url: /pages/order/detail?id${orderId} }); }, fail: (err) { if (err.errMsg err.errMsg.indexOf(cancel) -1) { // 用户主动取消不提示错误 } else { wx.showToast({ title: 支付失败请重试, icon: none }); } }, });说明fail并不仅仅代表支付失败用户取消、网络中断都会进入这里。一定要通过errMsg区分 cancel 和其他错误否则用户一看弹窗被提示“支付失败”会以为钱扣了但没支付成功产生咨询压力。真实扣款是否成功最终以回调通知为准。4.3 分享到会话与朋友圈open-type 配置下单完成后引导用户分享是点餐小程序提升复购率最简单的手段。在 WXML 里放置button open-typeshare classshare-btn分享给好友/button然后在当前页面 JS 里定义Page({ onShareAppMessage() { return { title: 这家店可以微信点餐免排队, path: /pages/index/index?tableNo${this.data.tableNo}, }; }, onShareTimeline() { return { title: 微信点餐小程序扫码即点, query: tableNo${this.data.tableNo}, }; }, });说明onShareTimeline只在基础库 2.11.0 及以上支持分享朋友圈时不支持自定义图片默认截图页面。path里不要带 http 链接必须是小程序内部页面路径。如果页面里有wx.hideShareMenu需要先移除。另外分享参数tableNo能帮助识别用户来自哪个桌台方便商家核对订单。4.4 用 Charles 抓包定位支付回调里的“疑难杂症”遇到支付回调不更新订单很多开发者无从下手。我一般会先在小程序开发者工具里看wx.requestPayment的返回确认支付是否成功再用 Charles 配置 SSL 代理抓取小程序发起的/api/pay/unifiedorder和回调请求。抓包时注意手机和电脑连接同一个局域网配置好代理后安装 Charles 的 CA 证书。这是微信小程序调试的常规手段能清楚看到请求头、回包和签名内容。如果抓包发现回调请求根本没到后端检查微信支付商户平台的回调 URL如果到了但验签失败重点检查证书序列、nonce_str和sign的排序规则。5. 上线前的安全加固与性能优化我验过这些坑必须提前填5.1 防 SQL 注入和 XSS从参数化查询到 WXML 转义点餐系统涉及真实支付安全底线一定要守住。后端所有数据库操作都使用参数化查询不使用字符串拼接 SQL。前端 WXML 的插值{{}}默认会对字符串进行转义特殊字符不会被解析成 HTML 标签这天然挡掉了一部分反射型 XSS。但富文本场景必须单独处理。5.2 发布流程体验版→审核→正式版的检查点阶段检查项开发版充满电、关闭代理在不同机型上走通下单支付全流程体验版添加体验成员测试微信支付真实回调检查订单通知审核类目选择“餐饮-点餐外卖”截图核心功能提供测试账号正式版观察错误监控查看退款和取消订单日志个人开发者在体验版阶段容易忽略支付回调因为大多数模拟器不支持微信支付。建议把体验版二维码发给同事用 Android 和 iOS 各支付一次一毛钱订单验证回调更新后再取消订单。5.3 从 UEditor 富文本到小程序样式的迁移技巧后台资源里的ueditor.css是富文本编辑器 UEditor 的样式。运营在后台编辑“店铺公告”或“菜品详情”时会写入大量带class的 HTML 片段。小程序端的rich-text组件并不加载外联 CSS导致这些片段渲染出来没有样式。我习惯在后端增加一个清洗中间件用sanitize-html过滤白名单标签和允许的样式npm install sanitize-htmlconst sanitizeHtml require(sanitize-html); function cleanRichText(html) { return sanitizeHtml(html, { allowedTags: [p, br, img, strong, em], allowedAttributes: { img: [src, style] }, allowedStyles: { img: { width: [/^\dpx$/], height: [/^\dpx$/] }, }, }); }说明allowedTags限制只有段落、图片和加粗斜体这类基础标签会保留allowedStyles只允许图片的宽高内联样式其它class和style全部剔除。这样rich-text在小程序端渲染时既不会丢图片也不会被后台的 CSS 污染布局。这段清洗逻辑放在接口层前端不用重复处理。本文还有配套的精品资源点击获取