企业官网建设流程全解析

简介：「微信小程序-餐饮点餐外卖-源代码 开箱即用」面向餐饮商家与微信小程序开发者，提供一套可直接运行和二次定制的餐饮点餐外卖解决方案，覆盖在线点餐、外卖配送、叫号排队与微信支付等核心业务场景，适合用于课程实训、毕业设计或小型餐饮项目的快速搭建。压缩包共 521 个文件、约 833KB，以 137 个 js 业务逻辑脚本、108 个 wxss 样式文件、104 个 json 配置、102 个 wxml 页面结构和 44 个 wxs 脚本为主，另含少量 png 图片资源，整体体积轻量、目录组织完整。已有 2331 人学习，说明其在同类小程序源码中具有一定参考价值。读者可从中了解菜品展示、购物车与订单确认、配送范围与费用计算、远程取号与等待人数同步、支付验证与退款、用户登录及商家订单管理等模块的实现思路，并借助数据统计相关代码理解运营分析如何落地，适合作为学习微信小程序开发实践或按自身需求裁剪定制的代码基础。

1. 开箱即用这四个字，在餐饮点餐小程序里到底意味着什么

扫码点菜这件事，卡住人的从来不是页面长什么样，而是规格、库存、起送价、支付回调这几处对不上。一份标着「微信小程序-餐饮点餐外卖-源代码 开箱即用」的包，价值就在于它把菜单、规格、购物车、下单、支付回调、配送这几段最容易翻车的主链路先串通了。它是一套原生小程序前端加一套轻量接口服务，堂食扫码和外卖配送两条线都在里面，附带建表脚本和演示数据。适合想快速跑通一个餐饮点餐商城验证业务的人，也适合在已有门店系统上补一个前端入口；不适合指望解压就能上线收钱的人，这点后面会讲清楚。

2. 目录与环境：三层结构、五个配置项，先把本地跑通

拿到这类包，最忌讳的动作是直接双击打开某个.js从头读到尾。正确的顺序是先看目录分层，再看配置在哪，最后才看业务代码。因为「开箱即用」的包通常已经把环境变量抽到了配置文件里，你改三个值就能跑，改错一个值就会白屏。

2.1 三层目录：小程序端、接口服务、数据脚本

一份结构清晰的餐饮点餐小程序源码，目录基本跑不出这三层。先用文件树确认它是不是这个形状，再决定要不要动手：

app.json这个文件值得单独说两句。很多人编译后看到首页一片空白，原因就是pages数组第一项指向了一个分包里的页面，或者被人改成了某个测试页。餐饮点餐场景里，堂食的启动页通常是扫码落地页（带桌号参数），外卖的启动页是门店选择页，这两者在打包时如果要合并，tabBar 的pagePath必须和pages里的路径逐字一致，少一个斜杠都不行。

2.2 五个配置项：AppID、baseUrl、数据库四件套

前端只改一处，后端只改一处。前端统一入口一般长这样：

// miniprogram/utils/config.js const ENV = 'dev'; // dev | prod，切环境只改这一行，别去业务代码里找 baseUrl const CONFIG = { dev: { // 本地调试：开发者工具里要勾上「不校验合法域名」，否则请求直接被拦 baseUrl: 'http://127.0.0.1:3000/api', }, prod: { // 线上必须是 HTTPS，且域名要在小程序后台的 request 合法域名里配好 baseUrl: 'https://your-domain.com/api', }, }; module.exports = CONFIG[ENV];

这段代码的作用是把环境切换收敛到一个常量上。参数说明：ENV只允许dev和prod两个值；baseUrl后面不带尾斜杠，拼接时统一在 request 封装里补/，不然会出现//api这种双斜杠导致部分服务端 404。判断自己有没有改对，看一眼request.js里有没有别处又写死了一个域名，这种包里经常残留一两处旧地址。

后端是常规的 Node 服务，数据库四件套从.env走：

# 1. 装依赖 cd server && npm install # 2. 复制环境变量模板，然后手改这四项 cp .env.example .env # DB_HOST=127.0.0.1 # DB_USER=root # DB_PASS=你的密码 # DB_NAME=order_demo # 3. 建表 + 灌演示数据，顺序不能反 mysql -u root -p < db/schema.sql mysql -u root -p order_demo < db/seed.sql # 4. 起服务，默认监听 3000 npm run dev

