iOS StoreKit 2 购买状态与订阅恢复

摘要：应用内购买涉及交易验证、权益更新、退款和跨设备恢复。本文介绍交易状态处理、权益建模、持久化边界和用户可见反馈。

一、把商品和权益分开

商品是用户购买的具体项目，权益是应用允许用户使用的能力。界面不应简单地把“曾经点击购买”视为永久权益。应基于经过验证的有效交易和订阅状态决定访问权限。

将商品标识映射到明确权益，避免价格展示和功能授权混在同一段界面逻辑中。

二、处理交易结果

购买可能成功、等待批准、被取消或失败。取消通常是用户选择，不应显示成系统故障。等待状态要给出清楚反馈，并在交易最终变化时更新权益。

交易数据需要验证后再应用。客户端可以读取平台交易状态；需要跨平台账号或服务器权益管理时，也可由服务端验证。

三、确认与重复处理

交易更新流可能包含此前已处理的状态。处理逻辑应幂等，避免重复发放同一权益。完成交易前应确保业务动作已持久化，避免确认成功但权益未落库。

应用启动时检查当前有效权益，并持续监听后续交易更新，包括退款或订阅续期变化。

四、恢复与跨设备

恢复购买应验证当前账户下可恢复的有效交易，并清楚反馈结果。若没有可恢复购买，也要区分“确实没有”和“暂时无法验证”。

本地缓存可改善启动展示速度，但不能成为长期授权的唯一依据。缓存过期或账户切换时需要重新校验。

五、处理订阅生命周期

订阅可能续期、过期、进入宽限期或被用户取消续订。取消自动续订不一定表示当前权益立即终止。界面应依据有效期和状态说明用户当前仍可用的时间。

价格、周期和续费条件在购买确认前清楚展示。不要通过默认选中或隐藏信息让用户误解订阅行为。

六、测试状态转换

使用沙盒购买场景验证成功、取消、等待、退款、续订和过期。业务权益计算应与购买框架调用分离，以便用固定交易状态做单元测试。

七、总结

购买系统应将验证后的交易转换成明确权益，并能安全处理重复更新、退款和订阅状态变化。恢复流程要给出可理解结果，本地缓存只能作为展示优化。