一个移动互联网产品从上线到用户留存，80%的失败发生在未完成基础核查之前。某头部App曾因未校验弱网状态下的图片加载，导致首屏崩溃率飙升15%，次日留存暴跌至12%。这份编号51111的核查表，正是为了卡住这类致命漏洞而生。

一、网络环境兼容性：不能只测5G满格

某社交电商App在双十一期间，大量用户投诉“下单按钮失效”。排查发现，开发团队仅在Wi-Fi和5G网络下测试，而用户在地铁、电梯等弱网场景下，接口超时未设置合理回调。具体操作：必须模拟2G/3G、信号衰减、高延迟（如500ms+）环境，并验证“重试3次后弹窗提示”等降级逻辑。同时，对CDN资源（如图片、视频）设置加载失败时的兜底占位图，并记录异常日志以便快速定位。

二、用户权限与隐私：过度索取比拒绝更致命

某健身App在首次启动时强制要求“相册+位置+麦克风”权限，被监管通报后下架三天，损失超百万用户。正确做法：将权限请求拆解为场景触发式——比如用户点击“上传头像”时才请求相册权限，并附简短说明（如“仅用于设置头像”）。此外，必须确认权限拒绝后的功能降级方案：拒绝位置权限时，应默认显示“全国城市”而非直接闪退或空白页面。

三、支付与账户闭环：最后一个页面常被忽略

有用户反馈，支付成功后App跳转至空白页，导致其以为扣款失败而重复下单。核查要点：首先，支付回调必须覆盖“成功/失败/处理中”三种状态，并在支付成功页显示订单号+预计到账时间。其次，测试“支付中强制杀进程”后，重新打开App需能自动触发状态查询（如轮询3次后显示结果）。最后，确保第三方支付SDK的版本与苹果/安卓的更新策略兼容——某次iOS 17升级后，旧版支付宝SDK导致支付页面白屏，修复耗时2天。

四、数据埋点与错误上报：看不见的“体检表”

某工具类App上线后，运营发现用户活跃时长骤降，但常规测试均通过。深度排查才知，新版本未上报“启动耗时”数据，导致无法定位到某广告SDK阻塞主线程。建议：在核查表中加入“至少覆盖启动、登录、核心行为、崩溃四个场景的埋点验证”，并设置埋点成功率阈值（如低于95%自动告警）。同时，确保测试设备覆盖iOS 15-17、Android 10-14各主流版本——某家公司的崩溃仅出现在Android 13的特定厂商ROM上。

• 误区一：只测“成功流程”，不测“边界操作” 比如用户连续快速点击购买按钮、在弱网下切换应用再返回、拒绝通知权限后重复点击分享。这些场景未必触发代码异常，但极易导致用户体验断裂。
• 误区二：用真机代替所有模拟 真机测试无法覆盖所有系统版本和分辨率。至少需用模拟器测试Android 6.0以下系统（仍有10%用户在使用），并用云真机验证华为、小米、OPPO等定制ROM的权限弹窗差异。
• 误区三：忽略“数据回捞”的能力 上线后若发现某功能异常，而日志未上报设备型号、系统版本、网络类型等关键字段，修复将如同大海捞针。核查表中必须包含“日志携带设备指纹+时间戳”这条规则。