FlutterFlow+RevenueCat搭建訂閱系統(tǒng)：從支付到權限的完整鏈路

做訂閱制應用最煩什么？不是寫代碼，是處理蘋果和谷歌兩家的支付規(guī)則。每次審核被拒，理由都和訂閱流程有關。直到我發(fā)現(xiàn)這套組合：前端用FlutterFlow拖拖拽拽搭界面，后端交給RevenueCat統(tǒng)一管支付，F(xiàn)irebase存數(shù)據(jù)。三樣東西拼起來，居然能跑通完整的訂閱閉環(huán)。

先說說為什么非得用RevenueCat。直接接App Store和Play Store的SDK不是不行，但兩套API、兩種沙盒環(huán)境、兩份審核指南，光是測試就要瘋。RevenueCat把兩邊包成一套接口，購買、驗證、續(xù)訂、退款，全走它的服務器。你只管調一個方法，剩下的它跟蘋果谷歌扯皮。

整個系統(tǒng)的骨架是這樣的：用戶在前端點按鈕，RevenueCat SDK彈出原生支付頁，錢扣完之后它的服務器做驗證，然后發(fā)一個webhook到你的Firebase Cloud Function，最后把訂閱狀態(tài)寫進Firestore。用戶下次打開App，讀Firestore就知道自己是不是會員。

關鍵在第六步——webhook觸發(fā)后的處理。RevenueCat會往你的Cloud Function發(fā)事件，類型包括購買成功、續(xù)訂、退款、訂閱過期。每個事件都要對應更新Firestore里的用戶文檔。我的做法是建三個集合：users存當前狀態(tài)，subscriptions存套餐配置，events存操作日志。events那個集合尤其重要，萬一用戶來扯皮說"我明明付錢了"，有這條記錄就能對賬。

這里有個坑：千萬別信前端傳來的"isPremium": true。有人拿抓包工具偽造響應，直接解鎖會員。所有權限判斷必須走Cloud Function查RevenueCat的API，確認這筆訂單真的有效。前端只負責展示，后端才是守門員。

性能方面也有講究。Firestore按讀取次數(shù)收費，每次進會員中心都拉全量歷史記錄，賬單會很好看。我的做法是：只在用戶文檔里存"當前是否有效"和"過期時間"，用實時監(jiān)聽盯這一行。其他信息比如歷史訂單，點"查看賬單"再懶加載。另外把訂閱狀態(tài)緩存到本地，減少重復調API。

最后說UI。訂閱頁面的轉化率差一個百分點，月收入可能差幾千刀。我的習慣是：首屏只放兩個選項，月付和年付，年付標上"省30%"；按鈕文案不用"購買"，用"解鎖全部功能"；價格旁邊加一行小字"隨時取消，無額外費用"，降低決策壓力。這些細節(jié)不是玄學，RevenueCat的后臺能看到A/B測試數(shù)據(jù)，哪個版本轉化高一目了然。

這套方案跑下來，從搭頁面到上架大概兩周。FlutterFlow省了寫UI的時間，RevenueCat省了接支付的時間，F(xiàn)irebase省了搭服務器的時間。但省下來的時間，建議花在訂閱策略上——什么時候彈付費墻、給多少免費試用、過期后怎么挽回，這些才是賺錢的關鍵。