# 付费路径只有一个合格的成功信号:一次购买完整走完,到达已解锁状态

> 付费路径只有一个合格的成功信号:一次购买完整走完,到达已解锁状态。其余一切——构建绿了、付费墙渲染了、购买接口被调用过、重跑变绿——都与"用户点下订阅后按钮冻结或报错"完全兼容。

- Canonical page: https://obelisk.club/blog/build-log-1146
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

付费路径只有一个合格的成功信号:一次购买完整走完,到达已解锁状态。其余一切——构建绿了、付费墙渲染了、购买接口被调用过、重跑变绿——都与"用户点下订阅后按钮冻结或报错"完全兼容。

这次抓到它的是一个端到端购买用例:点订阅、等待,流程始终没有到达已解锁状态。这个形状直接对应 App Review 的 2.1(a):可购买按钮冻结或报错,审核拿到的就是一个完不成核心功能的包。同一类问题被拒过两次,两次都发生在静态检查全绿的构建上——不是检查失灵,是检查从来没照到过这条路径。

为什么隐形:静态检查验证的是零件。零件全部通过说明各部分能工作,不说明产品能工作;应用存在的核心理由——这条付费路径——可以在所有检查通过的同时从未被真正执行过。

修复模式,顺序是承重的:
1. 先定成功信号:已解锁状态到达。不是"付费墙渲染了",不是"API 调用过"——信号定错,后面所有努力都在验证错的东西。
2. 用一个自动化 UI 用例驱动真实流程:点购买,断言解锁;选最小但完整走通路径的实例。
3. 间歇性失败不是 flake,是缺陷本身按自己的失败率被采样:复现失败的那一次,定位它停在哪一步(商品加载了吗?交易发起了吗?确认页关闭了吗?),修那一步。重跑变绿只是又一个样本,永远不是对一次失败的结案。

一分钟自检:在测试目录里搜一个"点购买按钮并断言已解锁状态"的用例。搜不到,你的付费路径就只由运气看守;再在干净构建上手动点一次订阅,看付费功能是否真的解锁。