刚入行时，别人跟我说“可以抓一下包看看”，我一脸懵：抓包？抓哪个包？怎么抓？抓完我又看不懂，有用吗？
后来某天项目出问题，组里一个前辈打开 Charles 看了几秒，说：“请求发错地址了。”五分钟搞定。
那一刻我意识到：原来抓包不是大神才会的玄学，而是最实际的开发能力之一。
第一次抓包的“撞墙”经历
我第一次用抓包工具，是为了调一个支付接口。当时对文档理解有偏差，把参数写错了。结果接口一直返回 403，我改了两天，没搞定。
同事说你装个 Charles 看看请求。安装、配代理、装证书，全是新知识。但当我第一次看到自己 App 的 HTTPS 请求数据被完整展示出来那一刻，有点震撼。
请求体里参数一目了然——原来我传了 total_amount，接口要的是 amount_total。
从此，我开始频繁使用抓包工具。
抓包技能的“进阶路径”
随着经验增加，我也逐步学会了更多操作方式和工具切换：
| 成长阶段 | 工具 | 学到的技能 |
|---|---|---|
| 入门 | Charles | 查看请求体、响应体、状态码、Header |
| 熟练 | Charles | 重发请求、断点调试、带宽模拟、移动设备抓包 |
| 进阶 | mitmproxy | 编写自动重放脚本，抓生产问题、测试边界场景 |
| 高阶 | Wireshark | 研究网络协议、TLS 握手问题、安全分析场景 |
每一种工具都为我解决过“非日志可查”的问题。也让我明白日志是后视镜，抓包是前挡风玻璃。
我常用的抓包工具及场景
Charles：日常主力工具
用得最顺手的还是 Charles，界面友好，适合调试 App、前端接口、移动端请求，尤其是模拟错误响应、测试重定向、验证弱网等。
推荐中文站：charlesproxy.net/
mitmproxy：脚本化处理神器
比如我们要测试接口返回大数据列表时的加载性能，我就用 mitmproxy 写脚本随机生成 JSON 数据，反复重放请求，测试前端是否处理卡顿。
Wireshark：定位深层网络问题
在某次客户反馈“偶发连接超时”后，只有 Wireshark 能抓到 DNS 解析失败导致整个请求卡死。
一个典型调试流程（用 Charles 举例）
以下是我平时定位接口问题时的标准流程：
- 设置代理和证书：尤其是手机端，必须让设备信任抓包证书
- 观察请求流：看请求是否真的发出，路径、方法、Header 是否完整
- 重放请求：使用
Repeat功能，测试不同参数组合 - 断点调试：截断响应模拟各种返回情况，看前端容错逻辑是否生效
- 网络模拟：测试带宽受限/断线重连后的请求处理行为
抓包“踩坑经验”分享
- HTTPS 抓不到？ 检查是否安装并信任了根证书（尤其是 iOS 设备）
- 抓不到手机请求？ 看手机 Wi-Fi 是否连到同一网络，代理设置是否正确
- 重发请求失败？ 有些接口有一次性 token，需同步刷新后再测试
后记：抓包的尽头，是思维方式的转变
从最初的“调试不得已才抓包”，到如今的“出问题先抓包”，这项技能已成为我开发工具链里不可替代的一环。
它帮我更理解数据是如何从前端走向后端，帮我更好地设计 API，帮我少说“我这边没问题”。
如果你还没开始学抓包，今天就是最好的开始。 Charles 中文官网：charlesproxy.net/
