换了手机，买过的会员就没了？应用内购买恢复实战

先说判断：恢复购买不是“找回订单”，是“重新确认权益”

几乎每个做过付费 App 的团队都收到过同一封客服邮件：“我换了新手机，之前买的会员怎么没了？”用户说这句话的时候，心里想的不是收据、订单号或者交易凭证，想的只有一件事：我花过的钱，还算不算数。很多团队的第一反应是去查订单：订单在，钱收到了，系统没问题。但用户要的根本不是“订单在”，而是“我的 Pro 还在”。查订单这个动作，回答的是财务的问题，不是用户的问题。

我的判断先摆出来：恢复购买的本质不是“找回一笔交易”，而是“用商店的凭证，重新确认一次用户现在拥有什么权益”。这个定义里有三个关键词，一个都不能少。第一，凭证来自商店，不是用户嘴上说的“我买过”，也不是客户端本地存的一个布尔值。第二，确认发生在服务端，客户端只负责展示结果，不负责下结论。第三，确认的是“现在拥有什么”，不是“曾经买过什么”——订阅过期了、退款了、家庭共享到期了，曾经买过和现在拥有是两回事，恢复必须按现在的状态给答案。

以下例子里出现的产品“青禾冥想”与人物、数字均为虚构，仅用于说明恢复流程的设计方法；商店规则的表述为公开平台做法的通用概括，不针对某一时点的具体条款版本号。

第一步：先搞清两家商店的分工，别把两套规则混成一套

苹果和谷歌的恢复机制，思路相似、细节处处不同，混成一套写代码，迟早要在某一边翻车。苹果这边，应用内购买的恢复有一条审核层面的硬要求：提供自动续订或非消耗型购买的应用，必须在界面上给用户一个显眼的恢复入口，不能只在客服话术里写“请联系我们”。恢复时走的是系统提供的权益查询：用当前登录的 Apple ID 去问商店，这个账号现在拥有哪些有效权益，再把结果同步回自己的服务端。关键点在于“当前登录的账号”——用户换了 Apple ID，商店就查不到旧购买，这不是 Bug，是商店的账号模型决定的。

谷歌这边，恢复的动作更多发生在应用启动时：通过 Play Billing 重新查询用户在该应用下的购买记录，包括一次性购买和订阅。查询回来之后，应用要按购买类型处理：消耗型购买用完要消耗掉，非消耗型购买和订阅要做确认，并且把有效状态写进服务端。谷歌还有一条容易踩的线：购买之后如果不做确认，超过一定时间会被系统自动退款。也就是说，恢复不是“查一次就完事”，而是“查到购买之后，必须把确认和权益写入做完整”，否则用户明明付过钱，权益却会在几天后悄悄消失。

还有一类购买最容易被忽略：家庭共享。苹果的家庭共享允许家人共享符合条件的购买，但“可以共享”和“已经共享”是两回事，取决于购买者有没有打开共享、以及该商品类型支不支持共享。用户说“我家里人买的，我怎么没有”，先别急着修代码，先问清三件事：买的是谁的账号、商品支不支持共享、共享有没有打开。十次里有八次，答案不在代码里，在设置里。

第二步：服务端一张权益表是唯一真相，客户端只做展示

恢复购买最常见的架构错误，是把“用户是不是 Pro”存在客户端本地。写在本地存储里的一个布尔值，换手机就没了，清数据就没了，改时间、改包名、伪造请求都能绕过。更糟的是，客户端和服务端各存一份，两个地方不一致的时候，谁也不知道该信谁，用户夹在中间，客服也说不清。

正确的做法是：服务端维护一张权益表，作为唯一真相。这张表至少有五列：用户是谁、权益是什么（比如 Pro 会员）、从哪家商店来的、有效期到什么时候、凭证是什么时候校验的。恢复的流程就变成一条直线：用户点“恢复购买”→ 应用拿商店凭证去问商店 → 服务端拿着凭证再去商店校验一次 → 校验通过，按商店返回的最新状态写权益表 → 应用按权益表展示结果。客户端从头到尾不下结论，只负责把用户的点击传上去、把服务端的结论展示出来。

这条直线里有两个细节值得单独说。第一，服务端校验不能省。只信客户端传回来的“商店说我买过”，等于把收银台交给顾客自己看管。商店提供了服务端校验的接口，就是给开发者用的，不用就是主动留门。第二，恢复必须是幂等的。用户紧张的时候会连点三次“恢复购买”，网络抖动的时候请求会重发两次，权益表必须保证：同一个购买恢复多少次，结果都一样，不会多发权益、不会多扣次数、不会写出三条重复记录。幂等不是优化，是恢复流程的底线。

