App Store 的拒审里有一类不带缺陷清单：Guideline 5.6（开发者行为准则），审核暂停。它不指出哪一行代码有问题，只说这次提交达不到上架的质量标准，并给出一个日期，在那之前，回复和重新提交都不会被读取。我们遇到的这一次，日期是九天之后，标准的措辞是「有意义、精致、可靠」。
下面来自我们自己的送审记录。最有用的经验，是怎么给它分类。
它长得像拒审，其实是暂停
普通拒审会指出可修的东西，所以「修完重提」的条件反射是对的。5.6 不一样：消息自己写明了限制何时解除，和配额重置、冷却期是同一个形状。日期之前，无论提交哪个版本都不可能成功，更好的构建也绕不过去。
有两个推论：
- 日期之前不要重提。 提前重提不会被读取，还可能被看成无视暂停。把「尚未受理」和真正的失败分开计数，否则一串提前的尝试会伪装成在努力，把真实信号埋掉。
- 不要打补丁。 没有哪个具体 bug 可补。猜「不精致」指什么然后改代码，比不动更贵。
窗口期做什么
这个标准是一个真人在设备上几分钟得出的印象。构建、测试、lint 衡量的是零件能不能工作，不是整体是否有意义、精致、可靠，所以它们可以全绿，暂停照样来。窗口期应该花在判词真正指的东西上：
- 像陌生人一样审计。 在一台干净设备上装最近提交的那个构建，像从没见过这个应用的人那样走一遍核心路径：首启、空数据、断网、被打断后恢复。再看没人提工单的表面：空状态、错误文案、切换时的顿挫。
- 问朴素的问题。 给谁用？比他们已有的选择好在哪？你会把它装在自己手机上用一周吗？把商店页给项目外的人看十秒，问这两个问题。答案含糊，说明缺口在选题和完成度，不在构建流程里。
- 冻结自动提交。 把停止开关放在最终那次不可逆的提交调用之前，而不是上游某一环，否则换个入口就绕过去了。如果一个开关冻结不了所有提交路径，你的暂停只是约定，不是机制。
日期过后
用一次小而可控的提交恢复：先交最小、最有把握的那个。把积压的版本一口气全部重提，在对方看来很像重演触发暂停的行为。这一个过了，再放量。
一分钟自检
在干净设备上装你最近一次提交的构建，只走核心流程五分钟，数数有几个不敢拿给人演示的瞬间。如果你的底气全靠自动检查的绿灯，那正是这类判定生长的缝隙。
以上是 Obelisk Club 自己的送审记录。Apple 的措辞和做法会变化，具体条款和日期请以当前的 App Review Guidelines 和你收到的原文为准。