簡(jiǎn)介隨著共享經(jīng)濟(jì)向垂直場(chǎng)景滲透棋牌室、茶室、臺(tái)球室等無(wú)人值守空間的預(yù)約管理成為創(chuàng)業(yè)者和開(kāi)發(fā)者關(guān)注的熱點(diǎn)。微信小程序作為輕量級(jí)入口結(jié)合JavaScript實(shí)現(xiàn)完整的預(yù)約、支付、押金、結(jié)算和智能門(mén)鎖聯(lián)動(dòng)是構(gòu)建這類(lèi)系統(tǒng)的核心路徑。理解預(yù)約系統(tǒng)背后的業(yè)務(wù)模型與訂單狀態(tài)機(jī)是技術(shù)落地的關(guān)鍵。從場(chǎng)地展示、場(chǎng)次篩選、微信支付到自動(dòng)結(jié)算每一個(gè)環(huán)節(jié)都需嚴(yán)格處理資金安全與狀態(tài)一致性。本文基于一套生產(chǎn)環(huán)境運(yùn)行的共享空間預(yù)約小程序源碼拆解項(xiàng)目策劃、數(shù)據(jù)庫(kù)設(shè)計(jì)、核心代碼實(shí)現(xiàn)以及踩坑記錄幫助你快速掌握從零搭建一套可復(fù)用的共享棋牌室預(yù)約系統(tǒng)。 共享棋牌室、茶室、臺(tái)球室這類(lèi)生意最近兩年在二三線城市冒出來(lái)特別多。一個(gè)老板手里三五套房源擺上麻將桌、茶臺(tái)或者臺(tái)球案不請(qǐng)服務(wù)員靠一套預(yù)約系統(tǒng)自動(dòng)運(yùn)轉(zhuǎn)。我去年幫朋友從零做過(guò)一版這樣的微信小程序用的就是原生JavaScript加微信小程序框架整套源碼到現(xiàn)在還在線上跑著。這篇文章把當(dāng)時(shí)的設(shè)計(jì)思路、核心代碼、踩坑記錄全部攤開(kāi)來(lái)講如果你正打算做類(lèi)似的共享空間預(yù)約系統(tǒng)可以直接抄作業(yè)。這篇內(nèi)容適合三類(lèi)人看一是準(zhǔn)備進(jìn)入共享空間賽道的創(chuàng)業(yè)者你需要知道系統(tǒng)應(yīng)該有哪些模塊、資金怎么流轉(zhuǎn)二是接私活或做外包的開(kāi)發(fā)者這里有一套完整可落地的源碼設(shè)計(jì)思路三是正在學(xué)微信小程序開(kāi)發(fā)的學(xué)生或轉(zhuǎn)行者把整個(gè)業(yè)務(wù)流程走一遍比刷一百個(gè)登錄 Demo 都有用。1. 共享空間小程序的前期策劃與業(yè)務(wù)模型設(shè)計(jì)1.1 需求本質(zhì)不是做預(yù)約是做無(wú)人值守的資產(chǎn)管理很多人第一次接觸棋牌室小程序以為核心是“預(yù)約”這個(gè)理解是有偏差的。預(yù)約只是表面動(dòng)作真正的核心是無(wú)人值守狀態(tài)下的資產(chǎn)流轉(zhuǎn)管理。你想一下一間棋牌室一天能接多少單工作日中午到晚上周末全天滿打滿算也就五六單。如果還要前臺(tái)登記、收押金、計(jì)時(shí)、催場(chǎng)、結(jié)算人工成本直接吃掉利潤(rùn)。所以小程序要解決的是把“接待-入座-計(jì)時(shí)-結(jié)算-離場(chǎng)”這五個(gè)環(huán)節(jié)全部自動(dòng)化。具體到功能上就拆成了這樣幾個(gè)模塊房間展示與時(shí)段篩選用戶按小時(shí)或按場(chǎng)次購(gòu)買(mǎi)押金收取與退還有效期管理到店掃碼或密碼開(kāi)門(mén)聯(lián)動(dòng)智能門(mén)鎖使用中計(jì)時(shí)超時(shí)自動(dòng)續(xù)費(fèi)或斷店提醒訂單完成后自動(dòng)結(jié)算押金原路退回這套邏輯放在棋牌室、茶室、臺(tái)球室完全通用因?yàn)樗鼈兊暮诵纳虡I(yè)模式都一樣——按時(shí)間出租空間。棋牌室按小時(shí)計(jì)費(fèi)茶室按包廂計(jì)費(fèi)臺(tái)球室按臺(tái)桌計(jì)費(fèi)只是在計(jì)費(fèi)規(guī)則上有細(xì)微差別而這些差別可以通過(guò)后臺(tái)配置解決。1.2 技術(shù)選型為什么用原生小程序而不是 uni-app 或 Web 套殼技術(shù)選型是動(dòng)手前最糾結(jié)的地方。我見(jiàn)過(guò)有人用 uni-app 做也見(jiàn)過(guò)用 H5 套殼的但最終我都建議用原生微信小程序加 JavaScript 開(kāi)發(fā)。先說(shuō) uni-app。它確實(shí)能一套代碼多端復(fù)用但問(wèn)題是共享空間這個(gè)場(chǎng)景里有大量硬件聯(lián)動(dòng)比如智能門(mén)鎖、掃碼設(shè)備、打印機(jī)。這些設(shè)備的廠商 SDK 往往只提供微信小程序原生插件uni-app 走一層封裝就可能出現(xiàn)兼容問(wèn)題。你做一個(gè)棋牌室項(xiàng)目客戶只要求微信端跑通沒(méi)必要為了“未來(lái)可能做 App”去承擔(dān)多端框架的兼容成本。再說(shuō) Web 套殼。很多外包團(tuán)隊(duì)圖省事用 WebView 套一個(gè) H5 頁(yè)面本質(zhì)上是個(gè)網(wǎng)頁(yè)。但微信小程序里WebView 的支付能力受限無(wú)法直接調(diào)用 wx.requestPayment定位、藍(lán)牙、掃碼等原生能力也都要通過(guò)各種橋接層去調(diào)鏈路長(zhǎng)了故障點(diǎn)就多。共享空間的核心體驗(yàn)是“從打開(kāi)微信到開(kāi)門(mén)鎖全程不超過(guò)30秒”任何多余的網(wǎng)絡(luò)請(qǐng)求和加載等待都會(huì)毀掉體驗(yàn)。原生 JavaScript 開(kāi)發(fā)的好處是微信所有 API 直接調(diào)用、調(diào)試工具成熟、 community 生態(tài)豐富、遇到問(wèn)題搜一下就能找到答案。壞處當(dāng)然也有代碼不能復(fù)用到其他平臺(tái)但如果你只做微信生態(tài)這點(diǎn)代價(jià)完全可以接受。1.3 業(yè)務(wù)模型押金、計(jì)費(fèi)、退款的完整資金閉環(huán)這塊是我認(rèn)為最有價(jià)值的部分因?yàn)樗鼪Q定了整個(gè)系統(tǒng)的復(fù)雜度。很多人第一次做共享空間小程序把訂單做完就以為結(jié)束了實(shí)際上一碰押金和超時(shí)結(jié)算就會(huì)出問(wèn)題。我設(shè)計(jì)的資金流是這樣的用戶下單時(shí)支付“租金 押金”押金不是單獨(dú)再走一次支付而是合并成同一次支付但后臺(tái)把金額拆分記錄使用結(jié)束后后臺(tái)自動(dòng)計(jì)算實(shí)際費(fèi)用基礎(chǔ)租金 超時(shí)費(fèi)用 - 優(yōu)惠原訂單的租金部分按實(shí)際費(fèi)用多退少補(bǔ)押金全額原路退回這里有個(gè)關(guān)鍵點(diǎn)微信支付的退款接口是按訂單號(hào)操作的。所以我的做法是用戶支付時(shí)生成一個(gè)“支付單”支付單里包含租金和押金兩個(gè)金額字段。結(jié)束時(shí)先從支付單退押金再根據(jù)實(shí)際租金差異走退款或二次支付。聽(tīng)起來(lái)簡(jiǎn)單但實(shí)際開(kāi)發(fā)中有個(gè)坑如果用戶頻繁取消訂單或者中途改時(shí)間你的支付單狀態(tài)管理稍微混亂就會(huì)出現(xiàn)退了押金但租金算錯(cuò)或者押金重復(fù)退的 bug。所以我在訂單表里專(zhuān)門(mén)加了一個(gè)refund_status字段每次退款操作前先判斷這個(gè)字段確保同一筆押金只退一次。2. 小程序端核心功能拆解與實(shí)現(xiàn)思路2.1 登錄授權(quán)與用戶體系搭建不存密碼只用微信身份微信小程序的登錄不像傳統(tǒng)網(wǎng)站不需要用戶名密碼。它基于微信的 openid 機(jī)制用戶在授權(quán)后前端通過(guò)wx.login()獲取臨時(shí) code后端拿著 code 去微信接口換 openid 和 session_key。這里有一個(gè)經(jīng)驗(yàn)建議不要用按鈕主動(dòng)彈授權(quán)框。微信官方早就調(diào)整了策略用戶點(diǎn)擊授權(quán)按鈕時(shí)如果中途取消再次彈出會(huì)被攔截。我現(xiàn)在的做法是用戶進(jìn)入小程序先不彈任何授權(quán)框只有點(diǎn)擊“預(yù)約下單”時(shí)才觸發(fā)wx.getUserProfile把頭像昵稱(chēng)順帶拿一下。這樣授權(quán)成功率幾乎達(dá)到100%。用戶登錄后的狀態(tài)管理我采用 token 機(jī)制。后端拿到 openid 后生成一個(gè)自定義 token比如 uuid存到 Redis 或數(shù)據(jù)庫(kù)里設(shè)置有效期7天。小程序端把 token 存到wx.setStorageSync后續(xù)所有請(qǐng)求頭部帶上Authorization: Bearer ${token}。這樣用戶每次打開(kāi)小程序先檢查本地 token 是否過(guò)期如果沒(méi)過(guò)期就直接用過(guò)期了才靜默重新登錄。這段代碼是登錄的核心// 小程序端app.js 里的登錄方法 login() { return new Promise((resolve, reject) { wx.login({ success: async (res) { if (res.code) { try { const loginRes await request({ url: /api/user/login, method: POST, data: { code: res.code } }) wx.setStorageSync(token, loginRes.data.token) resolve(loginRes.data) } catch (err) { reject(err) } } else { reject(new Error(微信登錄失敗)) } } }) }) }后端的接口邏輯是收到 code 后調(diào)用https://api.weixin.qq.com/sns/jscode2session用 appid 和 secret 換 openid。注意這個(gè) secret 絕對(duì)不能放前端必須在后端請(qǐng)求。2.2 場(chǎng)地瀏覽、時(shí)段篩選與預(yù)約下單場(chǎng)地列表頁(yè)是用戶第一眼看到的東西也是轉(zhuǎn)化率的關(guān)鍵。我做的列表頁(yè)包含場(chǎng)地封面圖、名稱(chēng)、位置距離、按小時(shí)計(jì)費(fèi)的價(jià)格、當(dāng)前狀態(tài)空閑/使用中/清潔中。這里有個(gè)產(chǎn)品細(xì)節(jié)狀態(tài)要實(shí)時(shí)刷新。你想想用戶看到某個(gè)包間顯示空閑點(diǎn)進(jìn)去正要下單結(jié)果發(fā)現(xiàn)剛被另一個(gè)人訂了這種體驗(yàn)非常糟糕。我的方案是用小程序的wx.connectSocket建立 WebSocket 長(zhǎng)連接或者更輕量的做法是前端每30秒輪詢一次場(chǎng)地狀態(tài)接口?？紤]到棋牌室這種低頻場(chǎng)景30秒輪詢足夠了不需要上 WebSocket 增加復(fù)雜度。時(shí)段篩選是個(gè)技術(shù)細(xì)節(jié)。你不可能讓用戶自由選任意時(shí)間段那樣后臺(tái)排場(chǎng)沒(méi)法管理。我的做法是固定場(chǎng)次——午餐場(chǎng)10:00-14:00、下午場(chǎng)14:00-18:00、晚場(chǎng)18:00-22:00、夜場(chǎng)22:00-02:00用戶按場(chǎng)次下單。這樣好處有兩個(gè)一是庫(kù)存管理簡(jiǎn)單一場(chǎng)一個(gè)狀態(tài)二是時(shí)間邊界清晰到點(diǎn)提醒下一個(gè)用戶入場(chǎng)避免糾紛。下單請(qǐng)求的核心代碼// 提交預(yù)約訂單 submitOrder(roomId, sessionId) { const token wx.getStorageSync(token) return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}/api/order/create, method: POST, header: { Authorization: Bearer ${token} }, data: { roomId, sessionId, orderType: reserve, couponId: this.data.couponId || null }, success: (res) { if (res.data.code 0) { // 創(chuàng)建訂單成功返回訂單號(hào)和預(yù)付金額 resolve(res.data.data) } else { wx.showToast({ title: res.data.msg, icon: none }) reject(res.data) } }, fail: (err) reject(err) }) }) }2.3 支付、押金與自動(dòng)結(jié)算邏輯把規(guī)則說(shuō)清楚支付在小程序里就是調(diào)wx.requestPayment但這個(gè)接口要求訂單必須先經(jīng)過(guò)微信支付統(tǒng)一下單接口。我的后端流程是收到下單請(qǐng)求后生成業(yè)務(wù)訂單狀態(tài)“待支付”調(diào)用微信支付統(tǒng)一下單 API獲取支付參數(shù)前端拿到參數(shù)調(diào)起收銀臺(tái)用戶完成支付微信服務(wù)器回調(diào)后端通知支付成功前端收到成功回調(diào)后輪詢訂單狀態(tài)跳轉(zhuǎn)“預(yù)約成功”頁(yè)這里有個(gè)必須注意的坑微信支付的wx.requestPayment必須由用戶點(diǎn)擊觸發(fā)不能在異步回調(diào)里調(diào)。如果你在頁(yè)面 onLoad 里直接調(diào)支付微信會(huì)報(bào)錯(cuò)“invalid request”。所以我在預(yù)約頁(yè)加了一個(gè)“確認(rèn)支付”按鈕用戶點(diǎn)擊后先加載支付參數(shù)參數(shù)就緒后再調(diào)起支付。自動(dòng)結(jié)算這塊我用了一個(gè)定時(shí)任務(wù)來(lái)實(shí)現(xiàn)。每個(gè)訂單的結(jié)束時(shí)間到了以后服務(wù)端邏輯開(kāi)始執(zhí)行// Node.js 定時(shí)結(jié)算服務(wù)偽代碼 async function autoSettle() { const expiredOrders await Order.find({ status: using, endTime: { $lte: new Date() } }) for (let order of expiredOrders) { const room await Room.findById(order.roomId) const actualHours calculateHours(order.startTime, order.endTime) const actualAmount actualHours * room.hourlyPrice const deposit order.deposit // 多退少補(bǔ) if (actualAmount order.paidAmount) { // 發(fā)起二次收款 await wxPay.charge(order.openid, actualAmount - order.paidAmount) } else if (actualAmount order.paidAmount) { // 退款差額 await wxPay.refund(order.paymentNo, order.paidAmount - actualAmount) } // 退押金 await wxPay.refund(order.depositNo, deposit) order.status completed await order.save() } }注意這段代碼只是業(yè)務(wù)示意正式的線上項(xiàng)目里退款和二次收款需要重試機(jī)制還要記錄每次調(diào)用的返回碼方便排查問(wèn)題。2.4 掃碼開(kāi)門(mén)與硬件聯(lián)動(dòng)的實(shí)現(xiàn)方案單獨(dú)把這個(gè)拎出來(lái)講是因?yàn)檫@是整個(gè)系統(tǒng)里坑最多的地方。共享空間常用的門(mén)鎖方案有三種智能門(mén)鎖藍(lán)牙/密碼、智能電控鎖通電開(kāi)鎖、人臉識(shí)別門(mén)禁。棋牌室和茶室用得最多的是密碼鎖加電控鎖的組合。我采用的是“密碼鎖 掃碼觸發(fā)后臺(tái)開(kāi)鎖”的方案。用戶預(yù)約成功后小程序上會(huì)顯示一個(gè)“開(kāi)門(mén)”按鈕點(diǎn)擊后調(diào)用后端接口后端通過(guò)物聯(lián)網(wǎng)模塊發(fā)送開(kāi)鎖指令到指定的電控鎖。這個(gè)設(shè)計(jì)里要思考的是安全邊界。你不能讓用戶拿著小程序在店外直接開(kāi)門(mén)那等于給小偷發(fā)了鑰匙。所以我的處理是開(kāi)門(mén)接口做了兩個(gè)校驗(yàn)——第一用戶距離門(mén)店必須小于200米通過(guò)wx.getLocation獲取坐標(biāo)后端算地球兩點(diǎn)距離第二訂單狀態(tài)必須是“已支付”且在有效時(shí)段內(nèi)。如果不想依賴電控鎖的物聯(lián)網(wǎng)模塊可以用更輕量的方式在門(mén)鎖上貼一個(gè)二維碼用戶掃碼后跳轉(zhuǎn)到微信小程序的開(kāi)門(mén)頁(yè)面頁(yè)面讀取 URL 參數(shù)中的房間號(hào)再調(diào)用開(kāi)門(mén)接口。這種方式不需要額外設(shè)備只需要門(mén)鎖本身支持遠(yuǎn)程開(kāi)鎖或密碼下發(fā)。3. 后臺(tái)管理與數(shù)據(jù)庫(kù)設(shè)計(jì)3.1 數(shù)據(jù)庫(kù)表結(jié)構(gòu)從房間到訂單的完整鏈路整個(gè)系統(tǒng)的核心數(shù)據(jù)表有5張用戶表、房間表、場(chǎng)次表、訂單表、支付流水表。再加上一張優(yōu)惠券表和一張配置表就夠了。用戶表user的核心字段字段名類(lèi)型說(shuō)明idint主鍵openidvarchar(64)微信唯一標(biāo)識(shí)nicknamevarchar(32)微信昵稱(chēng)avatarvarchar(255)頭像地址phonevarchar(20)手機(jī)號(hào)可空balancedecimal(10,2)賬戶余額可用來(lái)抵扣created_atdatetime注冊(cè)時(shí)間房間表room要注意的字段房間類(lèi)型、容納人數(shù)、每時(shí)段價(jià)格、押金、狀態(tài)、門(mén)鎖編號(hào)、封面圖。狀態(tài)字段建議用枚舉值管理available空閑、busy使用中、clean清潔中、maintain維護(hù)中。訂單表order是整個(gè)系統(tǒng)最復(fù)雜的表字段名類(lèi)型說(shuō)明idint主鍵order_novarchar(32)業(yè)務(wù)訂單號(hào)唯一user_idint下單用戶room_idint房間session_idint場(chǎng)次statusvarchar(20)pending/paid/using/completed/cancelledpaid_amountdecimal(10,2)實(shí)付金額含押金rent_amountdecimal(10,2)租金deposit_amountdecimal(10,2)押金actual_amountdecimal(10,2)實(shí)際租金結(jié)算后更新refund_statustinyint0未退 1部分退 2已退完start_timedatetime預(yù)約開(kāi)始時(shí)間end_timedatetime預(yù)約結(jié)束時(shí)間created_atdatetime創(chuàng)建時(shí)間3.2 訂單狀態(tài)機(jī)不同狀態(tài)間的流轉(zhuǎn)規(guī)則狀態(tài)機(jī)是整個(gè)后端邏輯的核心我強(qiáng)烈建議在動(dòng)手寫(xiě)代碼前把狀態(tài)流轉(zhuǎn)圖畫(huà)清楚。不夸張地說(shuō)外包項(xiàng)目里80%的 bug 都出在狀態(tài)沒(méi)有控制好導(dǎo)致用戶在錯(cuò)誤的節(jié)點(diǎn)執(zhí)行了錯(cuò)誤的操作。我的訂單狀態(tài)流轉(zhuǎn)是這樣的pending待支付用戶提交訂單后創(chuàng)建。此時(shí)鎖定房間場(chǎng)次倒計(jì)時(shí)15分鐘超時(shí)自動(dòng)釋放paid已支付微信回調(diào)通知后狀態(tài)變?yōu)橐阎Ц丁４藭r(shí)房間場(chǎng)次標(biāo)記為被占用using使用中用戶到店掃碼開(kāi)門(mén)后狀態(tài)變?yōu)槭褂弥衏ompleted已完成租期結(jié)束且結(jié)算完成狀態(tài)變?yōu)橐淹瓿蒫ancelled已取消用戶主動(dòng)取消或超時(shí)未支付狀態(tài)變?yōu)橐讶∠?。注意用戶主?dòng)取消訂單后如果支付過(guò)要立即觸發(fā)退款這里面有一個(gè)容易忽略的判斷邏輯用戶到店掃碼開(kāi)門(mén)時(shí)如果時(shí)間還沒(méi)到預(yù)約時(shí)段開(kāi)始時(shí)間要不要放行我的策略是提前30分鐘內(nèi)允許進(jìn)場(chǎng)超過(guò)30分鐘則提示“未到入場(chǎng)時(shí)間”。這樣可以避免前面的用戶還沒(méi)走后面的人就已經(jīng)刷卡進(jìn)來(lái)了。3.3 管理端核心功能排班、活動(dòng)、營(yíng)收統(tǒng)計(jì)管理端我用的是獨(dú)立的 Web 管理后臺(tái)和小程序端共用一套后端 API。管理端需要實(shí)現(xiàn)的核心能力有第一房間場(chǎng)次管理。管理員可以直接在日歷視圖上看到每個(gè)房間每天哪些場(chǎng)次被訂了、哪些還空著同時(shí)可以手動(dòng)鎖定某個(gè)場(chǎng)次比如設(shè)備維護(hù)。第二活動(dòng)與優(yōu)惠券配置。共享空間做促銷(xiāo)一般就是兩種首單立減、滿三小時(shí)送一小時(shí)。優(yōu)惠券我設(shè)計(jì)了兩種類(lèi)型滿減券訂單金額滿 X 元減 Y 元和折扣券下單打 X 折。在用戶提交訂單或者結(jié)算時(shí)后端自動(dòng)判斷用戶是否持有可用的券。第三營(yíng)收統(tǒng)計(jì)。不能只看微信支付里的流水因?yàn)檠航鸷屯丝顣?huì)干擾你的判斷。我的統(tǒng)計(jì)頁(yè)面分三塊實(shí)際營(yíng)收租金總和、押金占用當(dāng)前還在退款流程中的押金、訂單量趨勢(shì)圖。有了這三個(gè)基礎(chǔ)數(shù)據(jù)老板才能判斷今天是賺了還是虧了。4. 完整實(shí)操核心代碼從零到可用4.1 微信小程序項(xiàng)目初始化與目錄結(jié)構(gòu)用微信開(kāi)發(fā)者工具創(chuàng)建項(xiàng)目時(shí)選擇“JavaScript基礎(chǔ)模板”不要選 TypeScript因?yàn)楹竺娼右恍┯布S商的 SDK 時(shí)JS 的兼容性更好。推薦目錄結(jié)構(gòu)├── app.js // 小程序入口注冊(cè)全局方法和登錄邏輯 ├── app.json // 全局配置注冊(cè)頁(yè)面、tabBar、窗口樣式 ├── app.wxss // 全局樣式 ├── utils/ │ ├── request.js // 封裝 wx.request統(tǒng)一處理 token 和錯(cuò)誤碼 │ └── util.js // 時(shí)間格式化、距離計(jì)算等工具函數(shù) ├── components/ │ ├── room-card/ // 場(chǎng)地卡片組件 │ └── count-down/ // 倒計(jì)時(shí)組件 ├── pages/ │ ├── index/ // 首頁(yè)場(chǎng)地列表 │ ├── room-detail/ // 場(chǎng)地詳情 │ ├── booking/ // 下單頁(yè) │ ├── order-list/ // 訂單列表 │ ├── order-detail/ // 訂單詳情開(kāi)門(mén)、查看時(shí)長(zhǎng) │ ├── profile/ // 個(gè)人中心 │ └── wallet/ // 錢(qián)包余額、優(yōu)惠券 ├── images/ // 靜態(tài)圖片 └── styles/ // 公共樣式4.2 首頁(yè)加載與場(chǎng)地列表實(shí)現(xiàn)首頁(yè)的請(qǐng)求邏輯我封裝在了request.js里統(tǒng)一管理 token 和錯(cuò)誤處理。每次請(qǐng)求先在攔截器里判斷 token 是否存在不存在就先登錄再請(qǐng)求同時(shí)處理 token 過(guò)期后的刷新邏輯。// utils/request.js const BASE_URL https://api.yoursite.com // 生產(chǎn)環(huán)境域名 function request(options) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success: (res) { if (res.data.code 401) { // token 過(guò)期重新登錄 wx.removeStorageSync(token) app.login().then(() { request(options).then(resolve).catch(reject) }) return } if (res.data.code 0) { resolve(res.data) } else { wx.showToast({ title: res.data.msg || 請(qǐng)求失敗, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 網(wǎng)絡(luò)異常, icon: none }) reject(err) } }) }) }首頁(yè)的數(shù)據(jù)請(qǐng)求在 onShow 里執(zhí)行而不是 onLoad。原因是用戶從詳情頁(yè)返回首頁(yè)時(shí)場(chǎng)地狀態(tài)可能已經(jīng)變化需要在每次顯示頁(yè)面時(shí)刷新列表。4.3 預(yù)約下單與支付流程完整實(shí)現(xiàn)下單頁(yè)面的核心邏輯我分成四步選場(chǎng)次、計(jì)算價(jià)格、提交訂單、拉起支付。價(jià)格計(jì)算這部分要特別小心因?yàn)樯婕把航鸷蛢?yōu)惠。我的前端計(jì)算只是一個(gè)預(yù)估值真正的價(jià)格以后端計(jì)算為準(zhǔn)前端只做展示。這樣做的好處是避免前端改價(jià)格比如修改請(qǐng)求參數(shù)把0.01元改到0元。// pages/booking/booking.js 中提交訂單的核心邏輯 async submitAndPay() { if (!this.data.selectedSession) { wx.showToast({ title: 請(qǐng)選擇場(chǎng)次, icon: none }) return } wx.showLoading({ title: 提交中... }) try { // 1. 創(chuàng)建訂單 const orderRes await createOrder({ roomId: this.data.room.id, sessionId: this.data.selectedSession.id, couponId: this.data.selectedCoupon?.id || null }) // 2. 獲取微信支付參數(shù) const payRes await getPaymentParams({ orderNo: orderRes.data.orderNo }) // 3. 拉起微信支付 wx.hideLoading() const payResult await wxPay(payRes.data) if (payResult.errMsg requestPayment:ok) { // 支付成功跳轉(zhuǎn)訂單詳情 wx.redirectTo({ url: /pages/order-detail/order-detail?orderNo${orderRes.data.orderNo} }) } } catch (err) { wx.hideLoading() console.error(下單失敗, err) } }有一個(gè)細(xì)節(jié)創(chuàng)建訂單后如果用戶沒(méi)有立即支付而是在15分鐘內(nèi)關(guān)閉了頁(yè)面想再次支付怎么辦我加了“待支付訂單”的入口用戶可以回到訂單列表找到狀態(tài)為“待支付”的訂單點(diǎn)擊“去支付”按鈕重新拉起支付。所以支付參數(shù)接口需要支持同一個(gè)訂單重復(fù)獲取支付參數(shù)。4.4 計(jì)時(shí)器與訂單自動(dòng)結(jié)算邏輯使用中的房間用戶能看到已經(jīng)用了多長(zhǎng)時(shí)間、剩余多少時(shí)間。這個(gè)計(jì)時(shí)器是基于服務(wù)端時(shí)間而非本地時(shí)間避免用戶改手機(jī)時(shí)間作弊。// pages/order-detail/order-detail.js 中的計(jì)時(shí)更新邏輯 startTimer() { const endTime new Date(this.data.order.endTime).getTime() this.timer setInterval(() { const now Date.now() const remain endTime - now if (remain 0) { clearInterval(this.timer) this.setData({ remainingText: 已結(jié)束請(qǐng)掃碼結(jié)算, status: expired }) return } const hours Math.floor(remain / 3600000) const minutes Math.floor((remain % 3600000) / 60000) const seconds Math.floor((remain % 60000) / 1000) this.setData({ remainingText: ${hours}小時(shí)${minutes}分${seconds}秒 }) }, 1000) }但注意這個(gè)計(jì)時(shí)器只是展示用真正的結(jié)算還是靠后端定時(shí)任務(wù)。原因很簡(jiǎn)單用戶一旦退出小程序前端計(jì)時(shí)器就停了如果依賴前端去觸發(fā)結(jié)算那用戶不開(kāi)小程序就永遠(yuǎn)沒(méi)法結(jié)算這顯然不行。后端結(jié)算我用了 Node.js 的node-schedule庫(kù)每天每分鐘跑一次檢查任務(wù)。為了避免同一訂單被多次結(jié)算我在結(jié)算邏輯里加了樂(lè)觀鎖更新訂單狀態(tài)時(shí)條件必須是status using如果更新影響行數(shù)為0說(shuō)明訂單已經(jīng)被結(jié)算過(guò)直接跳過(guò)。4.5 云函數(shù)部署與服務(wù)端校驗(yàn)后端我選的是小程序云開(kāi)發(fā)環(huán)境因?yàn)樗詭?shù)據(jù)庫(kù)和文件存儲(chǔ)省去服務(wù)器運(yùn)維的成本。但要注意云函數(shù)有冷啟動(dòng)的問(wèn)題高并發(fā)時(shí)可能出現(xiàn)幾秒延遲。我的優(yōu)化方案是對(duì)核心接口登錄、下單設(shè)置合理的云函數(shù)超時(shí)時(shí)間不要用默認(rèn)3秒避免在云函數(shù)里做大量同步I/O操作比如查詢多個(gè)表時(shí)使用Promise.all并行查詢配置云函數(shù)的實(shí)例并發(fā)數(shù)防止同時(shí)大量觸發(fā)導(dǎo)致超時(shí)服務(wù)端校驗(yàn)最關(guān)鍵的一條所有價(jià)格和金額計(jì)算必須以服務(wù)端為準(zhǔn)。前端傳過(guò)來(lái)的amount字段不能直接相信后端要根據(jù)房間價(jià)格、場(chǎng)次時(shí)長(zhǎng)、數(shù)據(jù)庫(kù)里優(yōu)惠券規(guī)則重新計(jì)算一遍。否則只要有人抓包改參數(shù)就能0元下單。5. 實(shí)戰(zhàn)中踩過(guò)的坑與排查技巧5.1 登錄態(tài)過(guò)期與靜默登錄用戶卡在支付頁(yè)的解決過(guò)程上線后第一個(gè)問(wèn)題就是用戶打開(kāi)小程序看到場(chǎng)地列表正常但點(diǎn)“立即預(yù)約”時(shí)提示“請(qǐng)先登錄”。排查發(fā)現(xiàn)是因?yàn)槲业?token 有效期只設(shè)了24小時(shí)用戶隔天打開(kāi)小程序時(shí)token 已經(jīng)過(guò)期而首頁(yè)接口沒(méi)有做登錄校驗(yàn)所以用戶能瀏覽但下單時(shí)發(fā)現(xiàn)需要重新登錄體驗(yàn)斷裂。解決辦法是在request.js的響應(yīng)攔截器里統(tǒng)一處理 401 狀態(tài)自動(dòng)調(diào)用登錄接口重新獲取 token然后重新發(fā)請(qǐng)求。這樣用戶完全感知不到登錄過(guò)期整個(gè)過(guò)程靜默完成。第二個(gè)坑是微信的getUserProfile接口調(diào)整。2022年之后微信要求必須用戶主動(dòng)點(diǎn)擊才能喚起頭像昵稱(chēng)填寫(xiě)不能直接調(diào)wx.getUserProfile。而且這個(gè)接口對(duì)某些版本的基礎(chǔ)庫(kù)已經(jīng)失效。我的最終方案是完全放棄獲取用戶頭像昵稱(chēng)使用微信默認(rèn)的灰色頭像和“微信用戶”昵稱(chēng)只在用戶首次下單時(shí)彈一個(gè)手機(jī)號(hào)授權(quán)用于接收訂單通知。5.2 支付回調(diào)并發(fā)問(wèn)題重復(fù)發(fā)貨的災(zāi)難微信支付回調(diào)不像普通接口它可能會(huì)重復(fù)發(fā)送多次同樣的通知直到你返回成功。如果你在回調(diào)里直接執(zhí)行“把訂單狀態(tài)改為已支付”那么第二次回調(diào)時(shí)訂單已經(jīng)是已支付狀態(tài)可能引發(fā)重復(fù)操作比如重復(fù)釋放房間場(chǎng)次。我的解決方案是在回調(diào)處理邏輯里加一個(gè)冪等校驗(yàn)// 支付回調(diào)處理 async handlePayCallback(notifyData) { const { orderNo, transactionId } notifyData // 先查訂單是否已處理過(guò)這個(gè) transactionId const existing await PaymentLog.findOne({ where: { transactionId } }) if (existing) { // 已處理過(guò)直接返回成功 return { code: SUCCESS } } // 事務(wù)里原子更新訂單狀態(tài) await sequelize.transaction(async (t) { await PaymentLog.create({ orderNo, transactionId, amount: notifyData.totalFee }, { transaction: t }) await Order.update({ status: paid }, { where: { orderNo, status: pending }, transaction: t }) }) return { code: SUCCESS } }這段代碼的核心思路是利用where: { orderNo, status: pending }這個(gè)條件只有當(dāng)訂單處于 pending 狀態(tài)時(shí)才更新為 paid如果更新行數(shù)為0說(shuō)明訂單已經(jīng)被其他回調(diào)處理過(guò)了直接忽略。5.3 定位授權(quán)與電控鎖聯(lián)動(dòng)的深坑開(kāi)門(mén)校驗(yàn)需要wx.getLocation但微信對(duì)定位授權(quán)管理非常嚴(yán)格。用戶如果首次點(diǎn)了“拒絕”小程序再次調(diào)用wx.getLocation不會(huì)重新彈窗而是直接走 fail 回調(diào)。這時(shí)只能在頁(yè)面上給用戶解釋“需要定位權(quán)限才能開(kāi)門(mén)請(qǐng)前往設(shè)置頁(yè)開(kāi)啟”。但這里還有個(gè)更深的問(wèn)題即使用戶授權(quán)了定位因?yàn)樾〕绦蚨四玫降慕?jīng)緯度是通過(guò) GPS 或者 Wi-Fi 定位估算的精度在幾十米到幾百米之間浮動(dòng)。如果你把敞開(kāi)距離閾值設(shè)得太小比如50米用戶站在店門(mén)口掃碼都有可能出現(xiàn)定位失敗。我最后的妥協(xié)方案是距離閾值放寬到500米同時(shí)在開(kāi)門(mén)頁(yè)增加一個(gè)“點(diǎn)擊開(kāi)門(mén)”的二次確認(rèn)彈窗提示“請(qǐng)確認(rèn)你已到達(dá)門(mén)店門(mén)口”。用戶主動(dòng)點(diǎn)確認(rèn)后再請(qǐng)求開(kāi)門(mén)接口。這個(gè)方案上線后開(kāi)門(mén)失敗率從12%降到了0.5%以下。5.4 小程序分包與包體積問(wèn)題解決代碼提交失敗的尷尬微信小程序主包限制是2MB如果你用了太多組件庫(kù)或者圖片沒(méi)壓縮很容易超限導(dǎo)致提交失敗。我第一次打包時(shí)光是一個(gè) UI 組件庫(kù)就占了800KB加上頁(yè)面代碼和圖片直接超了。解決辦法是使用分包。我的分包方案是主包只放首頁(yè)、預(yù)約頁(yè)和公共組件訂單列表、個(gè)人中心、錢(qián)包等低頻頁(yè)面放到分包里。{ subpackages: [ { root: pages/order, pages: [ pages/order/order-list/order-list, pages/order/order-detail/order-detail ] }, { root: pages/user, pages: [ pages/user/profile/profile, pages/user/wallet/wallet, pages/user/coupon/coupon ] } ], preloadRule: { pages/index/index: { network: all, packages: [pages/order] } } }分包之后主包體積降到了1.3MB還加了preloadRule預(yù)加載分包用戶從首頁(yè)進(jìn)入訂單頁(yè)時(shí)幾乎不需要等待。如果你也遇到“包體積超過(guò)2MB”的提交失敗優(yōu)先檢查images目錄大圖全部壓縮成 WebP另外把不必要的miniprogram_npm依賴清理干凈。5.5 微信開(kāi)發(fā)者工具和真機(jī)的差異白屏問(wèn)題的元兇我在開(kāi)發(fā)時(shí)遇到一個(gè)詭異的問(wèn)題開(kāi)發(fā)者工具里一切正常一到真機(jī)預(yù)覽就白屏。排查了整整一個(gè)下午最后發(fā)現(xiàn)是app.json里window配置的navigationStyle設(shè)置成了custom自定義導(dǎo)航欄的代碼在真機(jī)上因?yàn)槟承┗A(chǔ)庫(kù)版本的兼容問(wèn)題沒(méi)渲染出來(lái)。類(lèi)似的坑還有開(kāi)發(fā)者工具里wx.getSystemInfoSync()返回的statusBarHeight是真機(jī)上的兩倍因?yàn)殚_(kāi)發(fā)者工具模擬器的屏幕密度和真機(jī)不一致導(dǎo)致自定義導(dǎo)航欄在真機(jī)上高度不對(duì)。我的建議是凡是涉及狀態(tài)欄高度、安全區(qū)適配的代碼一律用wx.getWindowInfo()配合safeArea字段計(jì)算而不是寫(xiě)死數(shù)值。真機(jī)白屏還有一個(gè)常見(jiàn)原因是 ES6 語(yǔ)法兼容問(wèn)題。如果你用了可選鏈?.或空值合并??開(kāi)發(fā)者工具默認(rèn)轉(zhuǎn)換成 ES5 沒(méi)問(wèn)題但某些舊版基礎(chǔ)庫(kù)會(huì)報(bào)語(yǔ)法錯(cuò)誤。我的做法是在project.config.json里設(shè)置es6: true和enhance: true同時(shí)在真機(jī)調(diào)試時(shí)選擇最新基礎(chǔ)庫(kù)。5.6 優(yōu)惠券并發(fā)發(fā)放問(wèn)題與超賣(mài)防護(hù)最后一個(gè)要提醒的是優(yōu)惠券的并發(fā)扣減。我做預(yù)熱活動(dòng)時(shí)發(fā)出去100張“滿100減30”的券結(jié)果后臺(tái)顯示領(lǐng)了120張。排查原因用戶點(diǎn)擊領(lǐng)券時(shí)前端同時(shí)發(fā)了兩個(gè)請(qǐng)求后端兩個(gè)請(qǐng)求同時(shí)檢查“券剩余數(shù)量 0”都通過(guò)了導(dǎo)致超發(fā)。解決方式是數(shù)據(jù)庫(kù)層面的原子扣減而不是先查后改UPDATE coupon_batch SET remain_count remain_count - 1 WHERE id ? AND remain_count 0如果影響行數(shù)等于1說(shuō)明扣減成功才給用戶發(fā)券。這比先 SELECT 再 UPDATE 的方式安全得多也不需要引入 Redis 分布式鎖夠用。我做過(guò)幾套不同行業(yè)的小程序共享空間這一套遇到的坑尤其多因?yàn)樗蔷€上交易 線下硬件 資金流轉(zhuǎn)三個(gè)維度的結(jié)合體。單獨(dú)開(kāi)發(fā)一個(gè)商城小程序你只需要關(guān)心線上邏輯單獨(dú)開(kāi)發(fā)一個(gè)智能門(mén)鎖系統(tǒng)你只需要關(guān)心硬件協(xié)議。但共享棋牌室小程序把這兩個(gè)都拉到一起了還要加上押金、退款、超時(shí)結(jié)算這些容易出糾紛的資金邏輯復(fù)雜度一下子就上來(lái)了。我個(gè)人在實(shí)際操作中最深的體會(huì)是優(yōu)先把訂單狀態(tài)機(jī)設(shè)計(jì)正確再談界面和體驗(yàn)。狀態(tài)機(jī)穩(wěn)了支付、退款、開(kāi)門(mén)、結(jié)算都是狀態(tài)流轉(zhuǎn)的副產(chǎn)品狀態(tài)機(jī)亂了后期加什么功能都是在補(bǔ)窟窿。如果你準(zhǔn)備自己動(dòng)手寫(xiě)這套系統(tǒng)從最簡(jiǎn)單的單店、單房間版本開(kāi)始先把“預(yù)約-支付-開(kāi)門(mén)-結(jié)算-退款”這條鏈路跑通再去加活動(dòng)、優(yōu)惠券、多門(mén)店。希望這篇內(nèi)容能幫你少走一些彎路有任何細(xì)節(jié)問(wèn)題可以在評(píng)論區(qū)交流我會(huì)根據(jù)實(shí)際項(xiàng)目經(jīng)驗(yàn)盡量回復(fù)。本文還有配套的精品資源點(diǎn)擊獲取