一个新应用的首次提审，拿到的是 2.1(a)——Performance: App Completeness。审核结论说发现了 bug，但没有说是哪个界面、哪一步、什么现象。这类拒审难的不是修，而是它把复现整件事留给了你。
好消息是消息里仍有几条可靠坐标：审阅设备(iPhone 17 Pro Max、iPad Air (M3))、被审的版本号、审核日期。它们不是客套话，是唯一能逐项对齐的复现变量。
为什么本地全绿、审核却是红的？因为两边的初始状态不同。本地测试永远是热的：开发者签名、已授予的权限、已有缓存和数据、迁移跑过的存储。审阅环境是全新安装、冷启动、无账号、无历史。住在首启路径里的 bug——首屏卡住、空数据态崩溃、首次请求失败后停在不可用的界面——在一切热的验证里都不可见。组件级检查全绿，与核心流程从未真正跑过，可以同时成立。
处理顺序，且顺序本身承重：
1. 先抄下消息里的环境字段：设备、系统版本、构建号。它们定义你要复现的世界，跳过它就等于换个世界找 bug。 2. 抹掉一台模拟器(Erase All Content and Settings),装同一个构建，以第一次使用的用户身份把核心流程从头走到尾：不登录、不预置数据、不跳步。 3. 复现了再修——没有复现的修复只是猜。确实复现不了，就在 App Store Connect 里回复这条消息，请审核给具体步骤或截图；消息本身就邀请回复，这是要数据，不是争辩。 4. 修完重新提交前，再冷启动一次：修复最容易顺手引入新的状态依赖。
一分钟自检：抹掉模拟器→全新安装→(若依赖网络)断网首启→只走应用存在的那一条主路径，看它在零状态下能否走通。再顺手问一句：你的自动化验证里，有没有任何一个用例是从冷启动、空数据开始的？如果答案是没有，2.1(a) 只是迟早，不是运气。
更一般的一条：绿灯证明的是零件，不是产品。核心流程是否真的被驱动过一次，要拿证据回答，不能由“周围都过了”推出。