pc端抓包工具fidder

Fiddler 本质上是个代理服务器。它蹲在客户端和服务器中间，包工所有 HTTP/HTTPS 流量都得从它眼皮底下过。端抓这事儿听起来简单，包工但威力不小。端抓我见过不少前端开发，包工调接口调得焦头烂额，端抓浏览器 F12 面板翻来覆去，包工结果装了个 Fiddler，端抓五分钟定位到问题——某个请求头少了个 token，包工或者响应体被网关截胡了。端抓那种“原来在这儿”的包工表情，比讲十遍原理都管用。端抓

装 Fiddler 不费劲。包工官网下个安装包，端抓一路下一步。第一次打开，界面左边是会话列表，右边是详情面板，底下还藏着一排命令行工具。多数人上来就盯着左边那堆密密麻麻的请求发呆，其实先别慌。你得先让 HTTPS 能看。默认情况下，Fiddler 解不了加密流量，得去 Tools > Options > HTTPS 里勾上“Decrypt HTTPS traffic”，顺手把证书装上。这一步不弄，抓到的全是乱码，跟没抓一样。

证书这东西，有时候挺烦人。Windows 上还好，Fiddler 自己就能把证书塞进系统信任区。但你要是抓手机 App 的包，就得手动把 Fiddler 的根证书导到手机里，还得在设置里开信任。我试过在 Android 7 以上版本折腾，系统默认不信任用户证书，得改 App 的网络安全配置，或者干脆 root 后用 Magisk 模块把证书挪到系统区。这过程不优雅，但搞定了就一劳永逸。

抓包的核心是过滤。Fiddler 默认把所有流量都列出来，浏览器后台心跳、系统更新、广告请求，全混在一起。你找目标请求跟大海捞针似的。我习惯先在命令行敲 cls 清屏，然后输入 select 加关键字，比如 select api.example.com。或者用 Filters 标签页，把 Host 和 Process 一卡，世界瞬间清净。这招在排查线上问题时特别管用——生产环境流量大，不滤一下，Fiddler 能给你卡成幻灯片。

有个功能我用了就回不去：AutoResponder。前端开发经常要 mock 数据，以前得改代码、重启服务，麻烦。现在直接把请求拖进 AutoResponder，指定一个本地 JSON 文件，Fiddler 就替你返回。改完保存，刷新页面，新数据立刻生效。有次调一个分页接口，后端还没写完，我靠 AutoResponder 模拟了十几种异常返回，把前端的错误处理逻辑全测了一遍。后端哥们儿后来看到，说这比写单元测试还快。

Composer 也是个好东西。有时候要重放一个请求，或者手动构造一个带特定 header 的调用，直接在 Composer 里粘贴原始请求文本，改几个参数，点 Execute。它会把请求发出去，响应直接出现在会话列表里。我拿它测过接口的幂等性，同一个订单号连发五次，看后端怎么处理重复提交。这种脏活，用 Postman 也行，但 Fiddler 能顺便把整个链路都录下来，前后对比方便。

性能分析这块，Fiddler 的 Statistics 标签页给得挺全。一个页面的请求数、总耗时、各阶段时间占比，一目了然。有回客户抱怨页面加载慢，我抓包一看，一个 CSS 文件卡了 3 秒，再一看，是某个 CDN 节点抽风。把域名切到备用节点，问题没了。这种事儿，不抓包根本猜不到——你以为是后端接口慢，其实是静态资源在拖后腿。

Fiddler 也有烦人的地方。它占内存，开久了能吃到 1G 以上。会话列表不清理，几万条记录堆着，界面就卡。我养成了习惯，每天下班前 cls 一下，或者干脆重启。另外它那个 Script 功能，用的是 JScript.NET，语法老不说，调试也费劲。我试过用 FiddlerScript 自动改请求头，写了几行就放弃了——有那功夫，不如在代码里加个拦截器。

说到底，Fiddler 是个工具。工具的价值在于解决问题，不在于功能多全。我见过有人拿它抓包改数据，在页面上刷了个“管理员”标识，然后截图发朋友圈——这属于玩梗，不算正经用途。真正干活的时候，它帮你省下的时间，是实打实的。一个请求发出去没反应，你不再需要猜，打开 Fiddler，看一眼，答案就在那儿。这种确定性，比什么文档都踏实。