每年因交易ID混乱导致的收入对账错误，让全球开发者损失数百万美元。而StoreKit 2的续费机制，正是最容易踩坑的盲区。
事件还原：一次续费，ID怎么变了
2021年苹果推出StoreKit 2时，承诺了更简洁的收据系统。但开发者很快发现一个反直觉的设计：用户首次订阅时生成原始交易ID（originalTransactionId），此后每次自动续费都会产生全新的交易ID（transactionId）。
这意味着同一位用户的连续12个月订阅，在系统里呈现为12条独立记录。如果后端按交易ID去重统计，活跃用户会被严重低估；如果按原始ID合并，财务对账又会遗漏单笔流水。
Restore的坑：ID再次"分裂"
更隐蔽的场景是用户恢复购买（restore）。当用户换设备或重新安装App后触发恢复，StoreKit 2会返回一组历史交易——但这些交易的ID序列可能与首次上报时不一致。
一位开发者曾在论坛描述：「我们发现有用户显示3次年度订阅，实际是同一份订单的重复恢复。」跨设备场景下，服务端必须建立原始ID与用户账号的映射表，否则极易重复发放权益。
苹果的意图与开发者的代价
这种设计并非漏洞。苹果将每次扣费视为独立金融事件，符合财务审计的颗粒度要求。但代价转嫁给了开发者：需要维护两套ID的关联逻辑，处理边缘 case 的测试成本陡增。
对比旧版StoreKit，收据是一整张Base64字符串，虽臃肿却保证了单一数据源。StoreKit 2的JSON化改造提升了可读性，却引入了分布式一致性的新难题。
为什么这件事现在更重要
订阅制正在吞噬移动应用的收入结构。Sensor Tower数据显示，2024年非游戏类订阅收入占比已达67%。当续费成为常态，交易ID的治理就从技术细节升级为财务基础设施。
StoreKit 2的异步更新机制（异步更新机制：后台自动推送交易状态变更）进一步放大了风险——服务器可能在任意时刻收到历史交易的补发通知，没有幂等性设计的系统会直接崩溃。
你的内购系统，现在能正确处理同一原始ID下的第47次续费吗？
热门跟贴