做开发多年，调接口已经是家常便饭，而调错接口也成为了家常便“坑”。
前端说“我发了请求啊”，后端说“我没收到”，这类“扯皮”每天都在上演。中间有什么问题？请求没发出去？发错地址？参数漏了？TLS失败？这些都无法只靠代码或日志来解决——这时候，抓包工具就是最直观的利器。
抓包工具不只是调 Bug，它也是“学习镜子”
很多开发者对抓包工具的第一印象是调错工具，但它真正的价值远不止如此：
- 可以复盘线上请求，看前后端是如何配合的
- 可以学习第三方产品的接口结构
- 可以验证自己的接口设计是否简洁一致
- 可以重放请求回溯偶发问题
- 甚至可以模拟攻击场景提前测试安全防护
下面结合我的日常开发经验，谈谈使用过的一些抓包工具：
一、Charles 抓包工具（Mac/Win通吃）
Charles 是我们团队内部使用最多的工具之一，界面直观、功能齐全，特别适合移动端请求分析。通过设置代理+证书信任，可以完整抓取 iOS 和 Android 端所有 HTTPS 请求。
场景案例：移动支付系统接口调试
有一次在接入第三方支付 SDK 时，App 端偶尔返回“支付失败”，但日志显示请求成功。我们通过 Charles 抓包分析，发现 SDK 在重定向后请求了一个废弃的 API 地址，导致响应体结构不一致而被解析失败。这个问题在 Charles 的 Session 重放中被复现出来，从而推动 SDK 方修复了问题。
- 特点：支持断点修改请求、重写响应、模拟带宽、图形化视图清晰
- 支持平台：macOS、Windows
- 官方中文站：charlesproxy.net/
二、Fiddler：老牌 Windows 党最爱
Fiddler 是 Windows 平台历史悠久的抓包工具，它的优势在于规则自定义能力，比如你可以用它实现复杂的请求条件转发。
我们曾在测试环境里用 Fiddler 做过一套自动响应返回模拟系统，前端在调用某些接口时，根据路径自动返回不同结构的 JSON，完全不依赖后端启动。这种“前端先走起来”的节奏，加快了整体开发速度。
- 优点：功能强大，规则灵活，插件丰富
- 缺点：界面稍显老旧，对 macOS 用户不友好
三、Wireshark：网络底层利器
Wireshark 更多用于底层协议抓取，比如 TCP、UDP、TLS 握手、DNS 查询等。我们在一次混合开发项目中，需要排查一个在弱网下请求失败的问题，发现是 TLS 握手失败导致的，而这个过程用 Charles 和 Fiddler都无法抓取，但 Wireshark 把每个 TCP packet 都记录了下来。
- 用途：协议分析、DNS问题排查、安全研究
- 缺点：数据量庞大，不适合日常应用调试
四、mitmproxy：终端党福音
喜欢命令行的开发者，大多会偏爱 mitmproxy，脚本能力极强，可以集成进自动化流程中。我们在一次 API 压测任务中，用 mitmproxy 写了个 Python 脚本，自动重放 1000 次 API 请求并分析响应耗时，快速定位接口性能瓶颈。
- 适合人群：自动化测试、命令行重度用户
- 缺点：不友好新手，学习曲线略高
五、实战：我平时怎么用这些工具？
在不同项目里，我会根据环境灵活选择工具，以下是一些实际做法：
| 使用目的 | 优选工具 | 原因说明 |
|---|---|---|
| 调试移动 HTTPS 请求 | Charles | 证书安装简单，支持手机抓包 |
| 分析接口返回错误 | Charles/Fiddler | 支持断点模拟与请求重放 |
| 查看网络瓶颈 | Wireshark | 可捕捉底层协议和延迟 |
| 重放和测试接口性能 | mitmproxy | 支持脚本控制请求逻辑 |
六、小结：没有完美的抓包工具，只有合适的工具
每个工具都有各自适用场景。你不必用最复杂的，也无需追求“全能”，关键是掌握一两种能满足日常需求的。
我个人目前主力是 Charles，特别是在移动端开发中，它几乎成了“必装工具”。但 Wireshark 和 mitmproxy 在特定场景下也屡屡救场。所以建议初学者从 Charles 入门，逐步探索更多。
如果你想尝试 Charles，可以参考这个中文站点，配置指南非常清晰：charlesproxy.net/
