内测群里测试同学都说没问题，包一提审却被驳回，这种落差很多团队都遇到过。原因并不复杂：内测分发只验证装得上、跑得动，应用市场审核还要看主体资质、隐私与权限说明、功能是否完整。两套标准并不重叠，所以内测全绿，也不代表提审能过。

内测通过却过不了审，差在哪

两条链路的目标本来就不同：

• 内测分发看的是安装成功率、功能是否可用、有没有崩溃和卡顿。测试用户是自己人，对临时入口、演示数据容忍度高。
• 应用市场审核看的是主体资质、隐私与权限合规、内容合规，以及功能是否完整可交付。
• 内测包里的调试开关、测试账号、占位文案，测试同学看得懂，审核人员只会判定为尚未完成。
• 分发渠道能把包稳稳送到测试用户手里，但它替代不了审核，两者是并列关系。

五类最常见的驳回原因

1. 隐私政策缺失，或写的内容与实际收集的信息不一致，应用内还点不开。
2. 权限声明超出实际使用场景，申请了却没有对应的功能说明。
3. 功能不完整，留着测试入口、演示数据、内部版标识。
4. 首次启动崩溃、白屏，或必须登录后才看得到任何内容。
5. 应用名称、截图、描述与实际功能不符，更新说明写得含糊。

送审前自查清单

1. 版本信息：versionName 与 versionCode（iOS 侧对应 CFBundleShortVersionString 与 CFBundleVersion）去掉 beta 后缀，版本号只增不减。
2. 权限核对：打开 AndroidManifest.xml 或 iOS 工程配置，逐项对照功能，删掉没有使用场景的声明。
3. 隐私政策：应用内能打开、能复制链接，字段与真实收集项一致。
4. 清理痕迹：关掉调试日志开关，隐藏测试入口，删掉测试账号提示。
5. 冷启动走查：不登录、不连内网，从安装到首页完整走一遍。
6. 素材更新：截图、描述、更新说明与当前版本功能对齐。

内测阶段就能提前做的三件事

• 把权限弹窗文案和隐私政策链接写进内测检查项，别等提审才补。
• 用正式构建的包做一次完整回归，避免内测包能跑、正式包出问题。
• 建一份驳回记录表，每被拒一次就补一条自查项，下一版照着执行。

常见问题

小结

内测分发解决的是给谁测、怎么装，审核解决的是能不能公开下载。前者可以用 虾分发 这类平台，把安卓与 iOS 安装包合并成一个二维码发出去，测试链路会顺很多；后者只能靠送审前的自查，把问题挡在提交之前。两条链路都走通，版本节奏才不会被一次驳回打断。

建议 把上面的自查清单固化成提审前的一张检查表，指定一个人负责勾选，比每次靠记忆靠谱。