一、2.1 与 2.3 同时触发时，先保功能完整再调文案
如果 2.1（功能完整性）和 2.3（元数据一致性）一起触发，建议先修复会影响审核流程的功能问题，例如登录失败、关键页面空白、审核账号不可用，再统一改截图和描述。先做 2.3 再做 2.1，往往会重复返工。
- 先保证审核员“可登录、可操作、可走完核心路径”。
- 再让截图、描述、关键词与当前版本能力逐项对应。
- 最后补充提交说明，减少二轮解释成本。
App Store 拒审实操解读：重点在证据完整
App Store 审核常见“条款明确，但整改不被采信”的情况。核心原因通常不是没改，而是缺少可复现证据与结构化说明。
二、回复邮件不要泛写“已修复”，改成条款化说明
审核团队每天处理大量工单，越标准化的说明越容易过。建议按条款拆分为“问题位置、修改动作、验证方式、测试账号”，并给出最短复现路径。这样能明显减少“请补充说明”的往返。
- 问题位置：明确到页面和触发动作，不要只写模块名。
- 修改动作：避免“优化了逻辑”这类模糊表述。
- 验证方式：给出设备、系统版本、测试流程。
- 测试账号：提供有效账号与必要权限，避免审核中断。