简介这套“微信小程序-餐饮点餐外卖-开箱即用”源码包面向餐饮行业开发者与中小商家提供可直接上手改造的点餐、外卖小程序方案。内容围绕菜单浏览、在线下单、外卖配送、叫号排队、微信支付、用户账号、订单状态推送及经营数据分析等环节展开适合希望快速搭建餐饮数字化服务、学习小程序前后端协作的初中级开发者。压缩包共521个文件以137个js业务逻辑与接口脚本、108个wxss样式、104个json配置、102个wxml页面结构及44个wxs辅助模块为主另含少量png图片资源整体约839KB结构紧凑便于按页面与功能模块检索。已有315人学习下载可作为餐饮小程序原型参考。读者可从中了解点餐商城从页面布局、业务逻辑到支付与订单流转的组织方式并借鉴外卖、排队、配送管理等场景的实现思路用于课程实践、毕业设计或二次开发。1. 开箱即用的餐饮点餐外卖小程序一份源码包到底省掉哪几周餐饮点餐外卖这类微信小程序是外包单和自研团队里重复造轮子最多的品类之一。菜单分类、规格加料、购物车、下单结算、多门店隔离这套东西每做一个新客户就要重写一遍写到最后大家都在抄自己上一版。这份「开箱即用」的餐饮点餐外卖小程序源码包把这条主链路预先搭好拿到手改的是菜品数据和门店参数不是从零搭骨架。它适合三类人接餐饮类外包、想压缩工期的独立开发者手上有个门店要快速上线的小团队以及拿它当学习样板、想看清小程序点餐业务数据模型怎么设计的初中级前端。后续几章按「拆骨架 → 跑主链路 → 调 SKU 参数 → 排查上线坑 → 交付验证」的顺序走每一步都能落到具体文件和参数上。2. 拆包先看骨架目录结构、技术栈与五张核心数据表拿到一个陌生的小程序包我一般不会先打开页面代码而是先看目录和app.json。页面代码决定「长什么样」目录结构和数据模型决定「能不能改得动」。很多号称开箱即用的包翻车就翻在数据模型上菜品、规格、订单全塞在一个集合里加个「大杯/中杯」就要动五个文件。所以这一章先把骨架认清楚。2.1 目录约定先认命名规则再动第一行代码包内常见的组织方式是把小程序端和云函数端分开放小程序端再按pages分包。下面这套结构是餐饮点餐项目里最通用的一种如果你拿到的包目录名略有差异按功能对应过去看就行。# 项目根目录结构按包内通用约定整理 ├── cloudfunctions/ # 云函数端下单、支付回调、库存 │ ├── createOrder/ # 创建订单含事务扣库存 │ ├── payNotify/ # 支付结果回调幂等处理 │ └── getMenu/ # 菜单聚合查询分类菜品 ├── miniprogram/ │ ├── app.js # 全局云环境初始化、登录态 │ ├── app.json # 页面注册、分包、tabBar │ ├── app.wxss # 全局样式变量 │ ├── pages/ │ │ ├── index/ # 首页门店选择 推荐位 │ │ ├── menu/ # 点餐页左分类右菜品 │ │ ├── cart/ # 购物车也可以是弹层 │ │ ├── confirm/ # 确认订单地址、备注、优惠 │ │ └── order/ # 订单列表与详情 │ ├── components/ │ │ ├── sku-picker/ # 规格选择弹层 │ │ └── dish-card/ # 菜品卡片 │ └── utils/ │ ├── cart.js # 购物车增删改查 │ └── price.js # 价格计算分单位 └── project.config.json # 开发者工具项目配置认目录时重点看三处app.json里的subpackages有没有配分包这直接决定后面能不能塞下图片资源utils/price.js存不存在存在说明作者至少想过价格精度问题cloudfunctions/下有没有payNotify有的话说明支付链路是完整走通的不是只做了个下单按钮。我见过不少包把购物车逻辑直接写在cart.js页面里页面一多就要复制粘贴。这套结构把cart.js抽到utils页面只负责渲染这是能二次开发的前提。你改的时候也守这条线能进utils的别进页面。2.2 技术栈与运行环境原生小程序加云开发的最小闭环这类餐饮点餐包主流是原生小程序 云开发好处是不用自己买服务器、不用配 HTTPS 证书、不用管登录态换取wx.cloud.callFunction一把梭。也有部分包给的是原生前端 自建 Node 后端的组合那样就多一层request封装和域名配置。判断方法很简单看app.js里有没有wx.cloud.init。有就是云开发版没有就看utils/request.js里的 baseURL。云开发版跑起来要做的动作只有三步缺一步都白屏// miniprogram/app.js —— 云环境初始化env 必须换成你自己的环境 ID App({ onLaunch() { if (!wx.cloud) { console.error(基础库版本过低请调高调试基础库); return; } wx.cloud.init({ env: your-env-id, // 云开发控制台 - 设置 - 环境ID traceUser: true // 记录访问用户便于排查 }); }, globalData: { storeId: , // 当前选中门店贯穿全站 cart: [] // 购物车内存副本落盘见 utils/cart.js } });这段代码里env是最容易翻车的参数。包内一般留的是作者自己的环境 ID直接跑会报「环境不存在」或者查出来一堆别人的测试数据。改成自己云开发控制台里的环境 ID 之后还要去云开发数据库里手动建集合、导初始数据否则菜单页是空的。traceUser建议保持true它会把用户访问记到云开发后台出问题能对着日志回溯。生产环境如果对日志量敏感可以关但调试阶段别关。环境变量之外还有一处要改project.config.json里的appid。用测试号跑能看界面但云开发和支付都调不通必须换成自己的小程序 AppID。这一步很多人卡住以为代码有问题其实是 AppID 不匹配。提示先在小程序后台把云开发开通再回开发者工具编译。顺序反了会出现「云开发未开通」的报错重启工具也修不好。2.3 数据模型五张集合撑起一整套点餐业务餐饮点餐的数据模型抽象到最后就是五张表门店、分类、菜品、规格、订单。少一张就要在代码里硬编码补多一张就是过度设计。下面这张对照表是我拆过几个同类包之后总结的字段约定你手上的包字段名可能不同但语义一定对得上。集合名关键字段说明stores_id、name、address、businessHours、status门店表status控制营业/打烊categoriesstoreId、name、sort分类表按sort升序排dishesstoreId、categoryId、name、price、image、stock、skuGroups菜品主表价格单位用分orders_id、openid、storeId、items、totalFee、status、createTime订单主表items是快照数组couponsstoreId、type、threshold、amount、expireAt优惠券可选包内不一定带两个设计细节值得单独说。第一price存整数分不存小数。浮点数在 JavaScript 里做加法会出现0.1 0.2 0.30000000000000004这种玄学结果一份 18.9 元的套餐加两份 2.5 元的加料结算时可能出现 23.900000000000002。存分、显示时再除 100是餐饮项目里最省心的做法。第二orders.items存的是下单那一刻的菜品快照不是dishId引用。菜单改价、下架之后历史订单还得能正常显示引用式设计做不到这一点。拆包时看到items里只有 ID基本可以判定这个包做完之后还得补一轮快照逻辑。数据模型认清楚之后后面改 SKU、加门店、跑结算都是在改这五张表之间的关联不会再迷路。3. 跑通点餐主链路菜品列表、购物车、下单结算三处改法骨架认完接下来是把一条完整的点餐链路跑通进店 → 选分类 → 加购物车 → 选规格 → 确认订单 → 提交。这条链路里最容易出问题的不是 UI是三处状态同步分类切换时的列表刷新、购物车的持久化、下单时的库存与金额校验。这一章按顺序拆。3.1 菜品列表与分类联动一次查询拆成两段更稳餐饮点餐页的经典布局是左边分类竖排、右边菜品列表点左边右边滚滚右边左边高亮。这套联动有两种实现一次性把全部分类和菜品查回来本地算或者按分类分页查。前者简单但门店菜品一多就卡后者省内存但切分类有延迟。我一般会取中间方案分类一次性查回来量小菜品按分类懒加载并缓存。代码如下。// miniprogram/pages/menu/menu.js const db wx.cloud.database() Page({ data: { categories: [], // 左侧分类 dishesMap: {}, // { categoryId: [菜品...] }按分类缓存 activeCatId: , loading: false }, async onLoad() { const storeId getApp().globalData.storeId // 分类量小一次拉全按 sort 升序 const { data: cats } await db.collection(categories) .where({ storeId }) .orderBy(sort, asc) .get() this.setData({ categories: cats, activeCatId: cats[0]?._id || }) if (cats.length) this.loadDishes(cats[0]._id) }, // 切分类命中缓存直接渲染未命中才发请求 onCategoryTap(e) { const catId e.currentTarget.dataset.id this.setData({ activeCatId: catId }) if (this.data.dishesMap[catId]) return this.loadDishes(catId) }, async loadDishes(categoryId) { if (this.data.loading) return this.setData({ loading: true }) const storeId getApp().globalData.storeId // 只取列表需要的字段避免把 skuGroups 等大字段一起拖下来 const { data } await db.collection(dishes) .where({ storeId, categoryId, onSale: true }) .field({ name: true, price: true, image: true, stock: true, desc: true }) .orderBy(sort, asc) .limit(50) .get() this.setData({ [dishesMap.${categoryId}]: data, loading: false }) } })要点在.field()这一行。菜品的skuGroups字段可能很长三四个规格组、每组几个选项列表页根本用不到一起查回来会让首屏白屏时间肉眼可见地变长。列表只取展示字段规格在点「选规格」时再单独查一次详情这是拆包后我几乎必改的一处。limit(50)是保护值单分类菜品超过 50 个的餐饮店极少真要超了就上滚动分页。loading锁防止用户快速连点分类导致请求乱序返回顺序和点击顺序不一致是这类页面最常见的显示错乱原因。3.2 购物车内存态 本地存储双写别只做一半购物车这块包的作者通常做了一半页面里用globalData.cart存用户退出小程序再进来购物车空了。餐饮场景里这很致命用户点了一半去接电话回来得重选。完整做法是内存态和本地存储双写读的时候优先读本地写的时候两边都写。// miniprogram/utils/cart.js const KEY cart_v1 // 带版本号结构变更时直接换 key避免读到旧结构 // 一条购物车项{ dishId, name, price, count, skuText, skuKey } function read() { return wx.getStorageSync(KEY) || [] } function write(list) { wx.setStorageSync(KEY, list) getApp().globalData.cart list // 同步内存副本 } // 加菜同菜品同规格合并数量不同规格算两条 function add(item) { const list read() const key ${item.dishId}_${item.skuKey || default} const idx list.findIndex(i ${i.dishId}_${i.skuKey || default} key) if (idx -1) { list[idx].count item.count } else { list.push({ ...item, count: item.count || 1 }) } write(list) return list } // 改数量减到 0 直接移除别留 count0 的脏数据 function updateCount(dishId, skuKey, delta) { const list read() const idx list.findIndex(i i.dishId dishId (i.skuKey || default) (skuKey || default)) if (idx -1) return list list[idx].count delta if (list[idx].count 0) list.splice(idx, 1) write(list) return list } module.exports { read, write, add, updateCount }sukKey是这一版购物车能不能用的关键。同一道「牛肉面」大碗微辣和小碗不辣必须是两条记录否则用户改规格的时候只能删了重加。skuKey的生成规则放到下一章讲这里先记住它是「规格组合的稳定指纹」。KEY带版本号_v1是老项目留下的习惯其实是血泪经验某次改了购物车项结构老用户本地还存着旧格式读出来skuKey是undefined合并逻辑全错购物车数字乱跳。换了 key 之后旧数据自动失效代价只是用户购物车清空一次比线上报错强。注意write()里同步globalData.cart是为了让 tabBar 角标和购物车页面能立刻拿到最新数量。只在页面onShow里读一次本地存储的做法在弹层加菜时角标不会变。3.3 下单结算事务、库存与幂等三件事必须一次做对下单是整条链路里唯一「错了要赔钱」的环节。常见翻车方式下单成功但库存没扣两个人同时买最后一份或者网络抖动用户连点两下生成两笔订单。正确的做法是把「校验库存 扣库存 写订单」放进一个事务并且用一个客户端生成的幂等键挡住重复提交。// cloudfunctions/createOrder/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const _ db.command exports.main async (event) { const { openid } cloud.getWXContext() const { storeId, items, remark, requestId } event // requestId 由前端生成一次重试时沿用同一个用于幂等 if (!requestId) return { code: 400, msg: missing requestId } // 幂等检查同一 requestId 已存在则直接返回旧订单 const dup await db.collection(orders).where({ openid, requestId }).get() if (dup.data.length) return { code: 0, orderId: dup.data[0]._id } const transaction await db.startTransaction() try { let totalFee 0 for (const it of items) { const dish await transaction.collection(dishes).doc(it.dishId).get() if (!dish.data || dish.data.stock it.count) { throw new Error(库存不足: ${it.name}) } // 服务端重算单价不信任前端传的 price totalFee dish.data.price * it.count await transaction.collection(dishes).doc(it.dishId).update({ data: { stock: _.inc(-it.count) } }) } const res await transaction.collection(orders).add({ data: { openid, storeId, requestId, items, totalFee, remark: remark || , status: unpaid, createTime: db.serverDate() } }) await transaction.commit() return { code: 0, orderId: res._id, totalFee } } catch (err) { await transaction.rollback() return { code: 500, msg: err.message } } }三处细节决定这单能不能扛住真实流量。totalFee在服务端重算前端传上来的price一律不用。小程序端的 JS 是可以被改的把 18.9 改成 0.01 不是什么高深操作价格校验必须在服务端做。requestId由前端在进入确认页时生成一次Date.now() 随机串即可提交失败重试时沿用同一个值。这样即使用户连点或者网络重发库里的orders也只会有一条。拆包时如果看到下单函数里没有类似字段这处一定要补。事务内的循环await会按菜品条数串行执行订单里菜品超过十几个时耗时明显。常见做法是先把所有菜品一次性批量查回来再在事务内批量update。云开发的单事务操作条数有上限拆单批次要自己控制别一次塞几十条进去。前端调用侧要注意拿到orderId之后立刻redirectTo到订单详情或支付页别用navigateTo否则用户在返回时还能回到确认页重复提交。4. 多门店与规格 SKU 参数设计把「大杯微辣加料」变成可算的数据点餐业务真正难的不是页面是规格。一杯奶茶可能有杯型、温度、糖度、加料四组规格加料还能多选价格各不相同。如果规格只是拼成一句「大杯/微辣/加珍珠」的字符串存进订单后面退款、改价、统计数据全得靠人肉解析。这一章把 SKU 拆到能算钱的粒度。4.1 规格组与选项用两层结构描述任意复杂度不管规格多复杂数据结构就是两层规格组skuGroups和组内选项options。组与组之间是笛卡尔积关系组内单选或多选由multiple控制。// dishes 文档里 skuGroups 字段的推荐结构 { _id: dish_1001, name: 招牌牛肉面, price: 2200, // 基础价单位分 stock: 100, skuGroups: [ { key: size, name: 份量, multiple: false, // 单选 required: true, options: [ { key: big, name: 大碗, delta: 300 }, { key: small, name: 小碗, delta: 0 } ] }, { key: spicy, name: 辣度, multiple: false, required: true, options: [ { key: none, name: 不辣, delta: 0 }, { key: mid, name: 微辣, delta: 0 }, { key: hot, name: 特辣, delta: 0 } ] }, { key: extra, name: 加料, multiple: true, // 多选 required: false, maxSelect: 3, options: [ { key: egg, name: 卤蛋, delta: 200 }, { key: beef, name: 加牛肉, delta: 800 }, { key: noodle, name: 加面, delta: 300 } ] } ] }delta用分存增量不是绝对价。这样基础价改动时不用同步改所有选项也方便做「第二份半价」这类活动时只动基础价。multiplemaxSelect覆盖了加料场景单选组不用maxSelect。required控制必选前端弹层在用户没选必选项时禁用「加入购物车」。这套结构的好处是新增一个规格组不用改任何代码改数据即可。我给一个门店加「是否加香菜」的时候就是在数据库里多推一个组进去前端弹层自动多一行。4.2 SKU 指纹与价格计算一次计算多处复用购物车合并、订单快照、后厨小票都要用同一个规格描述和同一个价格。所以选完规格之后立刻算两样东西skuKey稳定指纹和skuText展示文本。// miniprogram/utils/price.js // 生成规格指纹按 groupKey 排序拼接保证同组合不同选择顺序结果一致 function buildSkuKey(selection) { // selection: { size: [big], spicy: [mid], extra: [egg,beef] } return Object.keys(selection).sort() .map(g ${g}:${[...selection[g]].sort().join(,)}) .join(|) } // 生成展示文本大碗/微辣/卤蛋加牛肉 function buildSkuText(selection, groups) { const parts [] groups.forEach(g { const picked selection[g.key] || [] const names picked.map(k g.options.find(o o.key k)?.name).filter(Boolean) if (names.length) parts.push(names.join()) }) return parts.join(/) } // 计算单价基础价 所有选中选项的 delta 之和 function calcUnitPrice(basePrice, selection, groups) { let total basePrice groups.forEach(g { const picked selection[g.key] || [] picked.forEach(k { const opt g.options.find(o o.key k) if (opt) total opt.delta }) }) return total // 单位分 } module.exports { buildSkuKey, buildSkuText, calcUnitPrice }buildSkuKey里对groupKey和选项都做了sort()这行看着不起眼作用是让{size:[big], extra:[egg,beef]}和{extra:[beef,egg], size:[big]}生成同一个 key。没有这个排序用户同样的选择会生成不同 key购物车里就出现两条内容一样的记录数量还不合并。这个坑我在别的项目里踩过排查了半天。calcUnitPrice全部用整数分相加没有浮点误差。展示的时候统一走一个fen2yuan(fen)把分转成「22.00」这种字符串别在页面里各处(price/100).toFixed(2)散落各处迟早有一处忘了toFixed。skuText落进订单快照后厨打印、客服查单、退款对账都靠它。字符串是给人看的skuKey是给程序算的两个都要存缺一个后面难受。4.3 多门店隔离storeId 是所有查询的第一道门槛餐饮连锁场景下一个用户可能今天在 A 店点、明天在 B 店点两家的菜单、价格、营业时间都不一样。所有业务集合都带storeId所有查询都以storeId开头这是硬约束。初始化链路一般是进入小程序 → 定位或手动选门店 → 写进globalData.storeId和本地存储 → 后续所有查询带上它。// miniprogram/pages/index/index.js —— 选门店后落库 const db wx.cloud.database() async function selectStore(storeId) { const { data } await db.collection(stores).doc(storeId).get() if (data.status ! open) { wx.showToast({ title: 门店休息中, icon: none }) return } getApp().globalData.storeId storeId wx.setStorageSync(storeId, storeId) // 下次进来直接复用 wx.switchTab({ url: /pages/menu/menu }) }stores.status的判断要放在选店环节而不是等用户点完菜提交时才拦。选完一整单才被告知「门店休息中」用户当场卸载这是体验事故。购物车也要跟着门店走。用户从 A 店切到 B 店时A 店的购物车不能带过去因为两家的菜品 ID 和价格体系不同。稳妥做法是购物车按storeId分键存储切换门店时提示一次「切换后当前购物车将清空」比悄悄合并导致价格算错要好。云开发数据库的权限设置也要配合dishes、categories、stores设成「所有用户可读仅创建者可写」orders设成「仅创建者可读写」。这个配置在云开发控制台里点不在代码里常常被漏掉漏了就是订单数据互相可见。拆包时看到还停留在默认权限第一件事就是去改。5. 上线前的排查清单五个把 demo 拖成事故的坑源码包在开发者工具里跑通和能上线是两回事。开发者工具不校验证书、不卡包体积、网络永远稳定真实环境全反过来。这一章列五个我在同类项目里反复遇到的坑每个都按「现象 → 原因 → 解决」写照着对一遍能省掉上线当晚的返工。5.1 坑一购物车总价和确认页差几分钱现象购物车页面显示 45.90进确认页变成 45.89或者反过来多一分。原因两处用了不同的计算方式。购物车页面直接对浮点元累加确认页走了分单位整数计算或者优惠券抵扣时一边用了toFixed一边没用。餐饮订单里优惠券、满减、配送费混在一起算浮点误差会被放大。解决全链路只用「分」这一个单位。所有金额字段以分为单位存储和传输展示层统一走一个格式化函数。优惠券的amount也用分抵扣时totalFee Math.max(0, totalFee - couponAmount)。确认页和购物车页调同一个calcCartTotal(cartList)不许各写一份。注意满减门槛判断也要用分totalFee threshold别写成totalFee/100 50除完再比又是一次浮点运算。5.2 坑二下单成功但库存没动超卖被投诉现象某个菜品只剩 3 份两个用户同时下单各买 2 份两单都成功最后做不出来。原因库存校验在客户端做或者云函数里是「先 get 再 update」的非事务写法。中间有几十毫秒窗口两个请求读到同样的库存值 3都判断通过。解决校验和扣减放在同一个事务里用_.inc(-count)做原子自减并在事务内先判断stock count。事务外的预校验只用来给前端提示「快没了」不能作为最终判断依据。5.3 坑三菜品图片全部白屏开发者工具里却正常现象真机预览或体验版里菜品图全是灰块开发者工具里显示正常。原因image的 src 是外部图床地址小程序对网络图片有域名白名单要求没配的域名真机直接拒绝加载。云存储的cloud://地址不受这个限制所以如果包内图片走的是云存储通常不会有这问题一旦作者把图片换成了 CDN 或图床地址就必须去后台配downloadFile合法域名。解决优先把图片迁到云存储fileID直接用管理成本最低。确实要用外部图床去小程序后台「开发管理 → 服务器域名」里把downloadFile域名补上配完重新编译体验版才生效。另外图片尽量走modeaspectFill加固定宽高避免列表加载时高度跳变这个细节在弱网下特别明显。5.4 坑四加完几个页面就传不上去了提示包体积超限现象改到一半开发者工具上传时报主包超限。原因菜品图片、字体图标、没用到的组件全塞在主包里。餐饮项目图片多一个assets目录随便就几百 KB主包 2MB 这条线很容易撞上撞上之后连预览都困难。解决把订单页、个人中心这些非首屏页面拆进subpackages图片资源放云存储或分包内app.json里配preloadRule让分包在空闲时预下载。图标能用字体就不用切图app.wxss里没引用的样式块删掉。改完在开发者工具的「详情 → 基本信息」里能看到实时体积别等到上传才检查。5.5 坑五同一个订单被扣了两次款现象用户反馈付了一次钱订单列表里出现两条已支付记录或者支付成功后状态还是未支付。原因微信支付的异步通知会重复推送这是正常机制不是 bug。如果payNotify云函数收到通知就直接status paid并给用户加积分或发券重复推送就会重复执行。反过来如果回调里做了耗时操作超时了平台还会继续重推。解决回调处理必须幂等。用一个payLog记录transactionId处理前先查这个 ID 有没有出现过出现过直接返回成功。订单状态更新用「只有当前状态是 unpaid 才更新」的条件更新where({ _id, status: unpaid }).update(...)靠数据库的条件匹配挡住第二次写入。提示上线前用沙箱环境手动触发三次同一个回调确认订单状态和积分只变更一次这个测试五分钟能做完能省掉后面一堆客诉。6. 二次开发交付验证一条验收路径加一张配置收敛表改完代码别急着交付。餐饮点餐这类项目最容易在「改了一处、崩了另一处」上翻车尤其是规格和价格这两块改动会顺着购物车、确认页、订单快照一路传导。下面这条验收路径我每次交付前都会走一遍覆盖了绝大多数断裂点。先清一次本地存储模拟新用户首次进入选门店 → 切三个分类 → 各加一个菜品 → 其中一个选多规格加料 → 进购物车改数量、删一项 → 进确认页看总价 → 提交订单 → 不支付退出 → 再进小程序看购物车是否为空、订单列表是否有未支付单。这条路径能一次性暴露购物车持久化、价格一致性、订单状态三类问题比逐个页面点要快得多。然后做一次并发验证。让两个账号同时买最后一份限量菜品看是不是只有一个成功。这个测试在云开发控制台里可以直接调云函数模拟不用真开两台手机。失败的那单应该收到「库存不足」而不是静默成功。配置项这块我习惯在交付前把散落各处的硬编码收敛到一张表里交给接手的人。常见的必改项如下。配置项位置说明appidproject.config.json换成目标小程序 AppIDenvapp.js的wx.cloud.init云开发环境 ID图片域名小程序后台服务器域名非云存储图片必须配downloadFile数据库权限云开发控制台orders仅创建者可读写支付商户号payNotify云函数环境变量不要写死在代码里营业时间/门店状态stores集合上线前逐店核对把这张表交给接手方比口头交代靠谱。我吃过一次亏项目交付三个月后对方要换门店找不到storeId在哪儿配最后把整个库翻了一遍。从那以后我每次交付都强制走一遍「配置收敛 验收路径」这两步配置项全部列在文档第一页验收路径写成可执行的步骤清单。二次开发时还有个小技巧utils/price.js里的calcUnitPrice和buildSkuKey是纯函数不依赖wx对象可以直接抽出来写单测。规格计算这种逻辑靠手点页面测是测不全的写十个用例把单选、多选、超上限、不选必选项都覆盖一遍比反复重启开发者工具省时间。这份餐饮点餐外卖小程序源码包的价值不在于页面画得多好看而在于它把门店、分类、菜品、规格、订单这五张表和一条完整主链路预先搭好了你接手的是骨架而不是白纸。按上面的路径走一遍改配置、调规格、验价格基本一两天能跑出一个能交付的版本。需要这份源码包的话按项目名去找对应的获取入口就行拿到手先从app.json和utils/price.js这两个文件看起能少走不少弯路。希望帮到你。本文还有配套的精品资源点击获取