刚开始做开发时，我对"抓包工具有哪些"并没有太多概念。 浏览器有 Network 面板，iOS 有代理抓包工具，看起来已经覆盖了大多数需求。
直到有一次问题卡住，我才意识到： 并不是我不会用抓包工具，而是我一直在用同一类抓包方式。
一个促使我重新整理工具链的场景
当时排查的是一个跨端问题： Web 页面正常，App 内 WebView 偶发异常；接口日志完整，但客户端行为不一致。
我最初的做法很直觉------换代理、换证书、换端口。 但真正起作用的，是停下来重新思考：我现在需要的是哪一类抓包工具？
浏览器级抓包：最容易被忽略的"默认工具"
对 Web 开发来说，浏览器自带的 Network 面板往往是第一个抓包工具。 它的优势很明确：贴近前端执行环境，操作成本低。
它适合回答的问题包括：
- 请求是否由页面触发
- 参数在发起前是否正确
- 返回内容是否被浏览器解析
- 是否命中缓存或发生重定向
但当问题发生在浏览器之外，比如 WebView、代理层或设备环境时，这个视角就开始显得局促。
代理抓包工具：接口层的主力
提到"抓包工具有哪些"，大多数人第一时间想到的，还是代理抓包工具。
它们的定位很清晰： 把 HTTP / HTTPS 请求放到一个可观察、可修改的位置上。
在接口联调、参数验证、状态码分析时，这类工具非常高效。 你能快速判断接口是否按预期工作，也能方便地做请求重放或返回修改。
但它们也有一个共同前提： 请求必须经过系统代理，且 HTTPS 解密链路必须成立。
一旦这两个条件不满足，工具本身并不会"报错"，只会变得沉默。
当代理抓包失效时，工具列表需要扩展
很多工程师是在代理抓包失效之后，才开始真正关心"还有哪些抓包工具"。
比如：
- iOS App 启用了 HTTPS pin 校验
- 某些请求绕过了系统代理
- 只在真机环境复现的问题
这时，如果继续纠结代理配置，往往会陷入无效循环。
设备侧抓包：补齐"真实运行环境"的视角
在需要确认真实设备通信行为时，我会使用 抓包大师（Sniff Master） 这一类设备侧抓包工具。
它的作用并不是取代代理工具，而是解决一个更基础的问题：
这个请求，在真实设备上到底有没有发生？
由于不依赖系统代理，也不需要越狱或 root，它能从设备层面抓取 HTTPS、TCP、UDP 等通信数据。这在以下场景中非常关键：
- 真机环境与模拟器行为不一致
- HTTPS 解密失败但请求疑似存在
- 需要排查第三方 SDK 的真实网络行为
在我的工具列表里，它更多承担的是"还原真实环境"的角色。
指定 App 抓包，让分析回到问题本身
抓包工具有哪些，并不只是功能差异，还有使用体验的差异。
在真机或复杂环境下，全局抓包往往会产生大量噪音。 如果工具支持只抓取指定 App 或指定流量，排查效率会明显提升。
当所有抓到的数据都和当前问题相关时，工程师更容易形成判断，而不是被数据淹没。
数据流抓包工具：当 HTTP 已经解释不了问题
并不是所有网络问题都发生在 HTTP 层。
在涉及以下情况时，HTTP 抓包往往不足以解释现象：
- TCP 长连接异常
- 心跳或状态同步失败
- 自定义协议通信问题
这时，"抓包工具有哪些"这个问题，会自然扩展到数据流抓包工具。
抓包大师支持 TCP / UDP 数据流抓取，并可以导出数据供进一步分析。 它在这一步的意义，不是解析协议细节，而是确认连接是否建立、是否中断、是否重复。
Wireshark：工具列表里的"放大镜"
Wireshark 几乎出现在所有抓包工具列表中，但它并不适合所有阶段。
在我的使用习惯里，它更像是一个确认工具： 当我已经通过其他工具定位到某个可疑连接或时间点，再用 Wireshark 去验证细节。
如果在问题还很模糊时就直接使用，反而容易迷失在信息量里。
拦截与修改：验证理解是否正确
抓包工具的一个重要能力，是允许你改变通信行为。
通过修改请求参数、Header 或响应内容，可以快速验证客户端或服务端的处理逻辑。 这比反复改代码、重新部署要高效得多。
抓包大师支持通过脚本拦截和修改请求、响应，在这一阶段更像是实验工具，而不是单纯的抓包工具。
回到最初的问题：抓包工具有哪些？
如果只列名字，其实并不难。 但从工程实践来看，更有价值的问题是：
- 我现在站在哪一层看网络
- 当前工具能看到的，是否是真实发生的通信
- 是否需要换一个视角继续判断
不同抓包工具，本来就服务于不同层级。 把它们组合起来使用，往往比单独依赖某一个工具更可靠。