第三步：五种翻车现场，每种都有对应的判断句

恢复失败很少是因为代码写错了，大多数时候是因为现场和代码假设的不一样。把五种最常见的翻车现场写成判断句，客服和开发对着同一张表查，定位速度会快一个数量级。

第一种，换了商店账号。用户以前用 A 账号买，现在手机登录的是 B 账号，商店按 B 账号查，自然查不到。判断句是：“恢复时登录的商店账号，和购买时的是同一个吗？”处理办法不是修代码，而是告诉用户切换回购买时的账号再点一次恢复，并且在恢复失败的提示里就写清这一点，而不是只写“未找到购买记录”。

第二种，家庭共享没打开。购买者是家人，共享没开，或者该商品类型不支持共享。判断句是：“购买者是谁？共享开关开了吗？”处理办法是给用户一条能自己走通的路：去购买者的账号设置里确认共享状态，而不是让用户在自己的手机上反复点恢复。

第三种，沙盒账号残留。测试时用沙盒账号买过，沙盒购买会一直挂在测试设备和测试账号上，正式环境查不到，正式账号也恢复不了。判断句是：“这台设备登录过沙盒测试账号吗？”处理办法是测试流程里定一条规矩：沙盒测试用专用设备和专用账号，测完退出登录，并且把“沙盒残留”写进测试清单，发布前逐项清掉。

第四种，订阅已经过期、退款或者处在宽限期。用户记得自己“买过”，但订阅上个月就到期了，或者已经退款了。恢复按现在的状态给答案：过期就是过期，退款就是没有权益。判断句是：“商店现在返回的有效期到什么时候？”处理办法是：恢复结果页要把有效期明明白白写出来，“Pro 会员有效期至 2026 年 12 月 3 日”，而不是只写“恢复成功”四个字。用户看到日期，自己就能判断对不对。

第五种，跨平台。用户在 iOS 上买的 Pro，换到安卓手机上想继续用，或者反过来。判断句是：“购买发生在哪家商店？”商店的购买记录只在自家生态里有效，苹果的收据到谷歌那儿用不了。处理办法是在产品层面先定好规则：跨平台权益要不要打通、打通靠什么（通常是账号体系，用户用同一个账号登录，服务端按账号合并权益）。这条规则必须在购买前就告诉用户，而不是等用户换了手机才发现两边不认账。

第四步：恢复入口要放在用户找得到的地方，文案要说人话

很多产品的恢复入口藏得像个彩蛋：设置 → 账户 → 订阅管理 → 更多 → 恢复购买，四级菜单点进去，用户在第二级就放弃了。更糟的是有些产品根本没有入口，客服话术里写“请删除重装再试”，把恢复流程外包给了用户的耐心。苹果的审核要求只是底线，底线之上，入口应该放在用户第一眼就能看到的地方：设置页的订阅区域，直接放一个“恢复购买”按钮；付费墙上如果用户已经是会员，也应该直接显示会员状态，而不是再推销一次。

按钮的文案就叫“恢复购买”，不要发明新词。“同步订阅状态”“验证历史订单”“找回会员权益”这些词，用户一个都看不懂。恢复过程中要给进度：点下去之后，按钮变成“正在恢复…”，不要让用户对着一个毫无反应的界面猜它到底在干嘛。恢复失败的时候，给原因加下一步，不要只给一个“恢复失败”的弹窗。好的失败提示长这样：“没有找到用当前 Apple ID 购买的记录。如果你用另一个账号购买过，请切换账号后重试。”用户看完就知道下一步该干什么，不用再写邮件问客服。

还有一个细节：恢复成功之后，不要只弹一个 Toast 就完事。成功页应该写清三件事：恢复了什么权益、有效期到什么时候、如果不对该找谁。这三行字既是给用户的确认，也是给客服省下的三封邮件。

第五步：测试清单——沙盒里没测过的恢复，上线就是赌博

