1. 先搞清楚要不要做需求判斷才是小程序項(xiàng)目的第一道坎很久以前一個做社區(qū)團(tuán)購的客戶拿著厚厚一沓需求文檔來找我說要做一個集會員、積分、分銷、商城、社區(qū)分享于一體的小程序。我第一次報(bào)價就超出了他的全年?duì)I銷預(yù)算。我問他你只想讓用戶能在手機(jī)上下單付款對不對他愣了一下說對。于是我們把功能砍到只剩商品列表、購物車、微信支付和訂單列表開發(fā)周期從兩個月變成了三周。那個小程序上線后跑得很好復(fù)購率一直不錯。這個經(jīng)歷幾乎可以概括中小企業(yè)小程序開發(fā)的全部核心邏輯最貴的從來不是開發(fā)本身而是需求判斷失誤帶來的返工和拖延。很多人一提到小程序第一反應(yīng)是我要做個商城但商城只是一個實(shí)現(xiàn)手段真正要回答的是用戶憑什么打開你的小程序以及他進(jìn)來之后會完成哪個關(guān)鍵動作。這兩個問題沒想清楚后續(xù)所有技術(shù)選型、頁面設(shè)計(jì)、開發(fā)排期都會走彎路。我把這些年接觸到的需求場景分成三類。第一類是流量獲客型典型如門店展示、活動報(bào)名、預(yù)約到店小程序的作用是承接廣告投放和線下掃碼帶來的流量讓用戶能在微信里快速完成瀏覽和留資。第二類是服務(wù)履約型比如點(diǎn)餐、排隊(duì)、預(yù)約服務(wù)周期、課程報(bào)名核心是提高線下服務(wù)的流轉(zhuǎn)效率。第三類是交易轉(zhuǎn)化型就是通常說的商城和零售小程序核心是支付閉環(huán)和復(fù)購運(yùn)營。每種類型的開發(fā)重點(diǎn)完全不同。流量獲客型重點(diǎn)做加載速度和表單轉(zhuǎn)化率服務(wù)履約型重點(diǎn)做訂單狀態(tài)流轉(zhuǎn)和消息通知交易轉(zhuǎn)化型重點(diǎn)做支付穩(wěn)定性、對賬準(zhǔn)確性和售后流程。如果你一開始就要求把所有功能都做上那大概率會在每個模塊上都淺嘗輒止最后哪個都沒做好。還有一類情況我通常建議客戶再想想——業(yè)務(wù)本身不適合小程序。比如低頻重決策的定制服務(wù)用戶不會隔三差五打開一個小程序看定制家具進(jìn)度這種情況下公眾號H5或者企業(yè)微信一對一溝通可能更高效再比如已經(jīng)有穩(wěn)定App用戶群的業(yè)務(wù)硬要再做一個小程序反而會分散運(yùn)營精力。這些判斷聽起來像廢話但在實(shí)際咨詢中我?guī)缀趺扛粢欢螘r間就會遇到一位因?yàn)橥凶隽诵〕绦蚓头且L(fēng)的老板。跟風(fēng)的項(xiàng)目做完之后最常出現(xiàn)的結(jié)局就是上線即死亡——除了最初邀約上來的那幾十個用戶再也沒有自然增長。所以中小企業(yè)做小程序的第一步不是找開發(fā)、詢價、列功能清單而是先畫一張業(yè)務(wù)邏輯圖把用戶從哪里來、進(jìn)入后做什么動作、離開后如何再次觸達(dá)這三件事想透。想透了后面的技術(shù)選型才有依據(jù)想不透再先進(jìn)的技術(shù)棧也救不了一個偽需求。我在需求評審階段會要求客戶填一張表格把所有想做的功能列出來逐個標(biāo)注三個指標(biāo)使用頻次、開發(fā)成本、和維護(hù)成本。凡是高頻使用且能直接帶來收入的放到第一優(yōu)先級低頻但屬于核心服務(wù)的放到第二優(yōu)先級剩下的加分項(xiàng)功能全部暫時砍掉。這個流程走下來通常最終保留的功能只有客戶最初清單的百分之三十。提示判斷一個功能到底做不做有個很簡單的標(biāo)尺——它會不會讓用戶進(jìn)門后最重要的那個動作變得更順暢。如果答案不確定就先不做。2. 技術(shù)路線取舍原生小程序、跨端框架與云開發(fā)到底怎么選需求梳理清楚之后才輪到真正的技術(shù)選型問題。這也是我收到私信提問最多的一塊。坦白說中小企業(yè)和外包團(tuán)隊(duì)常遇到的選型困境和大廠前端團(tuán)隊(duì)完全不同。大廠要考慮的是幾百人團(tuán)隊(duì)協(xié)作、幾十個平臺同步發(fā)布、超大型代碼倉庫維護(hù)而中小企業(yè)通常只有一兩個后端開發(fā)甚至根本沒有專職前端很多項(xiàng)目是請外包來做做完交付源碼就不太有人管了。所以我給中小企業(yè)的選型建議只有一句話用你們現(xiàn)有的團(tuán)隊(duì)能力能長期維護(hù)的方式而不是當(dāng)下最流行或最高級的方式。市面上主流的小程序開發(fā)路線有三條。第一條是使用各平臺官方原生開發(fā)微信小程序用WXMLWXSSJS支付寶小程序用AXMLACSS抖音小程序也有自己的一套特點(diǎn)是不需要引入額外框架調(diào)試方便審核兼容性最好但平臺之間代碼不能復(fù)用做一個多平臺項(xiàng)目就要寫多份邏輯。第二條是使用跨端框架比如uni-app或Taro用一套代碼同時編譯到微信、支付寶、抖音等多個小程序平臺表面上省了重復(fù)開發(fā)代價是框架編譯層偶爾會出現(xiàn)某個平臺表現(xiàn)不一致的隱藏問題。第三條是使用微信的云開發(fā)能力也就是云函數(shù)加云數(shù)據(jù)庫加云存儲后端邏輯跑在平臺側(cè)托管服務(wù)上前端開發(fā)者不需要自己維護(hù)服務(wù)器這是很多小團(tuán)隊(duì)快速落地時喜歡走的路。三條路線我實(shí)際項(xiàng)目里都經(jīng)歷過各有各的坑。單平臺項(xiàng)目用原生開發(fā)其實(shí)最省心因?yàn)樵鶤PI調(diào)用最直接、真機(jī)調(diào)試最快、平臺升級時的適配壓力最小。但一旦客戶說以后要同時做支付寶小程序和抖音小程序用原生就不是好選擇了——等待你的將是三份代碼、三個提審周期、三個版本的bug修復(fù)進(jìn)度維護(hù)成本呈指數(shù)級上漲?？缍丝蚣苓@時候就體現(xiàn)出價值了但選擇跨端框架時有個前置條件團(tuán)隊(duì)里至少要有一個人能讀懂框架編譯后的產(chǎn)物能在某個平臺出現(xiàn)怪異表現(xiàn)時定位到具體代碼。這里順帶說一個我踩過的坑。有一次用某個跨端框架給客戶做預(yù)約類小程序多個平臺同時發(fā)布微信小程序一切正常但某個安卓廠商渠道上的分享卡片一直無法正常生成縮略圖。排查了很長時間最后發(fā)現(xiàn)是框架版本與廠商平臺的接口兼容問題升級框架之后才解決。這種問題文檔里寫得再清楚也敵不過你在真實(shí)環(huán)境里試一次。云開發(fā)這條路我認(rèn)為它最適合兩類人一類是公司有現(xiàn)成前端但沒有專業(yè)后端的團(tuán)隊(duì)想快速把產(chǎn)品跑起來做市場驗(yàn)證另一類是原型階段的產(chǎn)品需要一個月內(nèi)拿著Demo去談合作或融資。但在業(yè)務(wù)量起來之后你要認(rèn)真關(guān)注計(jì)費(fèi)模型和并發(fā)能力。云函數(shù)按調(diào)用次數(shù)計(jì)費(fèi)云數(shù)據(jù)庫按讀寫次數(shù)計(jì)費(fèi)流量高峰期賬單漲得快此外云函數(shù)存在冷啟動問題用戶第一次訪問有時會明顯感覺到卡頓這個感知對C端體驗(yàn)并不友好。如果業(yè)務(wù)走到這一步通常就需要遷到傳統(tǒng)服務(wù)器架構(gòu)或混合架構(gòu)了。下表是我在咨詢時經(jīng)常使用的一個選型思路包含了我個人對各路線的核心判斷項(xiàng)目情況推薦路線主要理由只做微信小程序且后續(xù)沒有多平臺計(jì)劃原生開發(fā)代碼少、性能穩(wěn)、提審簡單計(jì)劃覆蓋微信、支付寶等多個平臺uni-app / Taro一套代碼多端復(fù)用節(jié)省重復(fù)開發(fā)成本團(tuán)隊(duì)只有前端沒有后端運(yùn)維能力云開發(fā) / Serverless免運(yùn)維快速上線適合驗(yàn)證需求已有成熟后端系統(tǒng)或ERP、CRM需要對接傳統(tǒng)服務(wù)器 原生/跨端便于控制復(fù)雜業(yè)務(wù)邏輯、數(shù)據(jù)安全和接口靈活性想低成本快速做一個內(nèi)部工具型小程序云開發(fā)開發(fā)效率高不需要太多基礎(chǔ)設(shè)施投入關(guān)于外包交付我必須單獨(dú)提醒一件事無論選哪條路線簽約時一定要約定交付物清單源碼、后臺管理賬號、服務(wù)器部署文檔、云開發(fā)環(huán)境權(quán)限一個都不能少。我接手過不少爛尾項(xiàng)目開發(fā)公司跑路客戶手里只有一個小程序賬號后臺代碼看都看不到想換人維護(hù)等于從頭再來。這種損失往往比最初省下的開發(fā)費(fèi)高好幾倍。3. 基礎(chǔ)設(shè)施的隱性賬單域名、備案、服務(wù)器與云資源成本選完技術(shù)路線緊接著就是搭環(huán)境。很多第一次做小程序的老板會在這一步懵住為什么開發(fā)一個小程序還要買域名和服務(wù)器為什么備案要等大半個月為什么強(qiáng)制要求HTTPS證書我這里把從零到上線需要準(zhǔn)備的基礎(chǔ)設(shè)施項(xiàng)列全順便算一筆真實(shí)的成本賬。首先是域名。小程序后臺要求配置合法域名作為網(wǎng)絡(luò)請求白名單也就是說你的后端API地址必須是一個備案過的域名且必須是HTTPS協(xié)議。域名本身不貴普通后綴一年幾十元但備案是這里的真正時間成本。在國內(nèi)服務(wù)器上部署ICP備案通常需要一到兩周遇到資料退回重提的拖一個月也不奇怪。需要注意的是如果小程序主體是公司域名備案主體也必須是同一家公司否則審核時會出現(xiàn)主體不一致被拒的情況。然后是服務(wù)器。起步階段我不建議買高配機(jī)器一個每天幾百日活的業(yè)務(wù)2核4G的配置已經(jīng)完全夠用了。反而是帶寬我建議按實(shí)際并發(fā)來評估。小程序的API請求都是短連接圖片走對象存儲CDN時不會占用服務(wù)器主帶寬API本身消耗不了多少流量。很多新手在服務(wù)器帶寬上花冤枉錢買了很高的帶寬結(jié)果每月實(shí)際使用率不到百分之五。再說到存儲。如果小程序里需要上傳圖片、視頻、文件一定不要把這些文件存到服務(wù)器本地磁盤上更不要直接存到MySQL里。正確做法是使用對象存儲服務(wù)加內(nèi)容分發(fā)網(wǎng)絡(luò)上傳走臨時密鑰直傳展示走CDN緩存這樣既快又省。對象存儲的成本大頭在外網(wǎng)下行流量圖片如果不壓縮就直傳日活三千的小程序一個月流量費(fèi)也能到幾百上千。這里補(bǔ)充一個小程序研發(fā)階段常遇到的現(xiàn)象本地開發(fā)環(huán)境一切正常上線后卻發(fā)現(xiàn)部分用戶頁面加載奇慢。排查后大概率是靜態(tài)資源沒有走CDN或者圖片沒有做壓縮處理后端接口本身其實(shí)只占很小一部分耗時。我的習(xí)慣是在項(xiàng)目初期就把全鏈路資源優(yōu)化列入任務(wù)清單而不是等用戶投訴之后再補(bǔ)救因?yàn)樯暇€后再換資源路徑往往要改接口和客戶端雙端返工成本很高。HTTPS證書這塊也有坑。小程序強(qiáng)制要求所有請求域名均為HTTPS證書不能用自簽名必須由受信任的CA機(jī)構(gòu)簽發(fā)?，F(xiàn)在很多云平臺提供一年期免費(fèi)證書可以每年輕松續(xù)期。但要注意續(xù)期這件事必須有人盯著比如設(shè)個定時提醒。我曾見過一個線下門店小程序因?yàn)樽C書過期沒及時續(xù)整個小程序癱瘓了差不多一天那天的線上點(diǎn)單業(yè)務(wù)全部停了。就為了省幾十塊一年的事?lián)p失遠(yuǎn)超證書價格。關(guān)于云開發(fā)和傳統(tǒng)服務(wù)器混合使用我還想多說一句很多小程序?yàn)榱丝焖偕暇€后端邏輯全部寫在云函數(shù)里等到要接企業(yè)已有的客戶管理系統(tǒng)時才發(fā)現(xiàn)數(shù)據(jù)隔離、鑒權(quán)、內(nèi)網(wǎng)互通都成了問題。中小企業(yè)只要涉及后續(xù)系統(tǒng)對接我建議規(guī)劃時就預(yù)留接口層把哪些邏輯放云函數(shù)、哪些邏輯走自有服務(wù)器想明白別等數(shù)據(jù)流撕扯不開再重構(gòu)。最后給出一個粗略的月度成本參考。一個日活500到1000的小程序商城業(yè)務(wù)較簡單的情況下云服務(wù)器2核4G的費(fèi)用加上對象存儲和CDN流量控制在每月200到400元是完全可行的如果使用云開發(fā)起步階段可能只要幾十元但隨著調(diào)用量上漲通常會在200到600元區(qū)間浮動。真正要警惕的不是基礎(chǔ)費(fèi)用而是那些按次計(jì)費(fèi)的項(xiàng)目比如短信驗(yàn)證碼、云函數(shù)調(diào)用次數(shù)、日志存儲量這些單看都不貴乘上用戶量就完全不是一回事了。4. 上線前最容易被卡住的資質(zhì)與類目審核技術(shù)開發(fā)都完成了需求也做好了小程序卻不一定能順利上線。很多項(xiàng)目就是倒在了審核這一關(guān)而且通常是在項(xiàng)目交付前一周急得跳腳才意識到問題。首先要搞清楚一件事小程序不是你想用哪種功能就哪種功能的你的主體資質(zhì)決定了你能選什么類目類目又反過來決定你能用什么能力。比如做食品銷售需要食品經(jīng)營許可證做餐飲外賣需要食品經(jīng)營許可證或相關(guān)衛(wèi)生資質(zhì)做教育課程培訓(xùn)需要辦學(xué)許可或相關(guān)的備案證明做金融、醫(yī)療服務(wù)對主體資質(zhì)的要求更為嚴(yán)格個人和企業(yè)主體的準(zhǔn)入門檻都不一樣。在官方類目庫里選了對應(yīng)類目后系統(tǒng)會要求上傳相應(yīng)的資質(zhì)文件這一步若提供不了功能做得再好也發(fā)不了版本。這里面有一個很常見的誤區(qū)很多人以為注冊一個公司就能做任何行業(yè)的小程序。實(shí)際上審核平臺會核對小程序的實(shí)際服務(wù)內(nèi)容與營業(yè)執(zhí)照經(jīng)營范圍是否一致。曾經(jīng)有個客戶注冊的是商貿(mào)公司卻想做職業(yè)技能培訓(xùn)的報(bào)名和課程播放小程序因?yàn)榻?jīng)營范圍里沒有教育培訓(xùn)相關(guān)項(xiàng)目審核直接被打回后來折騰了變更經(jīng)營范圍前后耽誤了近一個月的上線時間。第二個常見被拒原因是隱私政策缺失?，F(xiàn)在各平臺審核都非?？粗赜脩綦[私合規(guī)小程序如果收集用戶的微信昵稱、頭像、手機(jī)號、地理位置信息等必須在《小程序用戶隱私保護(hù)指引》里逐項(xiàng)聲明并且在小程序內(nèi)提供可查看的完整隱私政策文本。很多開發(fā)者在首頁彈窗里只寫了一句歡迎使用就草草上線結(jié)果審核被駁回。這個環(huán)節(jié)不需要很復(fù)雜但一定要寫得明確比如我們收集手機(jī)號用于注冊登錄和訂單通知而不能模糊寫用于更好服務(wù)用戶。第三個被拒重災(zāi)區(qū)是虛擬支付問題。在iOS端小程序是不允許直接用微信支付購買虛擬商品的比如會員VIP、在線課程、付費(fèi)音頻這些屬于虛擬支付范疇。如果你的小程序里恰好有這種商品審核會要求你下架或調(diào)整支付方式。處理思路一般兩種要么虛擬商品只做線下核銷或安卓端購買展示要么接入平臺官方虛擬支付組件但后者對主體資質(zhì)和企業(yè)規(guī)模有額外要求。這一步盡量在開發(fā)前就確認(rèn)好商品屬性和支付方案別等前端頁面全做完了再拆。還有一類容易忽略的點(diǎn)是誘導(dǎo)分享類設(shè)計(jì)。比如分享后解鎖功能、分享后領(lǐng)取紅包、轉(zhuǎn)發(fā)朋友才能查看完整內(nèi)容這類玩法審核基本都會攔截。小程序早期的野蠻生長階段已經(jīng)過去現(xiàn)在對分享激勵的管控很嚴(yán)格。想要做傳播建議走正規(guī)的社交立減金分享得積分等營銷能力且這些能力通常也要求主體有相應(yīng)的經(jīng)營類目不能隨便上。我看到不少項(xiàng)目團(tuán)隊(duì)把審核相關(guān)的工作安排到開發(fā)收尾階段才啟動這是非常危險的。正確的做法是在需求評審階段就同步啟動資質(zhì)核查先把小程序擬選的類目和所需資質(zhì)清單整理出來把營業(yè)執(zhí)照經(jīng)營范圍與業(yè)務(wù)是否匹配核實(shí)一遍然后把支付方案、用戶信息收集范圍、隱私政策文案這幾件事定下來。資質(zhì)有問題的該變更經(jīng)營范圍就盡早變更類目選不了的該調(diào)整功能就盡早調(diào)整。這些前置工作做足了提審時才不會一波三折。注意還有一種個人主體小程序的情況。個人主體可選的類目非常有限也無法使用微信支付很多商家在起步階段為了速度快用個人主體注冊后期想升級到企業(yè)主體時卻發(fā)現(xiàn)無法直接在原賬號上切換只能新注冊賬號重新開發(fā)。所以哪怕營業(yè)執(zhí)照還在辦理中我都建議等企業(yè)主體下來再注冊小程序不要貪圖那幾天的進(jìn)度。5. 從開發(fā)到發(fā)布的實(shí)戰(zhàn)坑登錄、支付、緩存和提審節(jié)奏前面的環(huán)節(jié)都理順了終于進(jìn)入實(shí)際開發(fā)環(huán)節(jié)。這一部分我重點(diǎn)講幾個我反復(fù)遇到的、且?guī)缀趺總€中小企業(yè)項(xiàng)目都會踩的高頻坑附帶我自己的排查思路不一定能覆蓋所有情況但能幫你少走很多彎路。第一個是登錄態(tài)的暗坑。在小程序里用戶通過客戶端能力靜默拿到身份標(biāo)識再用它換一個會話憑證整個過程看起來很簡單。但實(shí)際開發(fā)中經(jīng)常出現(xiàn)一種情況開發(fā)者在微信開發(fā)者工具里模擬登錄一切正常一到真機(jī)上就無法獲取用戶信息或者短時間內(nèi)頻繁掉線。原因通常是工具環(huán)境和真機(jī)環(huán)境的緩存機(jī)制不同、基礎(chǔ)庫版本不同、或會話憑證過期處理邏輯寫得不夠健壯。我建議把登錄模塊當(dāng)作核心架構(gòu)來對待而不是一個簡單的接口調(diào)用。登錄成功后的憑證要設(shè)置合理的過期時間對所有涉及用戶身份的請求統(tǒng)一做攔截器和自動刷新邏輯。這樣處理之后即使部分用戶首次進(jìn)入稍慢也不容易出現(xiàn)頁面刷不出來或操作到一半被彈回登錄頁的體驗(yàn)問題。這個模塊一旦上線后出bug排查成本和用戶流失損失都比開發(fā)階段多得多。第二個是支付環(huán)節(jié)。微信支付的小程序接入流程中最容易出問題的是商戶號和回調(diào)接口。很多開發(fā)者在回調(diào)處理邏輯里只驗(yàn)證了參數(shù)卻沒有驗(yàn)證回調(diào)通知是否重復(fù)也沒有在設(shè)計(jì)上保證回調(diào)處理的冪等性。結(jié)果就是用戶明明支付成功了訂單卻顯示未支付因?yàn)榛卣{(diào)通知到達(dá)時被某些異常情況阻斷又或者用戶被扣了兩次款因?yàn)榛卣{(diào)被重復(fù)處理了。這兩個問題是支付類小程序投訴率最高的bug沒有之一。我在處理回調(diào)邏輯時有一套固定做法回調(diào)接口首先要驗(yàn)簽驗(yàn)簽通過后根據(jù)訂單號查數(shù)據(jù)庫如果該訂單已經(jīng)是已支付狀態(tài)則直接返回成功不再做任何重復(fù)操作如果還未標(biāo)記支付成功則加分布式鎖或數(shù)據(jù)庫樂觀鎖保證同一時間只有一個進(jìn)程處理這筆訂單。這套邏輯寫起來不復(fù)雜但能擋住絕大多數(shù)因?yàn)榻涌诔瑫r、重試、并發(fā)引起的支付狀態(tài)錯亂問題。第三個是緩存和版本更新問題。小程序發(fā)布的版本機(jī)制非常特殊用戶打開時如果本地已有舊版本代碼平臺不會主動把新版推給所有用戶而是會在用戶下次啟動時異步拉取新包如果在開發(fā)版中調(diào)試生產(chǎn)環(huán)境接口測出來的效果和正式版也可能不同。這就是為什么很多團(tuán)隊(duì)會遇到明明已經(jīng)發(fā)布了新版本還是很多用戶在用舊版的現(xiàn)象。處理方法是設(shè)置合理的版本更新檢查機(jī)制在啟動時主動獲取最新版本信息發(fā)現(xiàn)可用更新時彈窗提示重新打開同時開發(fā)時需要注意本地存儲的數(shù)據(jù)結(jié)構(gòu)版本否則新版本代碼去讀取舊版本的緩存數(shù)據(jù)時很容易出現(xiàn)字段缺失或格式錯誤引起的白屏。我手里有兩個項(xiàng)目都曾因?yàn)榫彺嫔墰]有處理導(dǎo)致一批存了舊緩存數(shù)據(jù)的用戶直接無法正常使用首頁。開發(fā)前就規(guī)劃好緩存key版本和兼容邏輯遠(yuǎn)比事后發(fā)緊急版本補(bǔ)救要舒服。發(fā)布節(jié)奏本身也是一門學(xué)問。小程序的審核周期通常是一到七個工作日遇到節(jié)假日或重大活動時期會更長所以提審時間要留冗余。我的一般建議是不要在周四或周五下午提審新版本因?yàn)橐坏┍获g回想再修改重新提審可能就撞上周末了。比較穩(wěn)妥的安排是周一提審駁回后周二修改、周三復(fù)審這樣一周內(nèi)就能完成版本發(fā)布。版本發(fā)布當(dāng)天建議先使用灰度發(fā)布或小范圍放量觀察接口報(bào)錯和崩潰日志驗(yàn)證無問題后再全量放開。這個流程聽起來多花了一天但能避免改動影響全量用戶這種最壞結(jié)果。再分享一次具體的排錯經(jīng)歷。某次給一個連鎖烘焙店上線預(yù)約取貨小程序測試階段支付都沒問題但上線后僅兩三個小時就接到電話說出現(xiàn)了幾筆訂單支付成功但后臺查不到。我的排查鏈路是這樣展開的先查支付回調(diào)日志發(fā)現(xiàn)回調(diào)任務(wù)在凌晨有大量超時重試再查訂單表確認(rèn)這些訂單確實(shí)沒有插入記錄繼續(xù)查回調(diào)處理代碼發(fā)現(xiàn)回調(diào)里有一段邏輯在訂單號不存在時會拋異常而異常直接導(dǎo)致了事務(wù)回滾也就是說回調(diào)處理方收到通知后試圖寫訂單但因?yàn)槟硞€字段校驗(yàn)失敗整筆操作被回滾訂單就丟了。問題定位到這兒修復(fù)方向就變成了兩件事一是把回調(diào)通知訂單號不存在的場景從報(bào)錯改成有序記錄并進(jìn)入重試隊(duì)列等待補(bǔ)償二是給訂單創(chuàng)建接口加上補(bǔ)償機(jī)制定期對賬時發(fā)現(xiàn)此類狀態(tài)就自動補(bǔ)單。修復(fù)后一周觀察同類問題再沒出現(xiàn)過。這個案例給我最大的教訓(xùn)是支付類的異常不能只靠開發(fā)環(huán)境測試覆蓋上線后要有對賬腳本和兜底補(bǔ)償否則任何一個你看不到的分支邏輯都可能在真實(shí)流量下變成資損事故。6. 上線后的版本節(jié)奏與成本優(yōu)化小程序是持續(xù)運(yùn)營品不是一次性交付很多中小企業(yè)把小程序上線當(dāng)成了項(xiàng)目的終點(diǎn)驗(yàn)收通過之后就不再投入技術(shù)和產(chǎn)品精力。這個認(rèn)知是我最想糾正的。小程序一旦上線就已經(jīng)進(jìn)入了運(yùn)營和迭代階段它的打開率、轉(zhuǎn)化率、成本消耗全部是動態(tài)變化的需要有人持續(xù)關(guān)注和調(diào)整。第一件要做的事是數(shù)據(jù)埋點(diǎn)。埋點(diǎn)不需要一開始就事無巨細(xì)全部鋪開中小企業(yè)階段抓住核心路徑就夠了。我通常會要求項(xiàng)目里至少埋下這幾個事件小程序啟動、首頁曝光、商品或服務(wù)詳情頁點(diǎn)擊、加入購物車或發(fā)起預(yù)約、提交訂單、支付成功。這六個事件串起來就是一條完整的主轉(zhuǎn)化漏斗。上線后每周看一遍每一步的轉(zhuǎn)化率就能非常清楚地知道用戶在哪一步流失最多下一步該優(yōu)化哪個頁面。很多團(tuán)隊(duì)不做埋點(diǎn)全憑直覺改版結(jié)果往往是花了大力氣改了用戶根本不看的頁面真正讓用戶流失的環(huán)節(jié)卻被漏掉了。第二件是版本迭代的節(jié)奏。我建議中小企業(yè)小程序保持每兩到三周發(fā)布一個小版本的節(jié)奏每次集中解決一到兩個問題。不要憋大招攢半年的需求一次性改版上線風(fēng)險極高。小步快跑的另一個好處是每個版本的改動范圍小出了問題更容易定位回滾也更快。需求來源除了你自己的構(gòu)想還包括用戶在客服消息里的高頻提問?？头⑹莻€極好的需求池用戶反復(fù)詢問能不能這樣操作大概率就是真的需要這個功能。第三件是成本優(yōu)化。小程序上線一段時間后應(yīng)該主動審視各資源項(xiàng)的消耗情況。服務(wù)器和云資源的成本不是一個固定值它會隨著用戶量增長而變化。我習(xí)慣在每個月月底做一次成本復(fù)盤查看API請求量變化、對象存儲流量趨勢、云函數(shù)調(diào)用次數(shù)、短信發(fā)送量找出增長異常的項(xiàng)目看是用戶量真在漲還是某段代碼存在無效請求。比如圖片不壓縮就傳輸、頁面滾動時反復(fù)觸發(fā)接口這類問題都會導(dǎo)致成本無謂上漲而這些多半可以通過前端優(yōu)化解決。這里額外提一個小技巧小程序首次啟動的資源加載策略很重要。如果首頁引用了大量圖片和接口冷啟動速度會非常慢用戶可能直接關(guān)掉。建議把首頁請求拆成主鏈路和輔助鏈路先渲染用戶最關(guān)心的內(nèi)容其他模塊異步加載圖片盡量使用輕量格式并壓縮尺寸能走CDN的別打源站。這些做下來首頁加載速度通常能快一截對轉(zhuǎn)化率的提升是立竿見影的。還有一個容易被忽略的點(diǎn)是用戶反饋渠道。小程序里要留一個明顯的意見反饋入口或者在設(shè)置頁放上客服聯(lián)系方式讓用戶遇到問題時能低成本觸達(dá)你。很多中小企業(yè)舍不得在客服上投入人力結(jié)果差評和投訴全跑到應(yīng)用商店和用戶朋友圈里去了反而更被動。哪怕只做一個簡單的反饋表單也能幫你提前發(fā)現(xiàn)很多數(shù)據(jù)和埋點(diǎn)發(fā)現(xiàn)不了的真實(shí)使用問題。關(guān)于技術(shù)棧的后續(xù)演進(jìn)我想再補(bǔ)一句上線初期選的路不會一直不變。比如最開始為了快速上線用了云開發(fā)后來用戶量大了、業(yè)務(wù)邏輯復(fù)雜了慢慢把核心交易環(huán)節(jié)遷到自有服務(wù)器這在很多項(xiàng)目里都是正常的演進(jìn)路徑。不用一開始就追求一步到位的完美架構(gòu)但每段代碼、每個數(shù)據(jù)表都要保持結(jié)構(gòu)穩(wěn)定、注釋清楚讓后續(xù)重構(gòu)有據(jù)可依。做了幾年中小企業(yè)小程序開發(fā)和顧問之后我最大的體會是這類項(xiàng)目真正的難點(diǎn)從來不是某一項(xiàng)高深技術(shù)而是怎么在有限的預(yù)算、有限的人和有限時間內(nèi)精準(zhǔn)做出能產(chǎn)生業(yè)務(wù)價值的東西。技術(shù)選型、服務(wù)器配置、審核合規(guī)、發(fā)布節(jié)奏每個環(huán)節(jié)都有省錢的技巧也有繞不開的硬成本關(guān)鍵是弄清楚錢應(yīng)該花在哪、時間應(yīng)該省在哪。如果你正準(zhǔn)備啟動一個小程序項(xiàng)目我建議先別急著找開發(fā)報(bào)價花兩三天時間把業(yè)務(wù)邏輯和資質(zhì)清單理清再回來做選型和排期你會發(fā)現(xiàn)后面每個步驟都順了不少。