做過幾個微信小程序商城專案之後，說實話我最深的感觸是：選對技術架構比什麼都重要。像原始碼中提到的520鮮花商店，用微信小程序原生框架加上雲開發，這條路我個人覺得特別適合剛起步的小團隊或是個人開發者——不用管伺服器、不用折騰域名備案，直接透過微信的雲資料庫和雲函數就能搞定前後端串接。這在實戰中能省下至少一半的開發時間，尤其是那種急著要上線的節日促銷項目，比如情人節、母親節，時間就是金錢啊。
為什麼要選原生框架而非第三方框架？
很多人會問：Taro、uni-app 不香嗎？跨平台欸。但我踩過幾次坑後發現，如果目標就是微信小程式商城，原生框架反而是最穩定的選擇。那些第三方框架雖然號稱一次編寫多端運行，但在實際開發中，經常遇到組件相容性問題，尤其是購物車的動畫、頁面切換的順滑度，原生框架能直接調用微信的底層 API，效能更可控。而且雲開發的雲函數與原生框架的綁定非常緊密，除錯也更簡單——你總不想在要上線前一天發現某個第三方框架的 bug 吧？
資料庫設計的實戰心得
原始碼裡提到雲數據庫有 flowers、cart、order 等集合，這點我深有體會。鮮花商城跟一般商品不太一樣，它的商品屬性很多：花語、包裝規格、配送時段、庫存狀態（比如節日當天可能特定花束會臨時下架）。我建議在設計 flowers 集合時，一定要留一個「自訂欄位」的空間，像是 specials: { holiday: "情人節", bundle: "暢銷款" }，這樣後續要搞促銷活動就不用改 schema。另外，訂單集合裡的狀態欄位，最好用數字而非文字，比如 0=待支付、1=已支付待配送、2=配送中、3=已完成、4=退款中，這樣在雲函數做條件查詢時效率更高。
購物車與訂單流程的坑
購物車看似簡單，實戰中卻最容易出問題。比如用戶切換設備後，本地 Storage 的購物車資料就丟了——原始碼裡用了 Base64 加密本地緩存，但其實更穩妥的做法是讓雲函數在用戶授權登入時，自動將本地購物車同步到雲端資料庫。我曾經做過一個案例，因為沒處理好同步，導致用戶在手機上下單的數量跟電腦上看到的不一樣，客訴一堆。所以建議實戰時，用戶每次操作購物車都觸發一下雲函數的異步同步，雖然多了幾毫秒的延遲，但數據一致性才是王道。
部署上線的最後一哩路
很多人以為寫完代碼就結束了，其實部署才是真正的考驗。原始碼提到「審核通過後發佈」，但實戰中審核可能因為「未完善用戶隱私協議」或「缺少售後入口」被打回。我通常會在個人中心放一個「意見反饋」和「退換貨政策」的鏈接，這些細節能讓審核順利很多。另外，雲開發的環境變量（比如呼叫微信支付的密鑰）一定要在正式發佈前配置好，而且切記不要把敏感信息寫死在代碼裡，我就曾見過有人把 AppSecret 直接放前端，結果被別人用工具抓出來，慘痛的教訓啊。
總之，這個鮮花小程序專案是很好的實戰入門，把這套流程跑通，後面做成衣、電器、甚至課程商城都不會太難。唯一要提醒的是，別急著塞太多功能，先把最基本的加購、下單、配送追蹤做好，用戶體驗遠比功能多更重要。
評論（7）
原生框架確實穩，之前用Taro踩過組件坑，後來還是切回來了。
雲開發不用管伺服器這點真的香，但價格呢？流量大了會不會很貴
「自訂欄位」這個建議實用，之前改schema改到崩潰
購物車同步那個坑我也踩過，用戶投訴到懷疑人生 😂
審核被打回過三次的人路過，隱私協議一定要提前放
沒寫過小程序，但看起來比我想的複雜…
最後那句話對，功能少但順比啥都強