一个新应用的首个版本被拒，条款是 Guideline 2.1(b) — App Completeness:审核在真机上发现内购商品有问题。本地这边一切绿：构建通过、截图齐全、付费墙渲染正常。这类拒审值得记一笔，因为它的根因属于「所有盯着二进制的检查都天然看不见」的那一类。
为什么看不见：
- 内购商品不是二进制的一部分，它住在 App Store Connect 的另一张表里。READY_TO_SUBMIT 不等于「已附加到这个版本」：附加没有 API(调用会 409),提交时也不会自动打包。任何只看构建产物的检查，对它都无话可说。
- 付费墙渲染成功不等于购买能走通。StoreKit 未加载、沙盒账号已是已购状态、停在错误的屏幕——这些状态下截图照样漂亮；而审核员手指按下订阅按钮的那一下，才是唯一真正被检验的动作。
- 于是「应用不完整」落下来的地方，恰好是本地所有绿灯都说「完整」的地方。
修复模式，顺序即优先级： 1. 先核对状态，再改代码：打开版本页的内购区，数行数。零行 = 审核根本无法测试付费层，这就是 2.1(b) 的形状；商品列表页显示 READY_TO_SUBMIT 说明不了任何事。 2. 附加必须发生在提交之前，并当成提交流程里的显式步骤——正因为它是网页端的独占操作、自动化够不着，才最容易被「以为已经带了」。 3. 金钱路径只有一个验收信号：一笔购买完整走完并到达已授权状态。构建绿、付费墙渲染、购买 API 被调用过，全都与「订阅按钮一点就卡死」相容。
一分钟自检：打开 App Store Connect 的版本页 → In-App Purchases,数行数；再在沙盒里完整点完一次真正扣钱的购买，看不到 entitlement 落地就当它是坏的。两项都过，这一类 2.1(b) 才算关上。
至于拒审本身：记下条款号、读懂它实际说了什么、按上面的顺序修、在 App Store Connect 里回复后重提。2.1(b) 的信息量其实很高——它意味着审核员真的点过你的付费路径，这是很多本地指标都给不了的证据。