fiddler测试

我抓了公司内网一个支付接口的报文，发现开发小哥提交的金额参数居然能改成负数。这不是漏洞演示，是Fiddler最日常的操作——改包重放。干这行久了你会明白，抓包工具不是黑客玩具，是后端开发的显微镜。

Fiddler启动后默认监听8888端口，手机连上代理就能看HTTPS流量，前提是装好它的根证书。真别嫌麻烦，那步证书操作能过滤掉七成新手抱怨"抓不到包"的问题。我见过最离谱的同事，折腾半天发现模拟器忘开代理设置，气得当场把咖啡泼在键盘上。

改请求体是最解气的功能。线上环境有个Bug，前端传参多了个空格导致查询失败，后端死活复现不了。我用Fiddler把正常请求复制一份，手动删掉参数里的空格，重放一次，接口立刻返回500。开发看着抓包记录愣了三秒，最后发现是网关层做了参数校验，空格被转义成%20。你看，有些问题就差这么一层窗户纸。

别光盯着请求，响应拦截才是进阶玩法。模拟弱网环境不用真去地下室，Fiddler的脚本里加个延迟函数，几百毫秒的卡顿就能把前端加载动画的竞态条件炸出来。上周测一个图片懒加载组件，我故意把某张图的响应拖到5秒后返回，结果页面直接白屏——前端代码没做超时兜底。这种问题上线后用户只会觉得"偶尔打不开"，你连复现路径都找不到。

倒是AutoResponder功能让我又爱又恨。它能用本地文件替换线上资源，调试样式时爽得飞起，改完CSS刷新就生效，不用走完整发布流程。但坑也在这——有次我忘了关规则，把测试环境的JS映射到生产域名上，整个页面功能全崩。同事盯着控制台报错怀疑人生，我默默关掉Fiddler，世界安静了。工具无罪，手滑害人。

用久了你会形成肌肉记忆。看到报错先想是不是没开捕获，接口通了先看Raw标签页的编码格式，响应乱码八成是gzip没解压。这些琐碎经验堆起来，才敢说"会用Fiddler"。那些教程爱教你点Composer构造请求，实际工作中谁手敲报文啊？都是抓包改完直接重放，效率翻倍。

最后提醒一句，别在生产环境乱改包。我见过测试拿Fiddler把订单金额改成0.01元，结果触发了风控，整条业务线被冻结排查。工具是刀，切菜还是砍人，全看握刀的手。能抓到包不算本事，知道改哪里、改了会怎样，那才是真功夫。