内购验收：本地配置、Sandbox 与 TestFlight
只测一次成功购买，会漏掉恢复、续费、撤销和网络失败等最容易造成用户损失的路径。
用你的前端经验理解
可以用支付测试环境的思路理解。Xcode StoreKit 测试更可控，Sandbox 更接近真实商店链路，但它们不是生产交易。
为什么需要它
内购测试必须覆盖支付之外的交付、恢复和生命周期。Xcode 的本地 StoreKit 配置适合快速制造状态，Sandbox 用来验证测试商店链路，TestFlight 用来接近真实分发环境。一个环境通过不能证明商品配置、后端通知和生产行为全部正确，测试证据要写明环境。
它是怎样工作的
测试矩阵可按商品类型、交易结果和应用时机组织。取消与待处理不应发放权益，验证失败不能解锁，重复交易不得重复记账，重启和换设备应恢复可恢复权益。订阅测试时间可能加速，不能把测试中的续订间隔硬编码进业务；应读取可信交易的实际时间信息。
把关键概念连起来
本地可控测试
StoreKit Configuration 用于本地商品与交易场景，便于练习取消、待处理、退款、时间推进和续费。它不代表 App Store Connect 商品或生产通知已经配置正确。
完整链路
Sandbox 与 TestFlight 用于测试适用的真实商店交互；订阅周期与环境规则不同于生产。核对商品、应用身份、测试账号和通知环境，不混用测试与正式权益。
验收矩阵
覆盖首次购买、重复点击、取消、pending 后成功、验证失败、断网重试、重装恢复、关闭续订、到期、退款、切业务账号、重复通知和应用被中断后的恢复。
恢复购买必须真的恢复
购买非消耗型功能后重新安装应用，在对应购买账号下获取当前已验证权益，应再次解锁。消耗型余额按你自己的可靠账本恢复，不能假定 currentEntitlements 会重建全部历史点数。
为上线前的会员功能做一轮验收
- 先本地验证界面状态：商品加载失败、购买取消、pending、成功和验证拒绝，确保每种结果可退出或重试。
- 再联通测试服务端，购买后断网或杀进程，确认重新启动能够完成交付，不丢订单也不重复加额度。
- 最后在分发测试包中验证已有用户恢复、账号切换、订阅到期与退款相关事件，记录商品 ID 和测试环境。
这里需要你亲自判断
本地 StoreKit 测试通过不能替代 Sandbox 的服务端验证；也不能因为 Sandbox 能购买就宣称生产审核、商品售卖配置都已完成。
做一个小练习
用“带账号的会员应用”实战任务单完成本地测试，再列出 Sandbox/真机需要补证的项目。
- 写出至少包含取消、延迟批准、重复投递、重启恢复和过期的验收表。
- 给每项记录输入事件、预期权益、实际结果和失败证据。
展开参考思路与验收标准
验收通过意味着支付状态与真实可用能力一致，而非系统付款弹窗能打开。测试配置不能代替真实商店元数据；上线前仍需核对商品状态与生产服务配置。