购买按钮在用户点击的那一刻冻结或报错,不是普通 bug,是 App Review 2.1(a) 级别的拒审理由——我见过两次,一次是按钮冻结,一次是点击报错,两次都发生在静态检查全绿的构建上:编译通过、付费墙正常渲染、购买 API 也确实被调用过。
为什么这类问题不可见:那些全是中间信号。金钱路径上唯一诚实的成功信号,是完整流程到达权益状态——交易完成、订阅生效、付费解锁的东西真的解锁了。任何更早的信号(构建绿、界面出现、API 被调用)都与"用户真正点的那一下失败"完全兼容。所以静态门禁全绿和这个缺陷共存不是矛盾,是结构性的必然。
通用的修复模式,顺序是承重的:
1. 先定义成功信号。断言权益状态真的到达,而不是某个 API 被调用、某个界面出现过。信号定错,后面做的全是白做。 2. 用端到端 UI 测试驱动真实流程:点真实的购买按钮,等 loading/价格占位符消失(等一个条件,不是固定 sleep——固定 sleep 会和商品加载赛跑),再断言解锁后的状态。 3. 失败时不要靠重试碰运气。复现失败的那一次,定位卡点:商品加载出来了吗?交易开始了吗?sheet 正常结束了吗?三个问题就能把缺陷钉在某一层。 4. 重跑通过只是一个样本,不是对失败那一次的结案。间歇性购买失败是缺陷按它自己的失败率被采样,不是 flake;当作 flake 重试过去,上线后它还会按同一个失败率发生。
一分钟自检:现在打开你的 app,点真实的购买按钮,别停在"面板弹出来了"——确认付费解锁的内容真的解锁了。再 grep 一遍你的测试,看断言的是权益状态,还是只是"按钮存在/sheet 出现"。如果是后者,这一类冻结对你就是不可见的。