如果只是想"看一下请求"，Mac 上的选择其实很多。
但当需求开始变得具体，比如要抓 iOS App、要看 HTTPS、要改请求内容，工具之间的差异才真正显现出来。
我自己在 Mac 上抓包，往往不是一开始就决定用哪个软件，而是先想清楚几个问题：
是抓浏览器流量，还是抓本机程序？
是调接口，还是分析异常？
有没有 iOS 设备参与？
这些问题，直接决定了工具是否合适。
Charles：最容易上手，但也最容易卡住
在 Mac 上，Charles 往往是很多人的第一站。
如果只是抓浏览器或者普通 App：
- 安装后启动
- 打开 macOS 的网络代理
- 访问目标页面
HTTP 请求几乎立刻就能看到。
但一旦涉及 HTTPS，或者抓 iOS App，步骤就会明显变多：
- 安装 Charles 根证书
- 在 macOS 钥匙串里设为信任
- iOS 设备上再装一份证书
- Wi-Fi 代理手动配置
只要其中一步没做对，表现通常就是"什么都抓不到"。
这不是 Charles 的问题，而是代理模式本身的复杂度决定的。
mitmproxy：更偏向开发者的命令行方案
如果你更习惯终端环境，mitmproxy 是 Mac 上非常值得一试的工具。
它的优势在于：
- 可脚本化
- 请求和响应可以用 Python 直接处理
- 适合自动化调试或测试场景
但现实是，mitmproxy 对新手并不友好。
证书、代理、脚本三件事，只要有一项不熟，体验就会明显下降。
我一般只在需要"批量处理请求逻辑"时才会选它，而不是日常抓包。
Wireshark：不是替代品，而是补充
严格来说，Wireshark 并不是抓"HTTP 接口"的工具。
在 Mac 上用 Wireshark，更像是在看：
- TCP / UDP 连接
- DNS 请求
- TLS 握手是否成功
它非常适合回答一些代理工具回答不了的问题，比如：
请求有没有真正发出去？
是 DNS 失败，还是 TCP 被拒绝？
但如果你想直接看 HTTPS 内容，Wireshark 并不合适，除非你已经能解密 TLS。
当抓包对象变成 iOS 设备，工具选择会明显收缩
一旦需求变成：
- Mac + iPhone
- 抓 App 内请求
- HTTPS 是默认
很多 Mac 抓包软件就开始显得力不从心。
代理模式可以继续用，但配置成本会迅速上升，尤其是面对证书校验、双向验证时。
抓包大师在 Mac 上的定位，其实很清晰
我第一次在 Mac 上用 抓包大师，并不是为了替代 Charles，而是因为代理模式已经走不通。
在 Mac 环境下，抓包大师更像是一个底层抓包工具，尤其是在抓 iOS 设备时。
它在 Mac 上常用的几种功能包括：
- HTTPS 代理抓包（传统方式）
- HTTPS 暴力抓包（无需证书信任）
- 数据流抓包（查看所有网络数据）
这些功能解决的是不同层级的问题，而不是互相替代。
如何在 Mac 上用抓包大师抓 iOS App
如果目标是 iPhone App：
- 用 USB 连接 iPhone 到 Mac
- 保持设备解锁并信任电脑
- 按提示安装描述文件
- 选择 iOS 设备而不是"本机"
- 根据需求进入 HTTPS 代理抓包或 HTTPS 暴力抓包
如果只是接口调试，我会先试代理模式；
如果代理抓不到，再切换暴力抓包。
这种按成本递增的方式，比一上来就搞复杂方案要省时间。
本机抓包与设备抓包，是两条完全不同的路
在 Mac 上抓包，经常会混淆两个概念：
- 抓 Mac 本机流量
- 抓 iOS 设备流量
前者更适合用 Charles、mitmproxy；
后者才是抓包大师发挥优势的地方。
抓包大师在 Mac 上第一次运行本机抓包时，会要求输入系统密码，这是 macOS 权限模型决定的，属于正常行为。
工具多，并不意味着要全用
实际工作中，我很少只用一个抓包工具：
- Charles：快速看接口
- Wireshark：排查连接问题
- 抓包大师：处理 iOS、证书校验、复杂 HTTPS
它们之间不是竞争关系，而是覆盖不同问题空间。
Mac 抓包软件确实不少，但真正好用的，往往取决于场景而不是功能列表。