移动端开发中，70% 的上线事故源于“忘记核对某个隐藏配置项”——比如第三方 SDK 的隐私权限开关、不同安卓厂商的推送通道适配、或者 webview 缓存策略与后端接口不兼容。这些事故的平均修复时间超过 2 小时，而如果提前 10 分钟走完一份结构化核查表，完全可以拦截。

核对网络与数据层：少看“通不通”，多看“怎么断”

很多人只检查“接口能不能调通”，但真实场景是：用户在地铁隧道里，信号从 5G 掉到 2G 边缘。此时 app 应该展示什么？我在一个电商项目中踩过坑：核对表里只写了“网络请求成功”，上线后用户反馈“优惠券页面一直转圈”——因为团队没测网络切换时接口超时后的重试逻辑。

具体做法：在核查表里加 3 条——①弱网环境下（用 Charles 模拟 100ms 延迟+30% 丢包）每个核心接口是否触发降级展示；②断网后从后台切回前台，是否自动重试上次失败的请求；③WiFi 切换到 4G 时，长连接（如 WebSocket）是否重建。

核对权限与隐私：别信“弹窗弹了”，要看“用户点拒绝”

很多团队只测试“同意所有权限”的完美路径。去年有个社交 app 上线后被大量一星差评，原因是：用户拒绝了位置权限后，点击“附近的人”模块直接白屏崩溃。核查表本应在“权限申请”条目下注明：必须测试每一个权限被拒绝后的 UI 兜底状态。

更隐蔽的问题是“隐私接口调用时机”。某次合规审查中我们发现，app 在启动页就调用了 IMEI 读取接口，而隐私弹窗此时还没弹出——这违反了工信部规定。核查表应新增一条：用抓包工具确认所有敏感权限相关 API 调用，是否发生在用户明确授权 之后。

核对动效与性能：重点测“快速连续操作”

静态页面看不出问题，但用户的实际操作是：快速双击“发布”按钮、疯狂滑动列表、频繁切换 tab。我在一个内容社区项目里见过，用户快速连点“点赞”按钮，结果后端收到了 4 条相同请求，导致同一篇文章被点赞 4 次。核查表里必须包含：①按钮是否做防抖/节流；②列表快速滑动时是否频繁触发图片懒加载导致卡顿；③页面频繁进出是否造成内存泄漏（用 Xcode 或 Android Profiler 观察 10 次进入退出后内存是否持续增长）。

三个最常踩的核查误区

• 误区一：“测试机用最新旗舰机就行” —— 真实用户里 40% 在用 2 年前的中低端机型。建议：核查表里指定至少 1 台 3GB 运存、安卓 10 以下的老机型，重点测冷启动速度和动画掉帧率。
• 误区二：“只测线上环境，忽略 Mock 数据” —— 有团队上线后发现图片链接是内网地址。核查表应要求：所有图片、视频、JSON 数据的 URL 必须用线上域名，并在 staging 环境跑一遍完整路径。
• 误区三：“以为权限只需测一次” —— 某用户首次拒绝位置权限，第二次手动打开后，app 并未重新读取位置。核查表应注明：每种权限至少测试“拒绝→授权”“授权→拒绝”来回切换两次，且每次切换后都刷新页面状态。