社區(qū)服務(wù)小程序聽(tīng)起來(lái)是一個(gè)很大的方向拆開(kāi)看通常就是三類(lèi)業(yè)務(wù)社區(qū)跑腿、社區(qū)團(tuán)購(gòu)、家政服務(wù)。很多開(kāi)發(fā)者和創(chuàng)業(yè)者一上來(lái)就想著把三個(gè)模塊全做出來(lái)功能列表寫(xiě)得很滿結(jié)果頁(yè)面畫(huà)了一堆真正能跑通的訂單閉環(huán)反而沒(méi)有。我個(gè)人的建議是先不要做“超級(jí)平臺(tái)”先選一類(lèi)業(yè)務(wù)把最小流程跑通再把跑腿、團(tuán)購(gòu)、家政逐個(gè)加進(jìn)去。這篇文章會(huì)按真實(shí)落地順序講一遍從業(yè)務(wù)拆分、技術(shù)選型、最小版本到支付、管理后臺(tái)、測(cè)試上線以及最常見(jiàn)的報(bào)錯(cuò)排查。適合正準(zhǔn)備做社區(qū)服務(wù)小程序或者已經(jīng)在開(kāi)發(fā)中遇到一堆“配置問(wèn)題”的開(kāi)發(fā)者參考。1. 做一個(gè)社區(qū)服務(wù)小程序前先別寫(xiě)代碼先把業(yè)務(wù)角色和訂單流程定清楚1.1 社區(qū)跑腿、社區(qū)團(tuán)購(gòu)、家政服務(wù)三類(lèi)業(yè)務(wù)看著像底層差別很大社區(qū)跑腿的核心是“人找人”和“位置”。用戶發(fā)布“幫我取快遞”“送一份文件”服務(wù)人員接單、取件、送達(dá)。整個(gè)鏈路里最重要的是地址、距離、費(fèi)用、接單狀態(tài)。訂單生命周期一般是待接單、已接單、配送中、已完成、已取消。社區(qū)團(tuán)購(gòu)的核心是“商品、庫(kù)存、成團(tuán)、自提”。用戶選擇商品、支付平臺(tái)根據(jù)訂單數(shù)量形成一個(gè)采購(gòu)批次到貨后用戶到自提點(diǎn)取貨。整個(gè)過(guò)程依賴商品規(guī)格、庫(kù)存扣減、拼團(tuán)狀態(tài)、自提點(diǎn)和配送批次。訂單生命周期一般是待支付、待成團(tuán)、已成團(tuán)、待提貨、已完成。家政服務(wù)的核心是“預(yù)約時(shí)間”和“服務(wù)人員”。用戶選擇保潔、維修、護(hù)工等服務(wù)項(xiàng)目確定上門(mén)時(shí)間平臺(tái)派單或由服務(wù)人員搶單。訂單生命周期一般是待預(yù)約、已派單、服務(wù)中、已完成、售后。如果一開(kāi)始就把三類(lèi)業(yè)務(wù)塞進(jìn)同一個(gè)訂單表字段會(huì)非常多既要放商品ID和拼團(tuán)號(hào)又要放服務(wù)項(xiàng)目和時(shí)間段還要放配送地址和接單人?？雌饋?lái)像“一個(gè)通用訂單系統(tǒng)”實(shí)際上后面每個(gè)模塊的查詢、統(tǒng)計(jì)、對(duì)賬都會(huì)變得很麻煩。我更建議按業(yè)務(wù)拆開(kāi)設(shè)計(jì)哪怕第一版的表結(jié)構(gòu)稍微重復(fù)比硬塞成一個(gè)表更穩(wěn)妥。1.2 用戶角色和權(quán)限可以簡(jiǎn)單但角色邊界一定要有社區(qū)服務(wù)小程序至少要有三類(lèi)角色C 端用戶下單、支付、查看訂單、評(píng)價(jià)。服務(wù)提供者跑腿騎手、家政服務(wù)人員接單、搶單、更新訂單狀態(tài)、查看收入。運(yùn)營(yíng)管理員管理商品、服務(wù)項(xiàng)目、訂單、退款、用戶以及查看數(shù)據(jù)統(tǒng)計(jì)。如果做了社區(qū)團(tuán)購(gòu)還可能需要“團(tuán)長(zhǎng)”角色負(fù)責(zé)自提點(diǎn)核銷(xiāo)和訂單催收。早期可以不用特別復(fù)雜的權(quán)限框架但后端接口一定要校驗(yàn)角色。不能只靠前端隱藏某個(gè)按鈕因?yàn)橛脩艨梢酝ㄟ^(guò)工具修改請(qǐng)求參數(shù)或直接調(diào)用后端接口。服務(wù)人員端只能看到與自己相關(guān)的訂單不能看到全部用戶數(shù)據(jù)。社區(qū)服務(wù)涉及大量地址、電話等個(gè)人信息權(quán)限邊界要在第一版就重視。1.3 賬號(hào)資質(zhì)和前置條件最好開(kāi)工前確認(rèn)清楚微信小程序開(kāi)發(fā)和上線前有幾項(xiàng)前置條件很容易被忽略。小程序賬號(hào)去微信公眾平臺(tái)注冊(cè)完成主體信息認(rèn)證。主體類(lèi)型個(gè)人主體無(wú)法開(kāi)通微信支付。跑腿、團(tuán)購(gòu)、家政這類(lèi)涉及交易的服務(wù)基本都需要企業(yè)或個(gè)體工商戶主體。支付商戶號(hào)如果業(yè)務(wù)真正收費(fèi)必須申請(qǐng)微信支付商戶號(hào)。服務(wù)器和域名正式上線的小程序要求接口使用 HTTPS并且域名需要配置到小程序后臺(tái)的合法域名列表里。HTTPS 證書(shū)證書(shū)過(guò)期、證書(shū)鏈不完整都會(huì)導(dǎo)致真機(jī)請(qǐng)求失敗。如果只是想學(xué)習(xí)或做內(nèi)部 Demo可以用開(kāi)發(fā)者工具自帶的測(cè)試號(hào)先不接支付。但只要想上真實(shí)業(yè)務(wù)這些前置條件需要提前準(zhǔn)備好否則開(kāi)發(fā)到一半再去注冊(cè)企業(yè)主體、申請(qǐng)支付會(huì)拖慢整個(gè)進(jìn)度。1.4 先畫(huà)一張簡(jiǎn)單的流程圖再開(kāi)始搭頁(yè)面我一般會(huì)在項(xiàng)目開(kāi)始前畫(huà)一張非常簡(jiǎn)單的流程圖用戶進(jìn)入小程序選擇服務(wù)發(fā)布需求支付服務(wù)人員接單服務(wù)完成用戶評(píng)價(jià)。不需要用專業(yè)建模工具用紙筆、白板或任意繪圖工具都行。這張圖的價(jià)值在于幫你想清楚“第一步做什么”。例如跑腿場(chǎng)景第一版可以不接支付下單成功后訂單直接進(jìn)入“待接單”狀態(tài)接單人看到的是“已支付”的虛擬狀態(tài)或者干脆用“貨到付款”來(lái)驗(yàn)證流程。等人物、頁(yè)面、狀態(tài)流轉(zhuǎn)都跑通了再接入真實(shí)支付比一上來(lái)就處理支付回調(diào)要簡(jiǎn)單得多。2. 技術(shù)選型原生微信小程序還是 UniApp看你到底只做微信還是未來(lái)要多端2.1 原生微信小程序的優(yōu)劣勢(shì)原生微信小程序是官方技術(shù)棧開(kāi)發(fā)工具、文檔、API、調(diào)試工具都最直接。社區(qū)服務(wù)類(lèi)項(xiàng)目的頁(yè)面結(jié)構(gòu)并不復(fù)雜比如商品列表、訂單列表、表單提交、地圖選點(diǎn)原生寫(xiě)法足夠覆蓋。好處是遇到問(wèn)題查資料更直接很多排查貼都是原生代碼示例不需要額外理解編譯層。缺點(diǎn)是只能發(fā)微信小程序。如果以后要做支付寶小程序、字節(jié)小程序甚至獨(dú)立 App就需要重新開(kāi)發(fā)一套。對(duì)只想先做微信生態(tài)、團(tuán)隊(duì)又是剛開(kāi)始接觸小程序的人來(lái)說(shuō)原生是比較穩(wěn)的選擇。2.2 UniApp 的優(yōu)劣勢(shì)UniApp 是 Vue 語(yǔ)法可以編譯到微信小程序、H5、App 和其他平臺(tái)。如果團(tuán)隊(duì)已經(jīng)熟悉 Vue或者公司明確要求以后要出 H5 和 App用 UniApp 可以省很多重復(fù)開(kāi)發(fā)時(shí)間。缺點(diǎn)是平臺(tái)差異會(huì)帶來(lái)額外問(wèn)題。同一套代碼在 H5 上正常到微信小程序里可能某個(gè) API 調(diào)用失敗微信官方更新了新的組件或能力UniApp 不一定馬上同步。編譯后的代碼定位問(wèn)題比原生多一點(diǎn)間接成本。另外如果項(xiàng)目有大量地圖、支付、藍(lán)牙等原生能力UniApp 可能需要封裝原生插件或使用市場(chǎng)里現(xiàn)成插件增加了不可控因素。2.3 我的選擇建議業(yè)務(wù)沒(méi)穩(wěn)定前優(yōu)先把排查成本降下來(lái)如果是“以微信小程序?yàn)橹?、團(tuán)隊(duì)從零開(kāi)始、業(yè)務(wù)形態(tài)還沒(méi)完全確定”的階段我傾向用原生。原因是排錯(cuò)最簡(jiǎn)單。如果已經(jīng)確定要同時(shí)做小程序和 App或者沒(méi)有原生小程序經(jīng)驗(yàn)但 Vue 很熟再用 UniApp。不要因?yàn)椤耙惶状a跑多端”這個(gè)口號(hào)就直接選實(shí)際開(kāi)發(fā)中多端的兼容調(diào)試時(shí)間會(huì)被低估。2.4 開(kāi)發(fā)環(huán)境和依賴準(zhǔn)備無(wú)論選原生還是 UniApp都必須準(zhǔn)備這些環(huán)境小程序 AppID在微信公眾平臺(tái)創(chuàng)建小程序后拿到。微信開(kāi)發(fā)者工具原生開(kāi)發(fā)直接使用它調(diào)試UniApp 開(kāi)發(fā)時(shí)需要配置為“微信開(kāi)發(fā)者工具模式”編譯后自動(dòng)打開(kāi)。后端服務(wù)可以自己寫(xiě)也可以用云開(kāi)發(fā)。如果用云開(kāi)發(fā)能減少服務(wù)器運(yùn)維但復(fù)雜業(yè)務(wù)的對(duì)賬、支付回調(diào)、消息推送仍然是獨(dú)立后端更可控。目錄結(jié)構(gòu)頁(yè)面按業(yè)務(wù)分目錄不要全部堆在 pages 下面。2.5 頁(yè)面結(jié)構(gòu)和公共組件劃分社區(qū)服務(wù)小程序的頁(yè)面可以這樣拆pages/ index/ 首頁(yè) publish/ 發(fā)布需求/下單 order/ 訂單列表/訂單詳情 goods/ 團(tuán)購(gòu)商品列表/詳情 cart/ 購(gòu)物車(chē) user/ 我的 service/ 家政服務(wù)項(xiàng)目列表公共組件可以單獨(dú)放components/比如地址選擇、聯(lián)系電話輸入、金額展示、訂單狀態(tài)標(biāo)簽、圖片上傳。這些組件在跑腿、團(tuán)購(gòu)、家政三個(gè)模塊里都會(huì)用到提前抽出來(lái)能減少重復(fù)代碼。3. 先跑通最小閉環(huán)社區(qū)跑腿“發(fā)布-接單-完成”3.1 為什么先做跑腿而不是團(tuán)購(gòu)或家政跑腿流程在三類(lèi)業(yè)務(wù)里最短。用戶填地址、備注發(fā)布需求服務(wù)人員看到后接單完成后訂單結(jié)束。沒(méi)有庫(kù)存、成團(tuán)、時(shí)間片調(diào)度這些復(fù)雜概念非常適合作為第一個(gè)可運(yùn)行版本。第一版沒(méi)必要做完整的商業(yè)系統(tǒng)先跑通“一個(gè)用戶發(fā)單、另一個(gè)用戶接單、狀態(tài)能更新”的最小鏈路。這個(gè)鏈路能跑通說(shuō)明賬號(hào)、數(shù)據(jù)庫(kù)、接口、頁(yè)面、狀態(tài)流轉(zhuǎn)這些基礎(chǔ)能力已經(jīng)通了。3.2 頁(yè)面字段和訂單數(shù)據(jù)結(jié)構(gòu)跑腿發(fā)布頁(yè)面至少要有起始位置目的位置物品類(lèi)型快遞、文件、藥品、其他期望送達(dá)時(shí)間備注配送費(fèi)第一版可以用文本輸入 下拉選擇不用急著接地圖。地圖選點(diǎn)需要配置地圖 SDK還會(huì)涉及定位權(quán)限復(fù)雜度高不少。一個(gè)最小訂單對(duì)象大致長(zhǎng)這樣{ id: 20250813001, userId: u_12345, pickupAddress: 3棟102室, deliveryAddress: 5棟樓下驛站, itemType: 快遞, note: 快遞比較重請(qǐng)帶小推車(chē), fee: 5, status: pending, acceptUserId: , acceptTime: , createTime: 2025-08-13 10:00:00 }字段不用一開(kāi)始就設(shè)滿后面需要“取消原因”“訂單號(hào)”“支付單號(hào)”時(shí)再慢慢加。3.3 登錄態(tài)先用 wx.login 確認(rèn)身份不要只盯著頭像昵稱社區(qū)服務(wù)小程序所有下單、接單、支付操作都必須先知道“這個(gè)人是誰(shuí)”。小程序端用wx.login()拿到臨時(shí) code傳給后端后端拿著 code 和 appid、secret 去微信接口換取 openid 和 session_key再生成自己的 token 返回給前端。后續(xù)請(qǐng)求帶上 token后端識(shí)別用戶身份。這里有一個(gè)常見(jiàn)誤區(qū)很多新手以為登錄就是“拿到微信頭像和昵稱”。實(shí)際并不是。登錄是為了確認(rèn)身份頭像昵稱只是展示信息。從某個(gè)版本開(kāi)始wx.getUserProfile只能返回匿名昵稱和默認(rèn)頭像真實(shí)頭像昵稱需要引導(dǎo)用戶在專屬界面填寫(xiě)。所以不要把頭像昵稱作為登錄的必要條件。簡(jiǎn)單示例wx.login({ success(res) { if (res.code) { // 將 res.code 發(fā)送到后端后端換取 openid 和 session_key } } })3.4 訂單狀態(tài)流轉(zhuǎn)要設(shè)計(jì)成“狀態(tài)機(jī)”不要在前端隨意改字段跑腿訂單狀態(tài)建議這樣流轉(zhuǎn)pending待接單 - accepted已接單 - delivering配送中 - completed已完成 pending 狀態(tài)可取消 accepted 之后用戶取消訂單要有限制后端更新?tīng)顟B(tài)時(shí)需要校驗(yàn)“當(dāng)前狀態(tài)是否允許新?tīng)顟B(tài)”。比如一個(gè)已經(jīng)被接單的訂單不能再次被其他人接單。最穩(wěn)妥的方式是更新時(shí)加條件UPDATE orders SET status accepted, accept_user_id ? WHERE id ? AND status pending這樣即使兩個(gè)人同時(shí)點(diǎn)擊接單數(shù)據(jù)庫(kù)也只會(huì)讓一個(gè)人更新成功。前端收到失敗提示“手慢了訂單已被接走”比查完再更新的方案更可靠。3.5 消息通知訂閱消息不能一進(jìn)頁(yè)面就彈用戶不可能一直盯著訂單列表所以需要訂閱消息通知狀態(tài)變化。微信小程序訂閱消息是“一次性訂閱”用戶點(diǎn)一次同意只能收到一次通知。設(shè)計(jì)時(shí)要在合適的時(shí)機(jī)申請(qǐng)訂閱比如用戶發(fā)布跑腿單成功后申請(qǐng)訂閱“訂單狀態(tài)變更提醒”。服務(wù)人員點(diǎn)擊“接單”成功后申請(qǐng)訂閱“新訂單提醒”。家政用戶預(yù)約成功后申請(qǐng)訂閱“上門(mén)提醒”。在小程序后臺(tái)申請(qǐng)訂閱消息模板拿到模板 ID后端發(fā)消息時(shí)用模板 ID 和用戶 openid 發(fā)送。不要一進(jìn)首頁(yè)就彈訂閱授權(quán)那樣用戶基本都會(huì)點(diǎn)拒絕后續(xù)就收不到通知了。3.6 第一版不一定要做在線支付很多人卡在支付上遲遲上不了線。其實(shí)第一版可以先不做在線支付用“貨到付款”或“模擬已支付”來(lái)驗(yàn)證業(yè)務(wù)流程。等到業(yè)務(wù)邏輯穩(wěn)定后再接入微信支付。接入時(shí)需要注意用戶在小程序端發(fā)起支付后端生成預(yù)支付單前端調(diào)wx.requestPayment支付結(jié)果以微信服務(wù)器回調(diào)為準(zhǔn)不要只依賴前端回調(diào)。4. 社區(qū)團(tuán)購(gòu)模塊商品、庫(kù)存、成團(tuán)、自提每一環(huán)都容易出問(wèn)題4.1 商品和庫(kù)存先保證不超賣(mài)再考慮性能社區(qū)團(tuán)購(gòu)和普通電商的區(qū)別在于“集中采購(gòu)、分批配送”。商品、規(guī)格、庫(kù)存一開(kāi)始就要有清晰的數(shù)據(jù)模型。第一版可以這樣設(shè)計(jì)商品表名稱、主圖、詳情、價(jià)格、狀態(tài)。規(guī)格表商品 ID、規(guī)格名、庫(kù)存、價(jià)格。訂單表關(guān)聯(lián)商品、規(guī)格、數(shù)量、自提點(diǎn)、訂單狀態(tài)。下單扣庫(kù)存時(shí)要使用數(shù)據(jù)庫(kù)事務(wù)或帶條件的更新避免用戶同時(shí)下單導(dǎo)致庫(kù)存變成負(fù)數(shù)。最簡(jiǎn)單的一種是“支付成功后再扣庫(kù)存”但要注意庫(kù)存數(shù)量有限時(shí)會(huì)出現(xiàn)“用戶付了錢(qián)但庫(kù)存被搶完”的尷尬。所以很多場(chǎng)景會(huì)選擇“下單鎖庫(kù)存支付成功正式扣減支付失敗釋放庫(kù)存”。第一版不要急著上 Redis 或高并發(fā)方案先把數(shù)據(jù)庫(kù)事務(wù)做對(duì)。社區(qū)團(tuán)購(gòu)的單量前期有限正確性比并發(fā)性能更重要。4.2 成團(tuán)邏輯支付回調(diào)是核心社區(qū)團(tuán)購(gòu)有兩種常見(jiàn)玩法用戶自己開(kāi)團(tuán)邀請(qǐng)別人參團(tuán)人數(shù)滿后成團(tuán)。平臺(tái)統(tǒng)一成團(tuán)所有用戶購(gòu)買(mǎi)同一個(gè)商品達(dá)到目標(biāo)數(shù)量后平臺(tái)統(tǒng)一采購(gòu)。如果是“拼團(tuán)”模式需要有一個(gè)團(tuán)表{ groupId: g_001, goodsId: goods_01, targetCount: 5, currentCount: 2, status: open, ownerUserId: u_100 }用戶支付成功后currentCount 1然后判斷是否達(dá)到targetCount。這里最容易忽略的是“支付回調(diào)會(huì)重復(fù)通知”。微信支付回調(diào)有可能發(fā)多次后端處理時(shí)要冪等同一個(gè)支付單號(hào)已經(jīng)處理過(guò)就不再重復(fù)增加人數(shù)。如果是“平臺(tái)統(tǒng)一成團(tuán)”模式可以簡(jiǎn)單很多支付成功即為參團(tuán)成功后端定時(shí)統(tǒng)計(jì)訂單量達(dá)到目標(biāo)后更新商品狀態(tài)為“已成團(tuán)”。4.3 自提點(diǎn)和配送批次社區(qū)團(tuán)購(gòu)用戶通常要選擇自提點(diǎn)。自提點(diǎn)可以是一個(gè)團(tuán)長(zhǎng)家、便利店、小區(qū)門(mén)口貨架也可以做成固定門(mén)店。訂單里保存自提點(diǎn) ID 和自提時(shí)間。后臺(tái)可以統(tǒng)一生成“配送批次”把同一個(gè)自提點(diǎn)、同一個(gè)時(shí)間段內(nèi)的訂單合并成一個(gè)批次按批次揀貨、發(fā)貨、核銷(xiāo)。第一版不要做復(fù)雜的路徑規(guī)劃直接讓用戶選擇“上午 10:00-12:00 自提”或“下午 16:00-18:00 自提”運(yùn)營(yíng)后臺(tái)按批次人工確認(rèn)完成。4.4 支付回調(diào)、退款和訂單狀態(tài)必須一致社區(qū)團(tuán)購(gòu)里最怕的是“用戶付款了但是訂單狀態(tài)還是待支付”或者“支付成功后成團(tuán)人數(shù)沒(méi)加”。處理方式前端收到支付成功只做提示不直接改訂單。以后端接收微信支付回調(diào)為準(zhǔn)回調(diào)里更新訂單狀態(tài)、扣減庫(kù)存、更新成團(tuán)人數(shù)。回調(diào)處理成功返回成功標(biāo)識(shí)處理失敗返回失敗標(biāo)識(shí)讓微信稍后重試。退款也要記錄退款單號(hào)和退款狀態(tài)所有金額變更都要有日志。5. 家政服務(wù)模塊預(yù)約、派單、上門(mén)、售后5.1 家政服務(wù)的核心是“預(yù)約時(shí)間”不是“立即下單”跑腿和團(tuán)購(gòu)可以立刻處理家政不一樣用戶需要一個(gè)未來(lái)的時(shí)間段服務(wù)人員需要提前安排。服務(wù)項(xiàng)目要提前維護(hù)好比如“日常保潔 2 小時(shí)”“空調(diào)清洗”“水電維修”。每個(gè)項(xiàng)目可以綁定服務(wù)時(shí)長(zhǎng)和價(jià)格。用戶選擇服務(wù)項(xiàng)目后再選上門(mén)日期和時(shí)段。最簡(jiǎn)單的排班方式是后臺(tái)為每個(gè)服務(wù)人員配置可預(yù)約時(shí)段用戶只能選擇剩余可約的時(shí)段。先不要做復(fù)雜的“排班算法”固定時(shí)段就能滿足早期需求。5.2 派單還是搶單家政更適合派單。因?yàn)椴煌?wù)人員擅長(zhǎng)的服務(wù)不同有的擅長(zhǎng)保潔有的擅長(zhǎng)維修平臺(tái)需要根據(jù)訂單類(lèi)型指派給合適的人。后臺(tái)指派以后服務(wù)人員端收到待接任務(wù)點(diǎn)擊“接受”后訂單鎖定。如果服務(wù)人員不接受超時(shí)后訂單可以重新進(jìn)入待指派狀態(tài)。如果做搶單要特別注意并發(fā)問(wèn)題。多個(gè)服務(wù)人員同時(shí)點(diǎn)擊接單后端要用“status pending條件更新”保證只有一個(gè)成功。不要先查出狀態(tài)再判斷因?yàn)橹虚g可能被其他請(qǐng)求改掉。5.3 地址和聯(lián)系方式要結(jié)構(gòu)化也要注意隱私邊界地址第一版可以做成“常用地址”功能用戶保存后復(fù)選。但存儲(chǔ)時(shí)盡量結(jié)構(gòu)化小區(qū)名稱、樓棟、單元、門(mén)牌號(hào)。純文本地址能跑通流程后面要做配送區(qū)域統(tǒng)計(jì)、專員按小區(qū)派單時(shí)會(huì)很難處理。聯(lián)系方式展示時(shí)要謹(jǐn)慎。跑腿、家政訂單會(huì)涉及雙方電話可以在訂單詳情頁(yè)臨時(shí)展示但不要把所有用戶的聯(lián)系方式集中暴露在后臺(tái)給所有人查看。服務(wù)完成后及時(shí)關(guān)閉聯(lián)系電話展示權(quán)限。5.4 完成確認(rèn)和售后流程家政服務(wù)完成最好由用戶確認(rèn)或者由后臺(tái)運(yùn)營(yíng)確認(rèn)。只靠服務(wù)人員自己點(diǎn)完成很容易出現(xiàn)“服務(wù)沒(méi)做完但訂單已經(jīng)完成”的糾紛。售后主要包含取消、改約、退款。未派單前取消全額退款。已派單但服務(wù)人員未上門(mén)用戶可以取消但可能產(chǎn)生少量費(fèi)用或由客服人工處理。已上門(mén)服務(wù)后取消或退款只能走售后審核。第一版可以全部人工處理不建議直接做全自動(dòng)退款。自動(dòng)退款對(duì)賬不熟時(shí)很容易造成資金差錯(cuò)。6. 管理后臺(tái)、服務(wù)人員端以及最容易被忽略的數(shù)據(jù)埋點(diǎn)6.1 一個(gè)社區(qū)服務(wù)小程序?qū)嶋H至少有三個(gè)端很多項(xiàng)目只做了 C 端小程序運(yùn)營(yíng)和服務(wù)人員全擠在同一個(gè)后臺(tái)里操作結(jié)果權(quán)限混亂。建議這樣拆用戶端微信小程序用戶下單和查看訂單。服務(wù)人員端可以做成另一個(gè)小程序也可以做成 H5功能只保留接單、訂單處理、收入統(tǒng)計(jì)。運(yùn)營(yíng)管理后臺(tái)Web 頁(yè)面管理商品、服務(wù)、訂單、退款、用戶和數(shù)據(jù)。如果項(xiàng)目初期團(tuán)隊(duì)很小可以把服務(wù)人員端也做成微信小程序但登錄后根據(jù)角色字段顯示不同菜單。關(guān)鍵是后端接口必須做權(quán)限校驗(yàn)不能只看前端菜單顯示。6.2 運(yùn)營(yíng)后臺(tái)第一版要有什么功能運(yùn)營(yíng)后臺(tái)不需要一開(kāi)始就做得很漂亮但要能解決實(shí)際問(wèn)題商品管理新增、上下架、改價(jià)、改庫(kù)存。服務(wù)項(xiàng)目管理家政項(xiàng)目維護(hù)。訂單管理按時(shí)間、狀態(tài)、用戶、服務(wù)人員篩選。退款處理退款申請(qǐng)列表、退款操作、退款記錄。用戶列表查看用戶基本信息封禁異常賬號(hào)。數(shù)據(jù)導(dǎo)出把訂單列表導(dǎo)出成 Excel 或 CSV運(yùn)營(yíng)經(jīng)常需要本地統(tǒng)計(jì)。不需要第一版就做數(shù)據(jù)大屏。先保證關(guān)鍵列表能查、能篩、能導(dǎo)出。6.3 服務(wù)人員端要保留哪些信息服務(wù)人員端做得很簡(jiǎn)單反而好用。核心功能新任務(wù)提醒。待接單列表。訂單詳情地址、聯(lián)系電話、備注、時(shí)間。訂單狀態(tài)更新接單、開(kāi)始服務(wù)、完成。收入明細(xì)。服務(wù)人員端不要顯示其他用戶的歷史訂單也不要在首頁(yè)展示大量用戶數(shù)據(jù)地圖。能完成“接單-完成后看到收入”就夠了。6.4 數(shù)據(jù)統(tǒng)計(jì)關(guān)鍵節(jié)點(diǎn)一定要埋點(diǎn)否則后面補(bǔ)數(shù)據(jù)很痛苦社區(qū)服務(wù)項(xiàng)目很容易忽視日志和統(tǒng)計(jì)數(shù)據(jù)等運(yùn)營(yíng)想要數(shù)據(jù)時(shí)才發(fā)現(xiàn)訂單表里缺少關(guān)鍵字段。最少要從第一版開(kāi)始記錄訂單創(chuàng)建時(shí)間、支付時(shí)間、接單時(shí)間、完成時(shí)間。用戶 ID、服務(wù)人員 ID。訂單金額、支付金額、退款金額。狀態(tài)變更記錄包括操作人和操作時(shí)間。哪怕第一版沒(méi)有統(tǒng)計(jì)頁(yè)面這些字段和數(shù)據(jù)也要在數(shù)據(jù)庫(kù)里存好。后面補(bǔ)統(tǒng)計(jì)功能可以通過(guò)記錄計(jì)算但如果當(dāng)初沒(méi)有記錄歷史數(shù)據(jù)就永遠(yuǎn)補(bǔ)不回來(lái)。7. 測(cè)試、上線和常見(jiàn)問(wèn)題排查7.1 內(nèi)測(cè)順序先用模擬數(shù)據(jù)再用真實(shí)支付社區(qū)服務(wù)小程序的測(cè)試順序很重要。我一般會(huì)這樣做先在微信開(kāi)發(fā)者工具里跑通完整流程注冊(cè)登錄、發(fā)布訂單、服務(wù)人員接單、更新?tīng)顟B(tài)、完成訂單。這個(gè)階段全部用模擬數(shù)據(jù)不接真實(shí)支付。跑通之后再用測(cè)試微信號(hào)在真機(jī)上跑一遍。真機(jī)環(huán)境和模擬器差異很大尤其是網(wǎng)絡(luò)、權(quán)限、HTTPS、緩存。你會(huì)發(fā)現(xiàn)很多問(wèn)題只在真機(jī)上出現(xiàn)。最后再接入真實(shí)支付先小額測(cè)試比如 1 元訂單再測(cè)試退款流程。支付回調(diào)和退款都要能正常走通才準(zhǔn)備提交審核。7.2 登錄失敗、獲取用戶信息失敗怎么排查如果后端拿不到 openid或者前端報(bào)“獲取登錄后的微信用戶失敗”不要急著改代碼。先按順序排查wx.login是否成功返回 code。code 是否有效是否用錯(cuò) appid。后端請(qǐng)求微信接口時(shí)appid、secret 配置是否正確。服務(wù)器是否能正常訪問(wèn)微信接口。請(qǐng)求日志里是否能看到入?yún)ⅰ㈠e(cuò)誤碼和返回結(jié)果。如果只涉及頭像昵稱確認(rèn)是否已經(jīng)切換到新版“頭像昵稱填寫(xiě)能力”不要再依賴getUserProfile拿真實(shí)昵稱。日志是關(guān)鍵。在登錄接口、微信接口返回處都打日志能省下大量猜測(cè)時(shí)間。7.3 域名、HTTPS、SSL 握手的排查鏈路真機(jī)預(yù)覽時(shí)經(jīng)常遇到net::ERR_CONNECTION_RESET或 SSL 握手失敗。這類(lèi)問(wèn)題通常不是邏輯代碼問(wèn)題而是網(wǎng)絡(luò)環(huán)境或配置問(wèn)題。排查順序小程序后臺(tái)是否配置了 request 合法域名。域名是否支持 HTTPS證書(shū)是否過(guò)期。證書(shū)鏈?zhǔn)欠裢暾？梢杂檬謾C(jī)或宿主機(jī)瀏覽器訪問(wèn)接口地址看證書(shū)是否正常。服務(wù)器是否只允許 HTTP沒(méi)有配置 HTTPS。請(qǐng)求地址是否寫(xiě)成了 IP線上環(huán)境應(yīng)當(dāng)使用域名。開(kāi)發(fā)階段可以臨時(shí)關(guān)閉域名校驗(yàn)但真機(jī)和上線階段必須使用合法域名。如果遇到“小程序無(wú)法打開(kāi)公眾號(hào)文章”通常是業(yè)務(wù)域名沒(méi)有配置。需要在小程序后臺(tái)配置業(yè)務(wù)域名并上傳校驗(yàn)文件讓小程序可以信任這個(gè)公眾號(hào)文章地址。如果要做“小程序 A 跳轉(zhuǎn)小程序 B”需要先在微信公眾平臺(tái)把兩個(gè)小程序關(guān)聯(lián)起來(lái)并使用正確的跳轉(zhuǎn)接口。不要在代碼里隨便填一個(gè) appId 就以為能跳過(guò)去。7.4 支付審核和上線前檢查正式上線前支付相關(guān)要做一次完整檢查用戶支付成功后訂單狀態(tài)是否更新。支付回調(diào)處理是否冪等。退款是否能原路退回。訂單狀態(tài)和支付金額是否一致。支付失敗時(shí)訂單是否能正確取消或允許重新支付。同時(shí)要準(zhǔn)備隱私協(xié)議、用戶協(xié)議、客服聯(lián)系方式、售后電話。小程序?qū)徍藭r(shí)會(huì)看這些基本運(yùn)營(yíng)信息。7.5 上線后不要馬上堆功能先跑一段時(shí)間真實(shí)訂單社區(qū)服務(wù)小程序上線后我最關(guān)心的不是頁(yè)面視覺(jué)效果而是連續(xù)跑 10 筆真實(shí)訂單能不能穩(wěn)定走完。發(fā)布、接單、完成、支付、退款每筆訂單的后端日志都要完整。如果發(fā)現(xiàn)某一步經(jīng)常卡住先看日志再改代碼。不要一收到用戶反饋就立刻改功能先確認(rèn)是偶發(fā)問(wèn)題還是流程問(wèn)題。真正落地時(shí)最容易出問(wèn)題的不是“功能沒(méi)做出來(lái)”而是訂單狀態(tài)在異常路徑下沒(méi)有兜底或者支付回調(diào)沒(méi)有正確處理。先把一個(gè)業(yè)務(wù)跑穩(wěn)再考慮擴(kuò)展團(tuán)購(gòu)、家政整個(gè)項(xiàng)目就不會(huì)推倒重來(lái)。