为什么外部测试邀请会卡住
TestFlight 外部测试的第一批测试员需要经过一次审核，很多人把它当成“走个流程”，结果邀请发出后长时间没有下文。实际经验是，卡住的原因往往不在邀请本身，而在提交审核前那几个容易被忽略的环节：构建版本、测试信息、隐私问卷。这三者只要有一处对不上，审核就可能要求补充说明甚至直接退回。
下面按提交顺序拆开讲，方便你在点“提交审核”之前逐项过一遍。
第一关：构建版本本身是否“可测”
外部测试审核看的是你上传的那个构建，而不是你本地跑通的版本。常见问题包括：
- 构建处理未完成：上传后需要等待处理，处理完成前无法加入外部测试组，急着提交只会反复失败。
- 缺少必要说明：首次提交外部测试时，需要填写测试内容说明，描述测试员要做什么、关注哪些功能。空泛的“测试 App”容易被要求补充。
- 登录或前置条件缺失：如果 App 需要账号才能进入核心功能，审核方拿不到可用凭据，就会卡在无法验证。建议在测试信息中提供可用的演示账号，或说明如何跳过登录。
- 崩溃与明显阻断：启动即崩、核心页面白屏这类问题，会直接导致退回。
另外，构建版本号不要重复使用，每次修复后重新上传并递增，避免审核方看到的是旧包。
第二关：测试信息要回答“测什么、怎么测”
测试信息不是营销文案，而是给审核人员看的操作说明。写得越具体，来回沟通越少。建议包含：
- 本次测试的目标功能，以及进入路径；
- 需要重点验证的场景，例如支付流程、推送、权限申请；
- 已知问题与暂不支持的机型或系统版本；
- 测试周期与反馈方式。
如果 App 内有需要特定条件才能触发的功能，比如定位、相机、蓝牙，最好说明在什么情况下会请求权限，以及拒绝权限后的表现。这一点和后面的隐私问卷直接相关。
第三关：隐私问卷要和实际采集对得上
这是最容易被低估的一环。隐私问卷里声明的数据类型，应当与 App 及其集成的第三方 SDK 实际采集行为一致。常见的不一致有：
- 问卷里没提，但统计 SDK 采集了设备标识或使用行为；
- 声明“不用于追踪”，但接入了跨 App 的广告归因 SDK；
- 申请了通讯录、相册权限，但问卷中没有对应说明。
建议在提交前，把工程里的依赖清单过一遍，逐个确认每个 SDK 会采集什么、是否联网、是否在后台运行。关于第三方 SDK 带来的合规与行为判定问题，可以参考站内这篇 第三方统计 SDK 过多带来的风险解析，思路同样适用于 iOS 侧的自查。
问卷填写时宁可如实多写，也不要为了“看起来干净”而漏报。漏报一旦被发现，处理成本远高于一开始就说明清楚。
邀请阶段还有两个细节
审核通过后，邀请方式也会影响测试员能否顺利加入：
- 公开链接与邮箱邀请：公开链接适合较大规模发放，邮箱邀请适合定向测试。两者都要注意名额与有效期管理。
- 测试员设备与系统版本：提前告知最低系统版本要求，减少“装不上”的反馈。
如果你同时在用 Ad Hoc 分发，注意两者的设备上限、有效期和安装体验差异很大，混用容易造成测试员困惑，可参考 Ad Hoc 与 TestFlight 的对比说明 再做分发规划。
提交前自查清单
- 构建已处理完成，版本号已递增；
- 测试信息写清了测试目标、进入路径与可用账号；
- 核心流程无崩溃、无阻断性缺陷；
- 隐私问卷与 App 及第三方 SDK 的实际采集一致；
- 权限申请场景在测试信息中有对应说明；
- 邀请方式、名额与有效期已规划。
把这六项过一遍，大多数外部测试审核的卡点都能提前消掉。真正需要反复沟通的情况，通常不是政策本身模糊，而是提交材料之间互相矛盾。