作为处理过多次内购跨设备同步问题的开发者，我来分享下实际项目里的落地方案和同行通用的思路：

一、先解决核心痛点：绕过本地缓存，直接从服务器拉取购买记录 #

你提到的queryPurchases仅查询本地缓存确实是问题根源，但现在的BillingClient API已经提供了官方的绕过方案：

• 用queryPurchasesAsync替代旧版queryPurchases，调用时设置forceRefresh = true。这个参数会强制BillingClient向Google Play服务器发起请求，直接获取最新的购买记录，完全跳过本地缓存。这是目前解决同步延迟最直接的方法。
• 在应用内添加**「恢复购买」按钮**，让用户主动触发同步。点击按钮时调用restorePurchases方法，该方法会请求Google Play返回当前账号下所有有效购买（包括一次性内购），返回结果包含完整的购买信息，包括purchase token。

二、没有Purchase Token时的验证方案 #

如果用户换设备后，连BillingClient都返回不了purchase token，可以从两个方向处理：

1. 提前将Purchase Token存储到自有后端 #

当用户首次购买成功时（客户端收到PurchasesUpdatedListener的成功回调），把purchase token和用户的唯一标识（比如你的APP内用户ID、Firebase Auth UID，或是用户的Google账号ID）绑定，同步存储到你的后端服务器。

用户换设备登录后，通过用户ID从后端取出对应的purchase token，再调用Google Play Developer API的purchases.products.get接口验证购买有效性——这是跨设备验证最可靠的方式，完全不依赖客户端缓存。

2. 处理未登录用户的极端情况 #

如果你的APP不需要强制登录，可以用用户的Google账号ID作为唯一标识（通过Google Sign-In获取），将purchase token与该ID绑定存储。用户换设备后，只要登录同一个Google账号，就能通过这个ID拉取对应的purchase token完成验证。

如果用户既没登录APP账号也没登录Google账号，这种情况只能引导用户登录——毕竟Google Play的购买是绑定Google账号的，没有账号标识就无法定位到对应的购买记录。

三、同行的通用解决流程 #

大多数做内购的APP都会遵循这套标准流程：

• 客户端初始化BillingClient时，优先调用带forceRefresh=true的queryPurchasesAsync，获取最新购买状态。
• 购买成功后，立即将purchase token和用户ID上传到后端存储，同时在后端调用Google Play Developer API验证购买合法性（防止客户端篡改本地状态）。
• 提供「恢复购买」入口，让用户在遇到权限问题时主动触发同步。
• 跨设备验证时，优先通过后端查询用户对应的purchase token，再调用Developer API验证，而非完全依赖客户端的BillingClient查询。

四、关于“绕过Google Play缓存验证”的补充细节 #

• 彻底放弃旧版无参数的queryPurchases方法，它仅读取本地缓存，已被官方逐步淘汰。
• 客户端验证仅作为快速判断，最终的合法性验证必须放在后端。客户端的本地状态可被篡改，而后端调用Google Play Developer API的验证是权威的。
• 处理网络异常：强制刷新需要网络支持，要给用户友好提示（比如“网络不佳，请稍后再试”），避免用户产生困惑。

内容的提问来源于stack exchange，提问作者EndOfAll