打开Fiddler，口测抓一个登录请求，试教右键选择“Reissue from Composer”，口测把用户名改成别的试教值，发送。口测看响应。试教这就是口测用Fiddler做接口测试最直接的样子——不用写一行代码，不用等开发部署环境，试教抓到什么就能改什么，口测改完立刻看结果。试教

很多人把Fiddler只当抓包工具用，口测看完请求就关掉。试教其实它的口测Composer面板本身就是个轻量级接口测试客户端。你抓到的试教任何一个请求，都能直接拖进Composer，口测修改参数后重新发送。我试过在测试环境里抓一个下单接口，把商品ID从1001改成1002，价格字段从9900改成1，服务端返回200，订单金额显示0.01元。这个漏洞后来被确认是价格校验缺失。如果只靠Postman手动构造请求，我可能根本不会想到去改价格字段——因为看不到原始请求长什么样。

Fiddler的断点功能比Composer更灵活。在Rules菜单里开启“Automatic Breakpoints”，选择“Before Requests”。浏览器再发请求时，Fiddler会暂停，弹出编辑窗口。你可以在请求真正到达服务器之前，随意修改URL、Header、Body。测权限接口时特别有用：把普通用户的Cookie换成管理员的，看服务端是否只靠前端隐藏按钮来做权限控制。我遇到过好几次，前端把删除按钮藏起来了，但接口根本没校验角色，换个Cookie就能删别人的数据。

AutoResponder是另一个被低估的功能。它能让Fiddler拦截特定请求，直接返回本地文件或预设响应，不经过服务器。测前端容错时很好用：把支付接口的响应改成超时，看页面会不会卡死；把返回的JSON字段删掉几个，看前端会不会白屏。这比等后端造异常数据快得多。我习惯在AutoResponder里建一套“异常响应库”——空数据、超长字符串、特殊字符、HTTP 500——拖进去就能用。

说个具体案例。有次测一个查询接口，正常返回是数组。我在AutoResponder里把响应改成空对象{ }，前端直接崩了，控制台报“Cannot read property 'map' of undefined”。开发说“后端不会返回这种格式”，但谁能保证？网络中间件、网关、缓存层都可能改变响应结构。Fiddler让你在几秒内模拟出这些边缘情况。

性能测试也能凑合做。Fiddler的Statistics面板会显示请求耗时、DNS解析、TCP连接、TLS握手各阶段时间。虽然不如JMeter专业，但排查“为什么这个接口这么慢”够用了。我见过一个接口，服务端处理只要50ms，但客户端总耗时2秒。看Statistics发现TLS握手占了1.5秒——服务器没开Session Resumption。这种问题用Postman根本看不出来，它只显示总时间。

Fiddler的脚本系统是进阶玩法。用C#写Custom Rules，可以在请求/响应流经时做任意处理。比如自动给所有请求加签名头，或者把响应里的敏感字段脱敏后再显示。我写过一个简单规则：当响应状态码是401时，自动弹窗提醒。测试登录态过期场景时省得一直盯着屏幕。

当然Fiddler不是万能的。它跑在Windows上，团队协作共享测试用例不如Postman方便。HTTPS抓包要装证书，有些App还做证书绑定。但如果你只是想快速验证一个接口的行为，不想打开IDE写测试代码，Fiddler的“抓-改-发”三步循环是最短的路径。我现在的习惯是：Postman管回归测试集，Fiddler管探索性测试和问题定位。两者不冲突。

最后说个坑。Fiddler默认只抓HTTP，HTTPS需要Tools > Options > HTTPS里勾选Decrypt。勾了之后如果某个App突然连不上网，检查是不是证书没信任。我见过同事抓包抓到自己把公司VPN搞断的——Fiddler把VPN的流量也解密了，证书冲突。关掉Fiddler就好了。