打开Fiddler，截修据点开AutoResponder选项卡，改数勾选“Enable rules”和“Unmatched requests passthrough”，截修据然后把你想要拦截的改数请求拖进去——就这么简单，你就能在本地随意篡改服务器返回的截修据数据了。我第一次用这招是改数在调试一个电商App的价格显示逻辑，把商品详情接口的截修据响应体里"price": 299改成了"price": 0.01，刷新页面后那个数字真的改数变成了1分钱。当然，截修据这只是改数本地自娱自乐，服务器该收多少钱还是截修据收多少钱。

Fiddler本质上是改数个HTTP代理服务器，它坐在你的截修据浏览器和真实服务器之间。所有请求先到它手里，改数它再转发出去；所有响应也先经过它，截修据它再交还给浏览器。这个“中间人”位置给了它篡改一切的能力。AutoResponder就是专门用来做这件事的——它不真正把请求发到服务器，而是直接返回你预设的响应。你可以在规则里指定匹配的URL模式，然后关联一个本地文件或者直接写一段文本作为响应体。我习惯把要修改的JSON响应保存成文件，改起来方便，改完保存，Fiddler会自动读取最新内容。

操作上有个细节容易踩坑：匹配规则用的是通配符或正则表达式。比如EXACT:https://api.example.com/v1/product/123只匹配这一个完整URL，而REGEX:.*/product/\d+能匹配所有商品详情接口。刚开始我总忘记加EXACT:前缀，结果规则死活不生效，后来才发现默认是模糊匹配，写完整URL反而匹配不上。另外，如果响应是gzip压缩的，你得先在Fiddler里把“Decode”按钮点亮，否则看到的是一堆乱码，改都没法改。

修改响应内容只是基础玩法。更实用的是修改请求参数——比如把分页的page=1改成page=999，看看后端有没有做边界校验；或者把用户ID从自己的改成别人的，测试越权漏洞。这些操作在Fiddler里通过“Composer”选项卡就能完成，手动构造请求发出去，比在浏览器里反复点按钮高效得多。我见过一个支付流程的测试，有人把订单金额从100改成1，提交后服务器居然没校验，直接按1块钱扣款了。这种漏洞在真实环境里就是灾难。

移动端抓包稍微麻烦点。手机得和电脑连同一个WiFi，然后在WiFi设置里手动配置代理，指向电脑的IP和Fiddler监听的端口（默认8888）。第一次连接时Fiddler会弹窗问是否允许，点允许就行。但很多App用了证书绑定（SSL Pinning），Fiddler的根证书不被信任，抓到的HTTPS请求全是加密的。这时候要么用Xposed框架绕过证书校验，要么直接反编译APK把校验代码删掉。后者听起来暴力，但确实管用——我试过一个银行类App，改完重新打包签名，Fiddler就能正常解密了。

说回AutoResponder，有个场景特别适合它：前端开发时后端接口还没写好，你可以用Fiddler伪造一套完整的响应数据，让前端先跑起来。等后端接口就绪，把规则一关，无缝切换。我见过一个团队用这招并行开发，前端压根没等后端，一周就把页面全调完了。比等接口文档、等联调环境高效太多。

最后提醒一句：改数据之前最好备份原始响应。我有次手滑把登录接口的token字段删了，结果整个App卡在登录页，排查了半小时才想起来是Fiddler规则没关。另外，测试完记得把AutoResponder的勾选去掉，不然你会对着一个永远返回假数据的接口怀疑人生。