在 Android 上选择 RevenueCat 还是原生…

当你需要在 RevenueCat 与直接接入 Google Play Billing Library 之间做选择时，用三张对照表厘清哪些工作被替代、哪些转移、哪些仍由自己承担。

适用场景

解决思路

1. 先明确评估意图：确认要比较的是 RevenueCat 与直接接入 Google Play Billing Library（PBL），并覆盖 Android 客户端以及支持订阅或一次性购买的服务器端基础设施。
2. 回答四个典型问题：采用 RevenueCat 后客户端哪些代码不再需要；它替代了哪些后端组件（收据验证、RTDN、状态机）；无论选哪条路自己仍需负责什么；是否存在只有原生 PBL 才能满足的需求。
3. 在阅读对照表前先定位关注点，把需求归入三类之一：客户端购买管道（BillingClient、监听器、确认、消耗）、服务器端购买真相（token 验证、RTDN、权益状态机）、两者都不覆盖（认证、用户数据库、付费墙 UI、推送）。
4. 若关注点被拆分（例如 RevenueCat 验证 token，但你仍需在 API 上控制高级内容），则集成胶水代码由你负责，即使验证本身已被处理。
5. 对照客户端职责表：BillingClient 设置与配置、连接生命周期与重连、PurchasesUpdatedListener、queryProductDetailsAsync()、launchBillingFlow()、购买后确认、消耗品消耗、启动时 queryPurchasesAsync()、瞬时错误重试逻辑、BillingResponseCode 处理、应用内支付恢复消息、订阅优惠选项选择——原生 PBL 下全部由你编写，RevenueCat 下分别由内部处理、替换为 purchase 回调、awaitOfferings()/awaitGetProducts()、awaitPurchase() 内部调用、自动确认、自动消耗（在 dashboard 标记为消耗品）、连接时内部处理、SDK 内部重试、抽象为 PurchasesErrorCode、自动（showInAppMessagesAutomatically = true）、自动选择 defaultOption。
6. 对照服务器端职责表：Google Play Developer API 集成、服务账号凭据管理、每次购买收据验证、购买 token 验证与去重、linkedPurchaseToken 链遍历、RTDN 处理与分发、Cloud Pub/Sub 设置、后端订阅状态机、跨 7 种状态的权益计算、宽限期/账号保留跟踪、取消后访问至到期逻辑、价格队列跟踪、产品到权益映射——原生 PBL 下全部由你构建或管理，RevenueCat 下分别由其后端处理、在 RC dashboard 一次性配置、自动验证、后端验证去重、后端遍历、处理并发送 webhook、无需设置、由 RC 计算 CustomerInfo、由 RC 计算 isActive、billingIssueDetectedAt、isActive + unsubscribeDetectedAt、RC 后端处理、在 RC dashboard 配置。
7. 确认无论选哪条路都仍由你负责的事项：用户认证系统（自带并将 user ID 传给 RC）、自己的用户数据库（RC 不是主用户库）、服务器端高级内容（通过 RC REST API 或 webhook 验证）、webhook 接收端点（RC 发送、你接收）、Play Console 产品创建、订阅延期（直接调用 Google Play API）、订阅撤销（直接调用 Google Play API）、替代计费计划（RC 支持有限，可能需原生 PBL）、应用 UI（付费墙、引导，RC Paywalls UI 可选）、支付问题推送通知（基于 webhook 事件自行构建）。
8. 应用推荐启发式规则一：若应用需要订阅延期、订阅撤销或 RevenueCat 尚未覆盖的替代计费计划，无论主选哪条路，都要为这些特定调用保留原生 PBL 路径。
9. 规则二：若你原本要从零构建收据验证服务、RTDN 管道和订阅状态机，服务器端表列出至少八项被 RevenueCat 消除的工作，除非有具体理由自建该栈，否则选 RevenueCat。
10. 规则三：若你已有成熟计费后端（已验证 token 和经过测试的状态处理），收益较小，需权衡 RevenueCat 的客户端简化与 dashboard 驱动目录。
11. 规则四：始终确认「仍由你负责」的事项已有人力覆盖；RevenueCat 不替代认证、用户数据库、付费墙 UI 或高级内容门禁，传递 appUserID 并通过 REST API 或 webhook 在服务器端验证权益仍由你完成。
12. 规则五：拿不准时，把每条需求映射到三张表之一；落在「仍由你负责」表中的事项在两种方案下成本相同，不应作为决策依据。
13. 使用快速判断门：需要自定义 RTDN 管道 → 只有必须端到端自建时才选原生 PBL；需要延期或撤销 → 为这些 API 调用保留原生 PBL 路径；需要快速上线 → 先选 RevenueCat，之后再添加原生 PBL 逃生通道。

适用边界 · 注意事项

• 当应用需要订阅延期、订阅撤销或 RevenueCat 尚未覆盖的替代计费计划时，不能完全依赖 RevenueCat，必须保留原生 PBL 路径。
• 当团队已有成熟计费后端（已验证 token 和经过测试的状态处理）时，采用 RevenueCat 的收益较小，不应仅凭对照表就切换。
• 不要指望 RevenueCat 替代认证、用户数据库、付费墙 UI 或高级内容门禁，这些始终由自己负责。