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