恢复流程的测试有一个特点：正常路径谁都会测，翻车路径只有清单能兜住。我的测试清单有六条，每条对应一个真实用户场景。第一，沙盒账号全流程：用沙盒账号买一次、恢复一次、再换一台设备恢复一次，三次结果一致才算过。第二，过期后恢复：订阅到期之后点恢复，结果应该是“没有有效权益”，而不是报错或者错误地给回权益。第三，退款后恢复：退款之后点恢复，权益应该被收回，并且提示写清原因。第四，换账号恢复：用 B 账号点恢复，应该找不到 A 账号的购买，并且提示用户切换账号。第五，断网时点恢复：提示应该是“网络不可用，请检查后重试”，而不是转半天圈最后报一个看不懂的错误码。第六，重复点恢复：连点三次，结果只有一条权益记录，界面只展示一次成功。

这六条测完，还要测一类最容易漏的：恢复之后的状态同步。用户在手机上恢复成功，打开平板看一眼，平板上的会员状态还是旧的。权益表写在服务端，平板下次打开时重新拉一次就好了；但如果平板用的是旧缓存，缓存的过期时间就必须比权益变化的频率短。我的做法是：权益相关的缓存只做内存级、不做长期磁盘缓存，打开应用先拉一次权益，再渲染付费墙。多一次请求，少一类“明明恢复了，平板上还是免费版”的工单。

第六步：把恢复失败当作最高优先级的工单来处理

恢复失败的用户，是付过钱的用户。他们遇到问题时的情绪，和免费用户遇到 Bug 完全不同：免费用户遇到 Bug 会关掉 App，付费用户遇到“我的会员没了”会觉得自己被骗了。所以恢复失败的工单，优先级应该提到最高：客服先回、开发先查、不要让用户等三天。

客服定位可以用三问法，一分钟问清现场。第一问：“购买时用的是哪个商店账号？”第二问：“现在登录的是同一个账号吗？”第三问：“购买的是什么商品，大概什么时候买的？”三问问完，前面五种翻车现场基本能定位到一种。客服话术里不要出现“请您耐心等待”这种空话，要给用户一个明确的下一步：“请切换到购买时的账号，再点一次设置页的恢复购买，如果还不行，把订单号发给我，我直接帮你查。”

数据上要记两个数。第一个是恢复成功率：点恢复的用户里，有多少一次就成功。低于九成，说明入口、文案或者流程里有系统性的坑，要排期修，不是靠客服一个个解释。第二个是失败原因分布：换账号占多少、过期占多少、家庭共享占多少。分布会告诉你下一个版本该修什么：如果换账号占了一半，下一版就应该在恢复失败页直接写“切换账号重试”；如果过期占了一半，下一版就应该在购买前把“订阅有效期”的说明写得更清楚。恢复失败不是客服的负担，是产品最诚实的用户反馈。

落地清单：上线前先过这十条

最后给一份可以直接拿去对照的清单。第一，恢复入口放在设置页订阅区域一眼能看到的地方，按钮就叫“恢复购买”。第二，恢复流程走服务端校验，客户端不下结论，权益表是唯一真相。第三，恢复幂等，同一个购买恢复多少次，结果都一样。第四，恢复结果写清权益内容和有效期，不要只写“恢复成功”。第五，失败提示给原因加下一步，换账号的场景直接提示切换账号。第六，家庭共享、跨平台、沙盒残留三类场景，购买前和恢复失败时都有对应的说明。第七，六条测试全过：沙盒全流程、过期后、退款后、换账号、断网、重复点击。第八，权益不同步问题有解：打开应用先拉权益再渲染付费墙，不做长期磁盘缓存。第九，恢复失败的工单最高优先级，客服三问法一分钟定位现场。第十，记恢复成功率和失败原因分布，低于九成排期修，按分布决定下一版改什么。

还有四个反模式，见到就改。第一，只在客户端判权益：本地布尔值一清就没，换手机就丢，还能被伪造。第二，不做服务端校验：只信客户端传回来的购买信息，等于把收银台交给顾客自己看管。第三，不做幂等：用户连点三次，权益表里多出三条记录，客服对账对到崩溃。第四，把恢复藏起来：没有入口、或者藏在四级菜单里，等用户写邮件来问，信任已经掉了一半。

恢复购买做得好不好，用户平时根本感觉不到——它只在用户最焦虑的那一刻出现：换了手机、重装了应用、会员突然不见了。那一刻产品给出的答案，决定了用户是觉得“这钱花得值”，还是觉得“这家以后别想再让我付钱”。把恢复当成产品的一部分来设计，而不是上线之后才想起来的客服补丁，就是这篇文章想说的全部。