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