同一份内测包，测试用户发来的截图里写着「请求失败」，你在自己手机上点同一个按钮却一切正常。这类问题最耗时间：不是必现，也没法靠猜。把手机上的网络请求完整记录下来，看它到底发到哪、带了什么、回了什么，通常半小时就能定位。下面按顺序走一遍。
先分清是「请求错了」还是「结果被改了」
抓包之前先做判断，避免白装一堆工具。
- 只有个别用户出错：优先怀疑网络环境、系统版本、账号权限。
- 同一用户必现、换个账号就正常：往鉴权和数据方向查。
- 所有人都出错：多半是服务端或配置问题，先看发布时间点。
- 报错文案与后端返回不一致：中间有层改写了响应，比如网关或客户端缓存。
把这四类分清，能省掉大量「先抓个包看看」的无效动作。
抓包前的三件准备
手机端抓包依赖代理，环境没配对时抓到的永远是空列表。
- 让测试包带一个「调试日志」开关，把请求地址、状态码、耗时打到本地文件。抓包只是补充，日志才是长期手段。
- 手机与电脑连同一个 Wi-Fi，在手机 Wi-Fi 设置里填入电脑的代理地址与端口。
- 首次抓 HTTPS 需要在手机上安装代理工具的根证书，并在系统设置里把该证书设为信任。iOS 还要在「关于本机」的证书信任设置里手动打开开关，这一步漏了会看到满屏 CONNECT 却没有内容。
再强调一句：代理只在测试机上开，测试结束立刻关掉，不要让代理配置留在用户设备上。
现象与请求特征的对照
抓到包之后，先按现象归类，再去看具体字段。
| 用户看到的现象 | 抓包里的典型特征 | 优先排查方向 |
|---|---|---|
| 一直转圈后超时 | 请求已发出，无响应或响应极慢 | 网络、CDN、服务端耗时 |
| 提示未登录 | 请求头缺少凭证或凭证已过期 | 登录态写入时机 |
| 部分机型报错 | 请求正常，响应体字段缺失 | 客户端解析兼容 |
| 同一按钮偶尔失败 | 重试后成功，状态码 5xx | 服务端并发或限流 |
这张表的价值在于把「感觉」变成可核对的线索：只要能抓到一条失败请求，剩下的事就是对比成功与失败那两条的差异。
让用户配合的最小动作
多数内测用户不愿意装证书、配代理，也不必强求。给他们三个动作就够：
- 记下出错时间点，精确到分钟。
- 截图完整报错，页面和弹窗都要。
- 说明当时的网络类型：Wi-Fi、移动数据，或是否开了加速器、公司内网。
有了时间点，服务端日志能直接捞到对应请求，比让用户描述「我点了几下」有效得多。
别忽略数据边界
抓包文件里可能有账号、手机号、地址等真实信息。测试阶段尽量用测试账号，抓到的包只在内部分享，不往公开群发，也不贴进需求文档。上传新包到 虾分发 做分发时，可以在应用说明里顺带写一句「如遇报错请提供时间点与截图」，能减少一半的来回沟通。
常见问题
| 问题 | 说明 |
|---|---|
| 抓包工具只显示 CONNECT 没有内容 | 多半是根证书未安装或未被信任，按系统路径重新确认一次 |
| iOS 上抓不到部分请求 | 系统组件的流量不走用户代理，属正常现象，优先看业务请求 |
| 内测包要为抓包单独打包吗 | 不必。保留调试日志开关即可，正式包关闭该开关 |
| 抓到 200 但页面仍报错 | 看响应体结构与解析逻辑，问题常在字段类型或空值处理 |
结语
「你这边正常、他那边报错」不是玄学，而是两套网络环境跑出了不同结果。先把现象分类，再按上面三步做准备，抓到一条失败请求后对比差异，多数问题当天就能有结论。
建议 团队把「调试日志开关 + 报错时间点」写进内测说明模板，要求测试用户在反馈时附上这两项，定位效率会明显不同。