StoreKit 的本地测试配置和内购目录漂移,是我见过最容易漏的一类不一致——因为两份文件各自都是"对的"。
这次的形状:一个 .storekit 配置文件里躺着一个 productId,商店后台记录的内购目录里却没有它。文件本身完全合法,Xcode 拿它跑购买流程一路绿灯;目录也完全合法。错的不在任何一份里,错在"这一对"——同一个对外契约的两份表示各自演化,互不通气,谁也不报错。
为什么隐形:绿色构建和它长期共存。本地测试读文件,商店读目录,日常循环里没有任何一步把两者对一遍。每份工件内部自洽,漂移就一直活着,直到审核或真实用户撞上一个买不了的付费墙——那是最贵的发现地点。
修法,顺序本身是承重的: 1. 先定真源。目录是事实——上架和审核测试的都是它;.storekit 只是它的镜像。动手前先回答"哪边是生成的",而不是"改哪边省事"。 2. 从真源机械地重新生成镜像,永远不手改镜像。手改的每一处都会被下一次生成冲掉,漂移就从"一处"变成"两个人的"。 3. 用双向 diff 当门禁:文件里有而目录没有的算错,目录里有而文件没有的也算错。单向检查只能抓一半,而漏掉的那一半(目录有、文件没有)恰好是审核最先撞上的。
一分钟自检:把 .storekit 里所有 productId 列出来,和商店后台的内购列表两个方向各对一遍。数量不等或 id 对不上,就是漂移;今天修,比上架后从拒审信里发现便宜一个量级。
这个形状远不止 StoreKit:本地 fixture 对服务端 schema、mock 对真实 API、生成的配置对权威元数据——全是"生成物 + 真源"描述同一份契约的组合。各自内部永远合法,错只在配对里。真源唯一、镜像机械生成、配对差异当成失败大声报出来,三件齐了,这类漂移的环才闭得上。