發(fā)構(gòu)建微信小程序點(diǎn)餐系統(tǒng):從環(huán)境初始化到訂單閉環(huán))
簡(jiǎn)介一款基于云技術(shù)實(shí)現(xiàn)的微信小程序點(diǎn)餐系統(tǒng)覆蓋在線點(diǎn)餐、菜單分類(lèi)、訂單生成等常用功能主要面向高校學(xué)生與小程序開(kāi)發(fā)者可作為課程設(shè)計(jì)項(xiàng)目或期末大作業(yè)的完整參考實(shí)現(xiàn)。資源共46個(gè)文件壓縮包僅502KB包含頁(yè)面結(jié)構(gòu)、樣式、邏輯腳本、JSON配置文件以及云函數(shù)與數(shù)據(jù)庫(kù)初始化腳本和用于界面展示的JPG/PNG圖片目錄劃分明確便于按模塊閱讀和二次開(kāi)發(fā)。已有988人學(xué)習(xí)下載。源碼提供完整項(xiàng)目配置與部署腳本下載后可直接導(dǎo)入微信開(kāi)發(fā)者工具運(yùn)行無(wú)需額外修改同時(shí)附有項(xiàng)目說(shuō)明文檔和云函數(shù)上傳腳本可幫助讀者快速理解前后端交互流程落地一個(gè)可演示的點(diǎn)餐小程序從菜單展示到訂單提交完整演示業(yè)務(wù)閉環(huán)適合高分課程設(shè)計(jì)與期末大作業(yè)場(chǎng)景。1. 微信小程序點(diǎn)餐系統(tǒng)不是“把菜單搬上線”云技術(shù)到底替我們省了什么“微信小程序點(diǎn)餐系統(tǒng)”這六個(gè)字放到一起很多人第一反應(yīng)是做個(gè)點(diǎn)菜頁(yè)面、拉個(gè)菜品列表、再寫(xiě)個(gè)購(gòu)物車(chē)就能交差。真正到餐廳里跑過(guò)一遍掃碼點(diǎn)餐就會(huì)發(fā)現(xiàn)難的不是界面而是“下單那一刻之后的事”庫(kù)存會(huì)不會(huì)被超賣(mài)、訂單狀態(tài)誰(shuí)來(lái)更新、用戶不支付就走怎么辦、商戶端怎么實(shí)時(shí)看到新單。這套方案目前比較省力的落地方式是微信小程序端配云技術(shù)也就是云開(kāi)發(fā)——數(shù)據(jù)庫(kù)、鑒權(quán)、云函數(shù)、對(duì)象存儲(chǔ)都替你兜住不用自己買(mǎi)服務(wù)器配域名。這篇按一套可復(fù)現(xiàn)的最小方案來(lái)講先想清楚選型再搭云端數(shù)據(jù)模型然后把下單、支付、接單的狀態(tài)機(jī)跑通最后把分頁(yè)加載和真機(jī)適配這些細(xì)節(jié)補(bǔ)上。適合準(zhǔn)備接小程序私活、做校園食堂訂餐系統(tǒng)、或者幫線下餐廳做數(shù)字化改造的開(kāi)發(fā)者。拿到源碼包之后先別急著跑先把環(huán)境和數(shù)據(jù)模型對(duì)上了后面才不返工。2. 選型階段先想明白為什么是微信小程序云技術(shù)而不是純Web或自建后端2.1 小程序端只做三件事渲染、交互、調(diào)云端點(diǎn)餐場(chǎng)景最核心的訴求是“到店掃碼即用”。用戶不需要下載App也不用記住網(wǎng)址微信掃一下桌臺(tái)碼就進(jìn)入菜品頁(yè)面這個(gè)體驗(yàn)只有小程序能順滑給到。相比公眾號(hào)H5小程序在微信生態(tài)里喚起更快還能拿到更穩(wěn)定的登錄態(tài)。相比純Web方案省掉了域名備案、跨域、H5登錄態(tài)維護(hù)這一堆雜事。小程序端本身不該承擔(dān)太多業(yè)務(wù)邏輯。它只做三件事展示菜品和價(jià)格、維護(hù)本機(jī)購(gòu)物車(chē)、把下單動(dòng)作變成一次云函數(shù)調(diào)用。真正算錢(qián)、扣庫(kù)存、改訂單狀態(tài)的操作必須放到云端。原因是微信小程序的代碼包可以被反編譯你把庫(kù)存判斷和訂單金額計(jì)算放在前端就等于把改價(jià)和超賣(mài)的權(quán)限也交給了用戶。云技術(shù)在這里補(bǔ)位的具體能力有三個(gè)一是數(shù)據(jù)庫(kù)集合存菜品和訂單二是云函數(shù)跑不能暴露給前端的邏輯三是云存儲(chǔ)放菜品圖片。這三塊都由微信云開(kāi)發(fā)托管你不需要關(guān)心服務(wù)器在哪臺(tái)機(jī)器上、磁盤(pán)滿沒(méi)滿、SSL證書(shū)要不要續(xù)期。我一般會(huì)把這個(gè)叫做“最小可信邊界”前端只負(fù)責(zé)表達(dá)云端只負(fù)責(zé)決策。這里要潑一盆冷水如果客戶已經(jīng)有現(xiàn)成的收銀系統(tǒng)、庫(kù)存系統(tǒng)或者需要和供應(yīng)鏈對(duì)賬那云開(kāi)發(fā)不一定是最優(yōu)選。它適合從零起步的門(mén)店不適合做復(fù)雜系統(tǒng)集成。判斷標(biāo)準(zhǔn)就一句話——你的數(shù)據(jù)是不是只在這個(gè)系統(tǒng)里轉(zhuǎn)是就放心用云開(kāi)發(fā)不是就得考慮自建后端。2.2 云開(kāi)發(fā) vs 自建后端這張對(duì)比表幫你做決定很多團(tuán)隊(duì)糾結(jié)“要不要自己寫(xiě)后端”我干脆把判斷維度列成一張表對(duì)著看就行。維度云開(kāi)發(fā)自建后端Node/Java MySQL前期成本按量付費(fèi)個(gè)人項(xiàng)目一個(gè)月幾塊錢(qián)甚至免費(fèi)額度內(nèi)服務(wù)器、域名、備案、運(yùn)維前期就要投入登錄鑒權(quán)wx.cloud.init之后openid直接拿不用寫(xiě)code2session需要自己接微信登錄維護(hù)session和token實(shí)時(shí)推送數(shù)據(jù)庫(kù)watch監(jiān)聽(tīng)改動(dòng)直接推給前端要自建WebSocket或者輪詢接口文件存儲(chǔ)云存儲(chǔ)自帶CDN圖片直接傳要自己接OSS/MinIO再配CDN事務(wù)能力云函數(shù)支持事務(wù)但跨集合復(fù)雜事務(wù)要小心完全可控支持復(fù)雜表關(guān)聯(lián)和事務(wù)適合場(chǎng)景門(mén)店點(diǎn)餐、校園食堂、中小餐飲獨(dú)立系統(tǒng)連鎖總部、已有ERP/POS、需要數(shù)據(jù)倉(cāng)庫(kù)的客戶我給小餐廳做點(diǎn)餐系統(tǒng)絕大多數(shù)情況選云開(kāi)發(fā)。原因很現(xiàn)實(shí)客戶預(yù)算就那么多你讓他在“前端開(kāi)發(fā)”之外再養(yǎng)一個(gè)后端項(xiàng)目周期和成本都翻倍。而校園食堂訂餐這類(lèi)需求用戶量不大、并發(fā)可控、數(shù)據(jù)模型簡(jiǎn)單云開(kāi)發(fā)完全扛得住。一個(gè)常見(jiàn)的反面案例是團(tuán)隊(duì)花兩周寫(xiě)后端接口第四周發(fā)現(xiàn)客戶改需求前后端一起返工云開(kāi)發(fā)模式下改兩個(gè)云函數(shù)就行成本低很多。2.3 數(shù)據(jù)模型設(shè)計(jì)先于寫(xiě)代碼三種集合怎么分點(diǎn)餐系統(tǒng)的數(shù)據(jù)模型比想象中簡(jiǎn)單但字段設(shè)計(jì)錯(cuò)了后期很痛苦。我一般分三個(gè)集合dishes菜品、orders訂單、cart購(gòu)物車(chē)。其中購(gòu)物車(chē)不建議存云端放在小程序本地storage里就行。原因是購(gòu)物車(chē)是即時(shí)交互本地讀寫(xiě)零延遲不消耗云資源換設(shè)備丟購(gòu)物車(chē)在點(diǎn)餐場(chǎng)景里不成立因?yàn)橛脩粲玫氖峭慌_(tái)手機(jī)。dishes集合的字段建議這么定字段類(lèi)型說(shuō)明namestring菜品名稱pricenumber單價(jià)以“分”為單位存儲(chǔ)避免浮點(diǎn)誤差categorystring分類(lèi)名稱如“主食”“飲品”stocknumber庫(kù)存0代表售罄imagestring云存儲(chǔ)文件IDstatusstringon/off下架用sortnumber排序權(quán)重越小越靠前createTimedate上架時(shí)間orders集合要額外注意冗余字段items數(shù)組里把菜品name和price都冗余進(jìn)去。別嫌臟數(shù)據(jù)這是必須的。用戶下單之后你改了菜價(jià)歷史訂單不受影響月底對(duì)賬時(shí)訂單里冗余的快照才是真正的賬本。total金額同理必須存進(jìn)訂單不能靠items實(shí)時(shí)算。訂單狀態(tài)就一個(gè)status字段建議用英文枚舉pending、paid、preparing、completed、cancelled。別用中文也別用數(shù)字后面接支付回調(diào)、定時(shí)任務(wù)時(shí)英文枚舉讀起來(lái)不容易搞錯(cuò)。createTime和updateTime都存數(shù)據(jù)庫(kù)時(shí)間不要信前端傳的時(shí)間戳用戶手機(jī)時(shí)間不準(zhǔn)會(huì)影響對(duì)賬。3. 從零把在線點(diǎn)餐系統(tǒng)跑起來(lái)初始化云端環(huán)境與小程序骨架3.1 云開(kāi)發(fā)環(huán)境初始化與三個(gè)必調(diào)參數(shù)拿到源碼包的第一步是先把云端環(huán)境對(duì)上。打開(kāi)微信開(kāi)發(fā)者工具導(dǎo)入項(xiàng)目后app.js里的wx.cloud.init是第一個(gè)要改的地方。// app.js App({ onLaunch() { wx.cloud.init({ env: your-env-id, // 改成你自己的云環(huán)境ID traceUser: true // 聯(lián)調(diào)時(shí)打開(kāi)可以在控制臺(tái)看到用戶訪問(wèn)記錄 }); this.globalData { openid: }; } });邏輯說(shuō)明wx.cloud.init如果不傳env默認(rèn)用第一個(gè)環(huán)境但很多開(kāi)發(fā)者電腦上有兩三個(gè)環(huán)境環(huán)境一多就串了訂單寫(xiě)進(jìn)測(cè)試環(huán)境里前端看不到。顯式傳環(huán)境ID是最穩(wěn)的做法。traceUser在前端聯(lián)調(diào)時(shí)建議開(kāi)著能看到是哪個(gè)用戶調(diào)用了哪個(gè)云函數(shù)排查問(wèn)題很有用。上線前可以關(guān)掉減少一點(diǎn)點(diǎn)日志量。還需要檢查project.config.json里有沒(méi)有聲明云函數(shù)目錄。沒(méi)有的話在文件里加一行{ cloudfunctionRoot: cloudfunctions/ }參數(shù)說(shuō)明這行配置告訴開(kāi)發(fā)者工具所有云函數(shù)都放在cloudfunctions目錄下。每個(gè)子目錄是獨(dú)立的云函數(shù)右鍵就能上傳部署。如果這行缺失云函數(shù)目錄在工具里就是個(gè)普通文件夾右鍵根本沒(méi)有“上傳并部署”的選項(xiàng)。這是新手最容易卡的第一個(gè)點(diǎn)。3.2 小程序頁(yè)面骨架左右分欄的點(diǎn)餐主頁(yè)頁(yè)面結(jié)構(gòu)我一般分四個(gè)pages/index點(diǎn)餐主頁(yè)、pages/order確認(rèn)下單頁(yè)、pages/orders訂單列表、pages/admin商戶接單頁(yè)。按原生小程序?qū)懖灰匦涂蚣芎竺婵蛻粢臉邮綍r(shí)你才不會(huì)被框架綁住手腳。點(diǎn)餐主頁(yè)的經(jīng)典布局是左側(cè)分類(lèi)、右側(cè)菜品列表!-- pages/index/index.wxml -- view classmenu-container view classcategory-side view wx:for{{categories}} wx:keyname classcategory-item {{currentCategory index ? active : }} bindtapswitchCategory>// cloudfunctions/initDishes/index.js const cloud require(wx-server-sdk); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db cloud.database(); exports.main async () { const dishes [ { name: 招牌牛肉面, price: 2800, category: 主食, stock: 50, sort: 1, status: on, image: cloud://xxx } // 更多菜品按同樣格式補(bǔ) ]; const result []; for (const dish of dishes) { const res await db.collection(dishes).add({ data: dish }); result.push(res._id); } return { added: result.length }; };參數(shù)說(shuō)明env用cloud.DYNAMIC_CURRENT_ENV意思是“云函數(shù)在哪個(gè)環(huán)境運(yùn)行就用哪個(gè)環(huán)境的數(shù)據(jù)庫(kù)”。這個(gè)寫(xiě)法有兩個(gè)好處一是不會(huì)因?yàn)橛簿幋a環(huán)境ID而串環(huán)境二是同一份代碼在開(kāi)發(fā)和生產(chǎn)環(huán)境都能跑不用改。價(jià)格字段用2800表示28元按“分”存整數(shù)避免浮點(diǎn)運(yùn)算誤差。前端拉取菜品列表數(shù)據(jù)庫(kù)查詢。注意limit的默認(rèn)限制。async loadDishes() { const db wx.cloud.database(); const res await db.collection(dishes) .where({ status: on }) .orderBy(sort, asc) .limit(20) .get(); this.setData({ dishList: res.data, currentCategory: 0 }); }參數(shù)說(shuō)明前端直連數(shù)據(jù)庫(kù)查詢單次最多返回20條超過(guò)20條必須用skip分頁(yè)。where篩選上架的菜品orderBy按sort升序排列。這里有個(gè)隱藏坑orderBy的字段必須在云開(kāi)發(fā)控制臺(tái)里建索引否則會(huì)報(bào)錯(cuò)。建索引的方法很簡(jiǎn)單進(jìn)控制臺(tái)數(shù)據(jù)庫(kù)集合點(diǎn)索引管理把sort設(shè)為升序索引。聯(lián)調(diào)時(shí)如果提示“query is not allowed”優(yōu)先查索引。4. 核心業(yè)務(wù)閉環(huán)點(diǎn)餐、下單與接單的狀態(tài)流轉(zhuǎn)4.1 購(gòu)物車(chē)邏輯放在本地為什么我不建議存云端購(gòu)物車(chē)是點(diǎn)餐頁(yè)面到確認(rèn)訂單的中間態(tài)把它放在小程序本地storage里是性能和數(shù)據(jù)成本的雙贏。本地讀寫(xiě)在毫秒級(jí)不產(chǎn)生云函數(shù)調(diào)用用戶體驗(yàn)流暢云端購(gòu)物車(chē)要處理多端同步代碼量和出錯(cuò)的概率都翻倍。// utils/cart.js const KEY CART; function getCart() { return wx.getStorageSync(KEY) || []; } function addToCart(dish, count 1) { const cart getCart(); const exist cart.find(item item.dishId dish._id); if (exist) { exist.count count; } else { cart.push({ dishId: dish._id, name: dish.name, price: dish.price, image: dish.image, count }); } wx.setStorageSync(KEY, cart); }邏輯說(shuō)明購(gòu)物車(chē)?yán)锏膒rice是從dishes集合里帶出來(lái)的冗余副本只在界面展示用。真正下單時(shí)云函數(shù)會(huì)重新從數(shù)據(jù)庫(kù)讀取菜品價(jià)格以數(shù)據(jù)庫(kù)為準(zhǔn)。這樣就算前端storage被人改過(guò)也影響不了訂單金額。這是點(diǎn)餐系統(tǒng)安全的基礎(chǔ)防線不能省。4.2 下單云函數(shù)服務(wù)端核價(jià)、狀態(tài)校驗(yàn)、庫(kù)存前置檢查用戶點(diǎn)“去結(jié)算”后前端把tableNo和items傳給云函數(shù)云函數(shù)只做一件事把訂單合法地寫(xiě)進(jìn)數(shù)據(jù)庫(kù)。// cloudfunctions/createOrder/index.js const cloud require(wx-server-sdk); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db cloud.database(); exports.main async (event) { const { OPENID } cloud.getWXContext(); const { tableNo, items } event; const orderCol db.collection(orders); const dishCol db.collection(dishes); let total 0; const checkedItems []; for (const item of items) { const res await dishCol.doc(item.dishId).get(); const dish res.data; if (!dish || dish.status ! on) { return { code: -1, msg: ${item.name} 已下架 }; } if (dish.stock item.count) { return { code: -2, msg: ${dish.name} 庫(kù)存不足 }; } total dish.price * item.count; checkedItems.push({ dishId: dish._id, name: dish.name, price: dish.price, count: item.count }); } const order { openid: OPENID, tableNo, items: checkedItems, total, status: pending, createTime: db.serverDate(), updateTime: db.serverDate() }; const addRes await orderCol.add({ data: order }); return { code: 0, orderId: addRes._id, total }; };邏輯說(shuō)明cloud.getWXContext()拿到的是微信側(cè)確認(rèn)過(guò)的openid前端無(wú)法偽造這是訂單歸屬用戶的依據(jù)。for循環(huán)里先查菜品再核價(jià)所有金額在后端算前端傳的price直接被忽略。返回的total供前端展示但真正的扣款以云函數(shù)為準(zhǔn)。參數(shù)說(shuō)明這次創(chuàng)建訂單沒(méi)有扣庫(kù)存status是pending因?yàn)橛脩暨€沒(méi)付款。庫(kù)存留在支付回調(diào)里扣這是點(diǎn)餐系統(tǒng)防超賣(mài)的關(guān)鍵決策。db.serverDate()記錄數(shù)據(jù)庫(kù)當(dāng)前時(shí)間避免用戶手機(jī)時(shí)鐘偏差影響超時(shí)判斷。下單之前還有一個(gè)防重復(fù)提交的校驗(yàn)我一般會(huì)在createOrder開(kāi)頭加一段短查詢const recent await orderCol.where({ openid: OPENID, status: pending, createTime: db.command.gt(new Date(Date.now() - 60 * 1000)) }).count(); if (recent.total 0) { return { code: -3, msg: 您有一筆訂單待支付請(qǐng)先處理 }; }參數(shù)說(shuō)明檢查該openid最近一分鐘內(nèi)是否已有pending狀態(tài)的訂單有就直接拒絕。這能擋住用戶連點(diǎn)“提交訂單”產(chǎn)生的重復(fù)單也擋住高頻惡意刷單。前端按鈕loading當(dāng)然要做但云端兜底才是硬保障。4.3 支付回調(diào)、庫(kù)存扣減與商戶實(shí)時(shí)接單創(chuàng)建訂單之后前端調(diào)wx.requestPayment進(jìn)入微信支付。支付成功后微信支付后臺(tái)回調(diào)你的云函數(shù)這才是真正扣庫(kù)存的時(shí)機(jī)。// cloudfunctions/payCallback/index.js const cloud require(wx-server-sdk); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db cloud.database(); exports.main async (event) { const { orderId } event; const orderRes await db.collection(orders).doc(orderId).get(); const order orderRes.data; if (!order || order.status ! pending) { return { code: 0 }; // 重復(fù)回調(diào)直接冪等返回 } const tasks order.items.map(item { return db.collection(dishes).doc(item.dishId).update({ data: { stock: db.command.inc(-item.count) } }); }); await Promise.all(tasks); await db.collection(orders).doc(orderId).update({ data: { status: paid, payTime: db.serverDate(), updateTime: db.serverDate() } }); return { code: 0 }; };參數(shù)說(shuō)明庫(kù)存扣減用db.command.inc(-item.count)這是原子操作多個(gè)并發(fā)回調(diào)同時(shí)執(zhí)行也不會(huì)互相覆蓋。先校驗(yàn)訂單狀態(tài)再扣庫(kù)存回調(diào)重復(fù)觸發(fā)也能安全退出這叫冪等處理。把狀態(tài)改成paid之后訂單就進(jìn)入商戶端的視野了。商戶端實(shí)時(shí)接單我一般用數(shù)據(jù)庫(kù)watch監(jiān)聽(tīng)const db wx.cloud.database(); const watcher db.collection(orders) .where({ status: paid }) .watch({ onChange: snapshot { snapshot.docs.forEach(doc { wx.showToast({ title: 新訂單${doc.tableNo}, icon: none }); }); }, onError: err { console.error(watch error, err); } });邏輯說(shuō)明watch是云開(kāi)發(fā)數(shù)據(jù)庫(kù)的實(shí)時(shí)推送能力比前端定時(shí)輪詢省資源也比“下拉刷新”實(shí)時(shí)。snapshot.docs是本次變更后的訂單列表里面是你監(jiān)聽(tīng)條件下的全部文檔不只是新增的。注意watch只在真機(jī)和開(kāi)發(fā)者工具的一部分場(chǎng)景下穩(wěn)定我建議以真機(jī)測(cè)試為準(zhǔn)。集合權(quán)限要允許watch觸達(dá)否則onError會(huì)一直刷。5. 避坑排查點(diǎn)餐系統(tǒng)最容易翻車(chē)的五個(gè)細(xì)節(jié)5.1 云函數(shù)調(diào)用報(bào)錯(cuò)環(huán)境ID沒(méi)對(duì)上還算是客氣的情況現(xiàn)象點(diǎn)擊提交訂單按鈕后一直轉(zhuǎn)圈最終提示“云函數(shù)調(diào)用失敗”。開(kāi)發(fā)者工具控制臺(tái)有時(shí)只給一句“FunctionName: createOrder not found”。原因有三個(gè)按概率排序一是云函數(shù)目錄沒(méi)有“上傳并部署”到云端本地代碼改了但云端是舊版二是云函數(shù)里cloud.init的env寫(xiě)死成測(cè)試環(huán)境ID線上小程序卻跑在生產(chǎn)環(huán)境三是云函數(shù)依賴的npm包沒(méi)有安裝右鍵上傳時(shí)選了“上傳全部文件”但node_modules缺失。解決先在開(kāi)發(fā)者工具里右鍵云函數(shù)目錄選“上傳并部署云端安裝依賴”再看控制臺(tái)日志。改完代碼一定要重新部署光保存不生效這不是玄學(xué)是部署流程沒(méi)走完。環(huán)境ID一律用cloud.DYNAMIC_CURRENT_ENV從根上規(guī)避多環(huán)境串環(huán)境的問(wèn)題。5.2 菜品列表白屏數(shù)據(jù)庫(kù)權(quán)限把普通用戶擋在門(mén)外現(xiàn)象開(kāi)發(fā)者工具里預(yù)覽菜品正常用體驗(yàn)版二維碼發(fā)給店長(zhǎng)測(cè)試頁(yè)面列表空白控制臺(tái)報(bào)權(quán)限錯(cuò)誤。原因database集合權(quán)限設(shè)成了“僅創(chuàng)建者可讀寫(xiě)”。菜品是管理員通過(guò)控制臺(tái)或initDishes云函數(shù)寫(xiě)入的創(chuàng)建者是管理員本人普通顧客的openid不是創(chuàng)建者被拒絕讀取。解決dishes集合權(quán)限改為“所有用戶可讀僅創(chuàng)建者可寫(xiě)”。orders集合是訂單數(shù)據(jù)不能開(kāi)放所有用戶可讀要按用戶隔離。云開(kāi)發(fā)控制臺(tái)里可以設(shè)置自定義安全規(guī)則{ read: doc.openid auth.openid || auth.openid admin-openid, write: doc.openid auth.openid }參數(shù)說(shuō)明read規(guī)則允許訂單屬主讀取自己的訂單同時(shí)放行管理員openid讀取全部訂單。admin-openid在安全規(guī)則里是明文如果客戶對(duì)安全要求高就讓所有訂單操作都走云函數(shù)不開(kāi)放數(shù)據(jù)庫(kù)直連。我自己的項(xiàng)目一律走云函數(shù)省心。5.3 連點(diǎn)“提交訂單”生成三張重復(fù)單現(xiàn)象用戶手速快或者網(wǎng)絡(luò)慢導(dǎo)致前端loading沒(méi)及時(shí)渲染同一份菜品下了三個(gè)訂單而且都是pending狀態(tài)。原因前端按鈕沒(méi)有做防重后端也沒(méi)有冪等校驗(yàn)。一個(gè)訂單請(qǐng)求進(jìn)來(lái)了三個(gè)并發(fā)請(qǐng)求同時(shí)通過(guò)查詢同時(shí)寫(xiě)入。解決前端button加disabled或loading狀態(tài)這是第一道防線。后端在下單云函數(shù)里加最近一分鐘pending訂單判斷有就拒絕。這里要注意云函數(shù)端的時(shí)間用new Date()取服務(wù)器時(shí)間不要用前端傳的timestamp。兩道防線都加上重復(fù)單基本絕跡。5.4 庫(kù)存被扣光但訂單沒(méi)支付庫(kù)存扣減的時(shí)機(jī)錯(cuò)了現(xiàn)象店里盤(pán)點(diǎn)發(fā)現(xiàn)某道菜庫(kù)存變成0但后臺(tái)沒(méi)有一筆paid狀態(tài)的訂單全是pending。原因創(chuàng)建訂單時(shí)就直接扣庫(kù)存用戶下單不付款庫(kù)存白白占用。等客戶真正來(lái)付款時(shí)反而因?yàn)閹?kù)存不足付不了款。解決把庫(kù)存扣減放到支付回調(diào)里只有支付成功才扣。同時(shí)加一個(gè)云函數(shù)定時(shí)觸發(fā)器每5分鐘掃一次pending超過(guò)15分鐘的訂單把它們置為cancelled。如果業(yè)務(wù)上需要在創(chuàng)建訂單時(shí)鎖庫(kù)存那cancelled時(shí)要用inc(count)回補(bǔ)庫(kù)存邏輯就復(fù)雜了小型點(diǎn)餐系統(tǒng)沒(méi)必要。5.5 真機(jī)預(yù)覽正常體驗(yàn)版發(fā)給別人全部白屏現(xiàn)象自己在開(kāi)發(fā)者工具和真機(jī)預(yù)覽都正常客戶拿體驗(yàn)版二維碼一打開(kāi)頁(yè)面空白或登錄態(tài)丟失。原因最常見(jiàn)是wx.cloud.init里env寫(xiě)空字符串開(kāi)發(fā)者工具自動(dòng)選了第一個(gè)環(huán)境真機(jī)上又找不到匹配環(huán)境。另一個(gè)原因是體驗(yàn)版用了“不校驗(yàn)合法域名”的調(diào)試開(kāi)關(guān)開(kāi)發(fā)時(shí)開(kāi)著沒(méi)事體驗(yàn)版上關(guān)了之后所有非白名單域名請(qǐng)求全部失敗。云開(kāi)發(fā)本身不需要配request合法域名但如果調(diào)了外部接口必須去小程序后臺(tái)把域名加進(jìn)白名單。解決初始化時(shí)顯式寫(xiě)環(huán)境ID。上線前把“不校驗(yàn)合法域名”關(guān)閉用體驗(yàn)版完整走一遍流程。怎么抓包排查把小程序接到抓包工具里看請(qǐng)求有沒(méi)有發(fā)出去、返回什么狀態(tài)碼能分清是前端沒(méi)調(diào)還是后端報(bào)錯(cuò)。不過(guò)云開(kāi)發(fā)的部分請(qǐng)求走微信內(nèi)部通道抓包工具看的是普通https請(qǐng)求最終還是以云開(kāi)發(fā)控制臺(tái)的日志為準(zhǔn)。6. 從能下單選到好用加載更多、導(dǎo)航欄適配與數(shù)據(jù)兜底菜品超過(guò)20條時(shí)列表不能一次渲染完要在滾動(dòng)到底部時(shí)加載下一頁(yè)。這個(gè)功能對(duì)應(yīng)熱搜里常見(jiàn)的“微信小程序頁(yè)面列表加載更多”是點(diǎn)餐列表的核心交互async loadMoreDishes() { const { dishList, page } this.data; const db wx.cloud.database(); const res await db.collection(dishes) .where({ status: on }) .orderBy(sort, asc) .skip(page * 20) .limit(20) .get(); this.setData({ dishList: dishList.concat(res.data), page: page 1 }); if (res.data.length 20) { this.setData({ hasMore: false }); } }邏輯說(shuō)明skiplimit是云開(kāi)發(fā)數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)分頁(yè)方式每頁(yè)20條page從0開(kāi)始。hasMore用于隱藏“加載更多”提示。餐飲菜單一般幾百條而已skip性能完全夠。如果以后菜品上千再考慮用_id游標(biāo)分頁(yè)現(xiàn)在不用提前優(yōu)化。自定義頂部導(dǎo)航欄時(shí)要適配不同機(jī)型的菜單按鈕位置。搜“微信小程序頂部導(dǎo)航欄高度”能翻到一堆文章核心就一句用膠囊位置反推不要寫(xiě)死高度。const { menuButton } wx.getMenuButtonBoundingClientRect(); const { statusBarHeight } wx.getSystemInfoSync(); const navHeight menuButton.top - statusBarHeight menuButton.height; this.setData({ navHeight, statusBarHeight });參數(shù)說(shuō)明menuButton是右上角膠囊按鈕的位置信息不同機(jī)型高度不同。iPhone靈動(dòng)島和安卓狀態(tài)欄的差異都能被這個(gè)函數(shù)覆蓋比你寫(xiě)死64或72像素穩(wěn)得多。數(shù)據(jù)兜底是我交項(xiàng)目前必做的一輪菜品圖片加載失敗時(shí)不能留灰塊要用占位圖頂上去。image組件加binderror事件數(shù)據(jù)里把失敗項(xiàng)的圖片替換成本地占位圖。我自己的習(xí)慣是每次交付前用體驗(yàn)版完整走一遍“點(diǎn)餐—支付—接單—出餐—取消”全流程然后在開(kāi)發(fā)者工具里把Network面板打開(kāi)重點(diǎn)看云函數(shù)調(diào)用時(shí)長(zhǎng)和失敗率。給別人做系統(tǒng)做了幾輪之后有個(gè)教訓(xùn)凡是“先做界面再做后臺(tái)”的后面全要返工先把數(shù)據(jù)模型和訂單狀態(tài)機(jī)定死界面隨便改都不慌。點(diǎn)餐系統(tǒng)這個(gè)方向技術(shù)難度不大真正值錢(qián)的部分是對(duì)業(yè)務(wù)細(xì)節(jié)的理解和那些不試幾次發(fā)現(xiàn)不了的邊界坑。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取