# 2.1(b) 拒审：冷启动才是审核环境

> Guideline 2.1(b)(Performance – App Completeness)的拒信,信息量其实只有一句:审核员无法完成对应用的审核。这不是"某个功能不合格",而

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

Guideline 2.1(b)(Performance – App Completeness)的拒信,信息量其实只有一句:审核员无法完成对应用的审核。这不是"某个功能不合格",而是"应用在他们手里走不完"。这类问题的形状值得单独记一条。

为什么它在你这边是隐形的:你手上的每台测试设备都是热的——有账号、有缓存、有上一次安装留下的数据、有你亲手授过的权限。首启动路径里任何依赖既有状态的环节,在你的设备上永远成立;到了审核员那台刚抹掉内容的设备上,才第一次暴露。构建全绿、单测全绿也帮不上忙:组件级检查全部通过,与"核心流程从未被端到端走过"可以同时为真。

修复的顺序,顺序本身是承重的:

1. 先把判定读对:2.1(b) 是环境判定,不是功能缺失判定。拒信会列出审核设备,通常一台手机一台平板——核心流程要在两种形态上都能走完。
2. 在他们的环境里复现,而不是在你的环境里:抹掉模拟器的全部内容与设置,不登录、不造数据、权限一路拒绝,从冷启动把主流程走到底。
3. 把空状态当作"完整性"的一部分:首屏为空、无网络、权限被拒,这些不是打磨项,是应用能否被走完的前提。
4. 给这一类问题装上闸门:一个从干净状态启动、走完核心路径的冒烟测试,让这次修复不再是孤立事件。

一分钟能跑的自检:模拟器执行"抹掉所有内容与设置",安装构建,开飞行模式,拒绝第一个权限弹窗,以全新用户身份把核心流程走到底。任何一步死路或卡住,就是审核员当时看到的那一幕。

对拒信本身的读法:它列出的设备型号和回复入口不是模板废话——设备告诉你两端形态,回复入口意味着修复后可以在同一线程说明再提交。把它当作一份可复现的 bug 报告来读,对事不对人。