事情起因并不复杂，一个 iOS 版本更新后，线上接口偶发失败，日志里只有模糊的错误码。代码回滚、重试都没法稳定复现，最后只能回到最原始的方式------看真实请求。
问题是，这个 App 已经上线，既不能加日志，也不能改网络层。
剩下的选择只有在真机上抓包。
在准备苹果手机抓包的时候，先别急着选工具
刚开始我也犯过一个错误，先找工具，再想怎么用。
后来发现更合理的顺序应该是反过来的------
先判断网络路径，再决定抓哪一层。
在苹果手机上，抓包需求大致会落在三个层面：
- HTTPS 请求是否正确发出
- 请求是否被系统代理接管
- 客户端对响应的处理逻辑
不同层面，用到的工具并不一样。
代理抓包仍然是最常用的一条路
在接口联调、参数校验这类场景里，HTTPS 代理抓包依然是首选。
Charles、Fiddler、Proxyman 都是这一类工具。
抓包大师的代理模式，本质上也是走系统代理，只是把证书和配置步骤做了整合。
在苹果手机上使用抓包大师做代理抓包的过程
我这次是在 Windows 上操作，流程大致如下：
- 用 USB 将 iPhone 连接电脑，保持解锁
- 打开抓包大师，在设备列表中选择当前 iOS 设备
- 切换到 HTTPS 代理抓包模式
首次使用时，软件会引导安装描述文件和证书。
证书安装完成后，只需要在 iOS 的 Wi-Fi 设置中，把代理模式切换为手动，填入软件提示的地址和端口。
整个过程和 Charles 的原理一致，只是省掉了手动导出证书的步骤。
什么时候你会发现抓不到包
很多时候开始抓包之后就出现问题
比如这次遇到的情况是：
- 系统接口能看到
- 业务接口完全没有
- App 内请求看起来消失了
这种情况，基本可以判断的是 App 没走系统代理。
这时，继续折腾代理已经没有意义
如果请求本身绕过了系统代理，再怎么检查证书、端口，结果都不会变。
我通常会直接换思路，去看设备层的数据流。
数据流抓包，用来确认有没有在通信
在抓包大师里，选择数据流抓包模式：
- 同样通过 USB 连接 iPhone
- 不需要配置代理
- 不依赖证书
开始抓取后，可以看到设备真实发出的 TCP、UDP 流量。
如果只关心某个 App，可以在开始前选择目标应用，过滤掉系统噪音。
这一层不关心 HTTP 结构，只回答一个问题：
这个 App 到底有没有在联网。
多工具协作，比换工具更重要
在这次问题里，我实际用的是一套组合：
- 代理抓包：确认哪些接口走系统网络
- 数据流抓包：确认隐藏请求是否存在
- 拦截器：验证客户端处理逻辑
没有哪一步是多余的。
拦截器在调试中的真实用途
当我重新在代理里捕获到部分请求后，下一步并不是马上改代码，而是先用拦截器做验证。
在抓包大师的代理界面右侧，可以打开拦截器，通过 JS 修改请求或响应。
比如：
- 强行返回错误状态码，看客户端分支
- 修改字段值，确认 UI 依赖
- 重定向请求，验证网络路径
这种方式的好处是成本极低 ，几分钟就能验证一个假设。
苹果手机抓包抓不到，其实可以不断换方向
回过头来看，这次问题并不复杂。
复杂的是，一开始把抓包当成了一个动作，而不是一个过程。
- 抓不到 HTTPS，不一定是证书问题
- 看不到请求，不一定是工具问题
- 工具失效，往往是路径判断错了