参数说明：db/schema.sql只负责结构，db/seed.sql只负责数据，两者分开的好处是重灌数据时不用连表一起删。注意seed.sql里如果带了CREATE DATABASE，第二条命令的库名就要和它对齐，不然会出现「建表成功但插数据报 Unknown database」。判断服务起没起，直接浏览器打开http://127.0.0.1:3000/api/store/1001，能返回一段门店 JSON 就说明接口和数据库都通了。

2.3 初始化数据：把菜品、规格、门店三张表灌对

规格表是这类项目里最容易被写坏的地方。有些包图省事，把「大份/中辣」和价格拼成一个字符串塞进菜品表，后面要做库存、要做加料、要做口味备注就全得推倒重来。合格的建表方式是把规格组合拆成独立的 SKU 行，价格挂在 SKU 上：

CREATE TABLE `dish_sku` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `dish_id` BIGINT UNSIGNED NOT NULL COMMENT '所属菜品 ID', `spec_json` JSON NOT NULL COMMENT '规格组合，如 {"份量":"大份","辣度":"中辣"}', `price` INT NOT NULL COMMENT '单价，单位：分', `stock` INT NOT NULL DEFAULT 999, `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1 上架 0 下架', PRIMARY KEY (`id`), KEY `idx_dish` (`dish_id`) COMMENT '按菜品查规格走这个索引' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 同一道菜的两个规格组合，各自独立定价 INSERT INTO `dish_sku` (`dish_id`, `spec_json`, `price`) VALUES (1, '{"份量":"小份","辣度":"微辣"}', 1800), (1, '{"份量":"大份","辣度":"微辣"}', 2800);

参数说明：price用「分」为单位存整数，是为了彻底避开浮点误差，1.8 元存 180，前端展示时统一除以 100 并toFixed(2)。spec_json用 JSON 类型而不是拼接字符串，是为了后面能用JSON_EXTRACT按口味做筛选统计。stock给默认值 999 是为了演示数据不用一个个填，真上线前要把不限库存和零库存区分开，否则卖光了还在接单。

数据灌完，先人工核对三件事：门店表的lat/lng是不是真实坐标（外卖配送判定全靠它）、菜品表的image是不是 https 地址、dish_sku有没有菜品的所有组合。这三项只要有一样不对，后面调试就会把时间浪费在「明明是代码问题」的错觉里。

3. 点餐主链路拆解：规格匹配、购物车、幂等下单、状态机四段代码

一条完整的点餐链路是：进店 → 选菜选规格 → 加购物车 → 确认页校验（起送价、配送范围、营业时段）→ 下单 → 支付 → 出餐。这条链路上有四段代码值得逐行看，因为它们决定了这个包是「能演示」还是「能改」。

3.1 规格匹配：价格不能在前端算死

规格弹层的交互逻辑是「每选一项规格，就匹配到一个 SKU」。前端要做的只是匹配，不是定价：

// miniprogram/pages/dish/detail.js // 把规格对象转成可比较的字符串，键排序保证 {a,b} 和 {b,a} 视为同一种组合 function specKey(spec) { return Object.keys(spec).sort().map(k => `${k}:${spec[k]}`).join('|'); } Page({ data: { dish: null, specGroups: [], selected: {}, matchedSku: null }, onLoad(options) { this.dishId = options.id; this.loadDish(); }, // 菜品和 SKU 列表都由后端一次返回，前端不做笛卡尔积 async loadDish() { const res = await request.get(`/dish/${this.dishId}`); this.skuList = res.skuList; // [{ spec:{份量:'大份'}, price:2800, stock:99, id:12 }] this.setData({ dish: res.dish, specGroups: res.specGroups }); }, onSpecTap(e) { const { group, value } = e.currentTarget.dataset; const selected = { ...this.data.selected, [group]: value }; // 只有选全所有规格组，才可能唯一命中一个 SKU const complete = this.data.specGroups.every(g => selected[g.name]); const key = complete ? specKey(selected) : ''; const hit = complete ? this.skuList.find(s => specKey(s.spec) === key) : null; this.setData({ selected, matchedSku: hit || null }); }, });

逻辑说明：specKey是整段代码的核心，它把{份量:'大份',辣度:'中辣'}变成固定顺序的字符串，避免因为对象键顺序不同导致匹配失败——这是规格弹层「点了没反应」最常见的原因。参数说明：specGroups是规格组定义，形如[{name:'份量',options:['小份','大份']}]；skuList是后端算好的全组合，前端只读。

需要强调的是，前端算出来的matchedSku.price只用来显示。下单时后端必须用 SKU ID 重新查一次价格，不然改个请求体就能一块钱买套餐，这是这类源码在正式使用前必须补的第一道校验。

3.2 购物车：按门店隔离，key 带版本号

购物车不要只往wx.setStorageSync里丢一个数组。餐饮场景有几个现实约束：用户可能切换门店、可能改了几次数据结构、可能加了一堆菜之后小程序被系统回收。用「版本号 + 门店 ID」做两层 key 会省掉很多麻烦：

// miniprogram/utils/cart.js const KEY = 'cart_v1'; // 结构变了就升到 cart_v2，老缓存自然失效，不用写迁移代码 function getAll() { return wx.getStorageSync(KEY) || {}; } function getCart(storeId) { return getAll()[storeId] || []; // 按门店隔离，切门店不会串单 } function saveCart(storeId, list) { const all = getAll(); all[storeId] = list; wx.setStorageSync(KEY, all); } // 加菜：同一 SKU 累加数量，不同 SKU 追加一行 function addItem(storeId, sku) { const list = getCart(storeId); const hit = list.find(i => i.skuId === sku.skuId); if (hit) hit.count += 1; else list.push({ skuId: sku.skuId, name: sku.name, price: sku.price, count: 1 }); saveCart(storeId, list); return list; } module.exports = { getCart, saveCart, addItem };

逻辑说明：只用单一 key 存全部门店的购物车，结构是{ storeId: [item, ...] }，好处是切门店时空数组天然存在，不需要额外初始化。参数说明：skuId必须是 SKU 主键而不是菜品 ID，否则两种规格会合并成一行；price存快照值只用来展示，结算时依然以后端为准。

注意单个 key 的存储上限是 1MB，正常点餐不会超，但如果有人把菜品图片的 base64 塞进购物车，几下就爆了。购物车里只存 ID、名称、价格、数量四个字段，别存整个菜品对象。

3.3 下单幂等：一个 client_token 挡住重复订单

用户手抖点两下提交、网络卡顿后重试、支付完返回又点了一次——这三种情况在真实场景里天天发生。防重复下单最省事的办法不是加锁，是加唯一索引：

-- 幂等的第一道防线：数据库层面直接不允许同一个 token 落两行 ALTER TABLE `orders` ADD UNIQUE KEY `uk_client_token` (`client_token`);

// server/routes/order.js router.post('/order/create', async (req, res) => { const { storeId, items, clientToken } = req.body; // clientToken 由小程序端在进入确认页时生成一次：Date.now() + 随机串 // 同一次确认动作复用同一个 token，用户返回再进才会重新生成 try { const orderId = await db.tx(async t => { const [id] = await t.insert('orders', { client_token: clientToken, store_id: storeId, status: 0, // 0 = 待支付 }); // 价格一律从库里取，前端传的 price 一个字都不信 const skus = await t.query( 'SELECT id, price, stock FROM dish_sku WHERE id IN (?)', [items.map(i => i.skuId)] ); const priceMap = new Map(skus.map(s => [s.id, s.price])); let total = 0; for (const it of items) { const price = priceMap.get(it.skuId); if (!price) throw new Error('SKU_NOT_FOUND'); total += price * it.count; } await t.query('UPDATE orders SET total = ? WHERE id = ?', [total, id]); // 明细表写入略，字段为 order_id / sku_id / count / price 快照 return id; }); res.json({ code: 0, data: { orderId } }); } catch (e) { if (e.code === 'ER_DUP_ENTRY') { // 撞唯一键说明是重复提交，把上一次的订单查出来原样返回，前端体验无感 const old = await db.query('SELECT id FROM orders WHERE client_token = ?', [clientToken]); return res.json({ code: 0, data: { orderId: old[0].id } }); } res.json({ code: 500, msg: e.message }); } });

逻辑说明：整段代码依赖「唯一索引 + 捕获重复键错误」这一个组合，比先查后插的写法可靠得多——先查后插在两个请求同时到达时依然会插两行。参数说明：clientToken的生成时机很关键，必须是「进入订单确认页时生成一次」，而不是「点击提交时生成」，后者等于没做幂等，每次点击都是新 token。判断有没有生效，最简单的办法是按 F12 在 Network 里把同一请求重放一次，两次返回的orderId必须一致。

3.4 订单状态机：别用一个 UPDATE 改到底

订单状态如果允许随便改，早晚会出现「已完成的单被改成退款中」。加一个白名单状态机，成本极低：

// server/utils/orderStatus.js const FLOW = { 0: ['1', '9'], 1: ['2', '9'], 2: ['3'], 3: [], 9: [], }; function canTransfer(from, to) { return (FLOW[from] || []).includes(String(to)); }

逻辑说明：from和to统一转成字符串比较，是因为数据库里是 TINYINT、前端传来的是字符串，不统一就会出现「明明允许流转却判断失败」。参数说明：FLOW里没列出的状态一律拒绝流转，包括传了不存在的状态值。每次更新状态前先canTransfer，再执行带WHERE status = 当前状态的 UPDATE 并检查影响行数，两步都过才认账。

4. 堂食与外卖的参数差异：起送价、配送半径、运费、支付回调怎么配

同一个菜品列表，堂食和外卖走的是两套规则。堂食看桌号、看翻台、看是否支持多人同桌加菜；外卖看起送价、看配送范围、看打包费、看预计送达时间。这类餐饮点餐商城源码通常已经把这部分拆成了门店配置，问题在于很多人没找到那个配置对象，直接去改业务代码里的魔法数字。

4.1 门店配置：把写死的数字挪到一个对象里

先找到门店配置。如果没有，就自己建一个，这是改造这类源码性价比最高的一步：

{ "storeId": 1001, "storeName": "示例门店", "businessHours": [["10:30", "14:00"], ["17:00", "21:30"]], "dineIn": { "enabled": true, "tableMode": "scan", "minAmount": 0 }, "delivery": { "enabled": true, "minAmount": 2000, "packingFee": 200, "rangeType": "radius", "radiusMeter": 3000, "baseFee": 500, "freeOverAmount": 8000 } }

参数说明：金额字段全部以「分」为单位，minAmount: 2000是 20 元起送；businessHours用二维数组表示多个营业时段，午市晚市分开，中间歇业时段的判定就是「不落在任何区间内」；packingFee是打包费，单列而不是揉进运费里，因为对账时这两笔钱的归属方不一样。freeOverAmount: 8000表示满 80 元免配送费，但打包费通常不免，这一点各家规则不同，配置里要能拆开。

这段配置的落地要点是：堂食和外卖必须有独立的开关。周末只做堂食、雨天只做外卖，这类临时调整如果能通过改配置完成，就不用发版。我一般会把门店配置缓存到小程序端本地，进页面先读缓存再异步更新，避免弱网时进店转圈。

4.2 配送范围与运费：圆形半径判定，先把直线距离算对

最简的配送范围是「以门店为圆心、半径 R 米」。别被「半径」两个字骗了，很多人把直径填进去，结果配送范围缩了一半：

// 两点间球面距离，单位米 function distanceMeter(lat1, lng1, lat2, lng2) { const R = 6371000; // 地球平均半径，米 const rad = d => (d * Math.PI) / 180; const dLat = rad(lat2 - lat1); const dLng = rad(lng2 - lng1); const a = Math.sin(dLat / 2) ** 2 + Math.cos(rad(lat1)) * Math.cos(rad(lat2)) * Math.sin(dLng / 2) ** 2; return 2 * R * Math.asin(Math.sqrt(a)); } function calcDelivery(store, userLoc, cartTotal) { const { delivery } = store; if (!delivery.enabled) return { ok: false, reason: 'DELIVERY_CLOSED' }; const d = distanceMeter(store.lat, store.lng, userLoc.lat, userLoc.lng); if (d > delivery.radiusMeter) return { ok: false, reason: 'OUT_OF_RANGE', distance: Math.round(d) }; // 打包费照收，配送费按门槛免 const shipFee = cartTotal >= delivery.freeOverAmount ? 0 : delivery.baseFee; return { ok: true, distance: Math.round(d), fee: shipFee + delivery.packingFee }; }

逻辑说明：先判配送开关，再判距离，最后算钱，顺序不能乱——先算钱再判范围，超出范围的单会显示一个「看似合理」的运费然后在下单时被拒，用户体验很差。参数说明：radiusMeter是半径；userLoc必须来自用户主动授权的定位，定位失败时要给「手动选地址」的兜底，别直接弹窗拒绝。

这里有个必须说清的边界：直线距离不等于骑手路径距离。3 公里直线范围在密集城区可能实际要跑 4.5 公里。稳妥做法是直线距离先粗筛，超出的直接拒；临界区域（比如半径的 85% 以上）再调路径规划接口二次判断。演示阶段只用直线距离没问题，真接单之前一定要补这一步。

4.3 支付回调：金额比对、重复通知、返回格式三个坑

支付回调是整个链路里最容易出事的一段，因为它不受你控制——渠道会重试、会乱序、会在你服务重启时刚好打进来：

// server/routes/pay.js router.post('/pay/notify', async (req, res) => { // 1. 先验签，验不过直接返回失败，绝不写库 if (!verifySign(req.headers, req.rawBody)) return res.send('FAIL'); const { outTradeNo, totalFee, tradeState } = parseNotify(req.body); if (tradeState !== 'SUCCESS') return res.send('SUCCESS'); // 非成功状态也要应答，否则会被反复重试 const rows = await db.query('SELECT id, total, status FROM orders WHERE order_no = ?', [outTradeNo]); if (!rows.length) return res.send('FAIL'); // 2. 金额比对：回调金额必须等于订单金额，防止改价下单 if (rows[0].total !== totalFee) return res.send('FAIL'); // 3. 幂等：只有「待支付」才允许改成「已支付」，影响行数为 0 说明已处理过 const ret = await db.query( 'UPDATE orders SET status = 1, paid_at = NOW() WHERE id = ? AND status = 0', [rows[0].id] ); if (ret.affectedRows === 0) return res.send('SUCCESS'); res.send('SUCCESS'); });

逻辑说明：整段代码的顺序是「验签 → 状态判断 → 金额比对 → 条件更新」，任何一步不过都直接返回，不做多余写库。参数说明：outTradeNo是你自己生成的订单号，不是渠道流水号，两者都要存但查询用前者；totalFee单位必须和订单表一致（分），不一致就会永远比对失败。

最重要的一条：支付结果以回调为准，不要用小程序端wx.requestPayment的 success 回调去改订单状态。用户付完款直接杀进程，前端回调根本不会触发，但钱已经扣了。

5. 常见问题排查：五个把「开箱即用」变成「开箱即炸」的地方

下面这五条，是按「拿到包之后最可能依次撞上」的顺序排的。每条都按现象、原因、解决写，照着对一遍能省掉大半天。

5.1 编译通过，首页一片白

现象：开发者工具编译无报错，模拟器里只有导航栏，页面内容全空，Console 里一条Page is not found或干脆什么都没有。

原因：app.json的pages数组第一项指向了分包内页面，或者被人改成了某个测试页；另一种是tabBar.list里的pagePath没有在pages中注册，工具会静默跳过。

解决：打开app.json，把pages第一项改成实际存在的首页路径（通常是pages/index/index），逐个核对tabBar.list的pagePath与pages是否完全一致。改完记得清一次编译缓存，工具对app.json的改动偶尔不会热更新。

5.2 菜品列表全是灰色占位块

现象：列表能渲染，文字正常，图片位置全是灰块或裂图图标。

原因：seed.sql里的图片地址是/images/xxx.jpg这种相对路径，指向的是服务器磁盘目录，小程序端根本访问不到；或者用了 http 地址，被安全策略拦掉。

解决：图片统一换成 https 的对象存储地址；演示阶段图省事，可以把图片放进miniprogram/assets/用相对路径引用。改完顺手在image标签上加mode="aspectFill"和默认图，不然图裂了页面会塌。

5.3 前端提示下单成功，后台订单列表查不到

现象：点提交后跳转到订单详情，但商家后台一条记录都没有。

原因：前端baseUrl还指向dev，后端.env里连的却是另一套库；或者请求里storeId传了 0/undefined，后端过滤时直接丢掉了。

解决：先看服务端有没有收到/api/order/create的 access log。没有就是前端地址问题，有就是业务过滤问题。把数据库的慢查询日志打开，确认 INSERT 到底落没落库，再核对.env里的DB_NAME和你手动导入数据用的库名是不是同一个。

5.4 同一笔订单被处理两次，库存扣了双份

现象：订单表出现两条已支付记录，或者一笔订单的库存扣减量是实际的两倍。

原因：支付渠道的回调会重试，代码里只判断了「订单是否存在」，没判断「订单当前状态」。

解决：把更新语句改成带状态条件的形式（WHERE status = 0），用affectedRows判断是不是第一次处理；库存扣减同样要放进这个条件分支里。如果历史数据已经脏了，按order_no分组找重复，人工核一次。

5.5 开发者工具能跑，真机或体验版打不开

现象：工具里勾了「不校验合法域名」一切正常，真机扫码后白屏，或者报request:fail。

原因：那个勾选项只对开发者工具生效，真机走的是真实校验；此外体验版要求服务端域名完成备案并配置到小程序的合法域名列表里。

解决：在小程序后台把request、uploadFile、downloadFile三类合法域名都配齐，全部 https；开发阶段真机调试用「真机调试」模式，别用体验版去验证接口连通性。

6. 上线前空跑一遍：五个接口 + 一次重复提交，比读十遍代码管用

改完之后别急着提审。我会用一个 shell 脚本把主链路按顺序打一遍，全部通过才算完。脚本不用写得漂亮，能跑就行：

#!/bin/bash # scripts/smoke.sh —— 上线前按顺序打这五个接口 BASE=https://your-domain.com/api # 1. 门店配置能取到，且配送开关是开的 curl -s $BASE/store/1001 | jq '.data.delivery' # 2. 菜品列表非空 curl -s "$BASE/dish/list?storeId=1001" | jq '.data.list | length' # 3. 购物车校验：金额由后端算，看是不是 2 份的钱 curl -s -X POST $BASE/cart/check -H "Content-Type: application/json" \ -d '{"storeId":1001,"items":[{"skuId":1,"count":2}]}' | jq '.data.total' # 4. 下单 curl -s -X POST $BASE/order/create -H "Content-Type: application/json" \ -d '{"storeId":1001,"clientToken":"smoke-001","items":[{"skuId":1,"count":2}]}' | jq '.data.orderId' # 5. 同一个 clientToken 再下一次，返回的 orderId 必须和第 4 步完全一致 curl -s -X POST $BASE/order/create -H "Content-Type: application/json" \ -d '{"storeId":1001,"clientToken":"smoke-001","items":[{"skuId":1,"count":2}]}' | jq '.data.orderId'

第 4 步和第 5 步的输出必须一模一样，这是幂等是否真的生效的唯一证据。只要这两个数字不同，就说明唯一索引没加上，或者clientToken生成位置写错了。另外第 3 步的金额要拿计算器手算一遍，别默认后端算对了。

几个我会固定检查的项，列成表方便对照：

顺便说一句，中间那个clientToken我一般会在脚本里用固定值，而不是随机生成——固定值才能验证幂等，随机的等于每次都测「首次下单」。测完记得把订单表里这条测试单删掉，不然演示时后台列表第一行永远是 smoke 测试单。

从那以后我每次拿到这种标着「开箱即用」的源码包，都是先跑一遍空跑脚本，再去谈改需求；先证明主链路是通的，再看代码写得怎么样，顺序反过来就会把时间全花在怀疑自己上。希望帮到你。

本文还有配套的精品资源，点击获取