1. 项目概述为什么我们需要Fiddler来Mock接口数据在前后端分离开发、移动端测试或者第三方接口联调的日常工作中我们经常会遇到一个让人头疼的问题依赖方接口不稳定或者尚未开发完成。比如前端页面需要展示用户订单列表但后端订单查询接口还在开发中又或者你需要测试一个支付失败场景但真实的支付网关不可能让你反复触发失败。这时候如果干等着项目进度就卡住了。Mock测试或者说模拟接口数据就成了我们推进工作的“救命稻草”。而Fiddler这个老牌的Web调试代理工具就是实现这个“稻草”变“金条”的利器。很多人对Fiddler的印象还停留在“抓包工具”看看请求响应、改改参数。这没错但它的“自动响应器”AutoResponder功能才是Mock测试的“神级”应用。它允许你拦截特定的网络请求并直接返回一个你预先准备好的本地文件如JSON、TXT、HTML作为响应完全绕过了真实的服务器。这意味着你可以在本地瞬间构造出任何你想要的接口数据成功的、失败的、超时的、数据结构异常的……整个测试环境完全由你掌控。我从业十多年从手动写死前端数据到搭建独立的Mock服务器最后发现对于快速验证、临时调试和特定场景测试Fiddler的Mock方案是成本最低、效率最高的。它无需编写任何后端代码无需启动额外服务只需点点鼠标配置几条规则真实环境下的网络请求流就能被你“偷梁换柱”。接下来我就带你彻底拆解如何用Fiddler玩转Mock测试从核心原理到每一步实操再到那些官方文档里不会写的“坑”和技巧让你不仅能上手更能用到精。2. 核心原理与工具准备Fiddler如何拦截并改写流量2.1 Fiddler作为代理的工作机制要理解Mock首先要明白Fiddler是怎么“插手”你的网络通信的。Fiddler本质上是一个运行在你本地电脑上的HTTP/HTTPS代理服务器。当你为系统或浏览器设置了Fiddler作为代理后通常地址是127.0.0.1:8888所有应用程序发出的HTTP/HTTPS请求都会先经过Fiddler再由Fiddler转发给目标服务器同样服务器的响应也会先回到Fiddler再经由它返回给你的应用程序。这个过程就像你寄快递请求和收快递响应都必须要经过一个“中转站”Fiddler。这个中转站不仅能看到你寄了什么、收到了什么抓包还能在你同意的情况下把你寄出的包裹掉个包修改请求或者把寄给你的包裹换成另一个Mock响应。AutoResponder功能干的就是“换包裹”的活儿它根据你设定的规则比如匹配特定的URL拦截下即将转发给应用程序的“真实响应包裹”然后从你本地仓库磁盘文件里拿出一个“模拟包裹”递出去。你的应用程序对此毫不知情以为这就是从真实服务器回来的数据。2.2 关键组件与环境配置工欲善其事必先利其器。开始Mock之前需要确保Fiddler正确安装并配置好关键部分。1. Fiddler的安装与基础配置下载与安装直接从Telerik官网下载Fiddler Classic目前免费且功能最全的版本。安装过程很简单一路下一步即可。不建议使用来路不明的汉化包可能存在安全风险且专业术语的英文表达更利于问题排查和国际交流。信任根证书关键为了解密HTTPS流量Fiddler需要生成一个根证书并安装到你的系统受信任的根证书颁发机构中。打开Fiddler进入菜单Tools - Options - HTTPS勾选Capture HTTPS CONNECTs和Decrypt HTTPS traffic然后点击Actions - Trust Root Certificate。这一步至关重要否则你只能看到HTTPS请求的一堆乱码无法进行有效的Mock。允许远程连接用于移动端抓包/Mock如果你想对手机App进行Mock需要允许远程设备连接。在Tools - Options - Connections中勾选Allow remote computers to connect。记住Fiddler监听的端口号默认8888。2. 理解AutoResponder面板这是我们的主战场。在Fiddler主界面找到并点击AutoResponder标签页。你会看到几个核心区域规则列表显示所有已创建的Mock规则。规则编辑器上方用于匹配请求的“If request matches”框和下方用于指定响应内容的“Then respond with”框。控制按钮Enable rules启用/禁用所有规则、Unmatched requests passthrough放行未匹配的请求务必勾选否则所有请求都会被拦截导致网络异常、Add Rule添加规则等。3. 准备Mock数据文件Mock的本质是返回文件。你需要提前准备好模拟的响应数据保存为文本文件。最常见的是JSON格式用于API接口也可以是HTML、TXT、甚至是一个图片文件。最佳实践在本地创建一个专门文件夹如C:\FiddlerMockData用来存放所有Mock文件。文件名最好具有描述性例如user_login_success.json、order_list_empty.json、api_error_500.txt。文件内容你需要按照目标接口的真实响应格式来编写内容。例如一个成功的用户信息接口Mock数据可能如下保存为user_info.json{ code: 200, message: success, data: { userId: 10001, username: 测试用户, email: testexample.com, avatar: https://example.com/avatar/default.png } }注意在开始Mock前务必先正常抓包一次目标请求记录下其完整的URL、请求方法GET/POST、以及真实的响应头和响应体格式。这是你编写Mock规则和Mock数据的基础能极大提高Mock的准确性和成功率。3. 从零开始一步步配置你的第一个Mock规则理论说再多不如动手做一遍。我们以一个最常见的场景为例Mock一个获取用户列表的GET接口。3.1 捕获目标请求首先我们需要知道要Mock谁。确保Fiddler正在捕获流量左下角显示Capturing。在你的浏览器或应用程序中触发你想要Mock的那个接口调用。例如访问你的开发网站点击“用户管理”页面。在Fiddler的会话列表左侧主窗口中你会看到捕获到的大量请求。找到你的目标请求通常可以通过URL路径如/api/users或响应状态码来筛选。点击该请求在右侧的Inspectors标签页中查看其详细信息。重点关注Headers请求头和TextView或WebForms请求体如果是POST。3.2 创建并配置AutoResponder规则现在我们将这个请求“绑架”让它返回我们预设的数据。在Fiddler会话列表中直接拖动你找到的目标请求会话到AutoResponder标签页的规则列表区域。这是最快捷创建规则的方法Fiddler会自动将请求的URL填入匹配框。观察规则编辑器。If request matches框里现在应该有一条类似EXACT:https://api.yoursite.com/api/users的规则。EXACT表示精确匹配。点击Rule Editor下方Then respond with对应的...按钮在弹出的文件选择器中找到并选中你之前准备好的Mock数据文件例如user_list_mock.json。勾选Enable rules和Unmatched requests passthrough两个复选框。最后点击Save按钮保存这条规则。3.3 验证Mock效果规则生效是瞬间的。回到你的浏览器或应用程序。再次触发相同的操作比如刷新用户管理页面。观察Fiddler的会话列表你应该会看到刚才那个请求的响应结果列状态码可能变成了200并且背景色会有所不同默认是浅黄色同时在响应图标上会有一个小小的“闪电”标志表示这个响应来自AutoResponder。点击这个会话在右侧Inspectors的TextView或JSON标签页中看到的响应内容应该就是你user_list_mock.json文件里的内容了。同时在Headers里你会看到一行FiddlerTemplate: True这也是来自AutoResponder的标记。回到你的应用程序界面它现在展示的数据应该就是你Mock的数据了。至此你的第一个Mock规则就成功了整个过程不到一分钟你就实现了对线上或开发中接口的完全掌控。4. 高级匹配规则精准定位你的目标请求直接拖拽创建规则虽然快但匹配条件过于精确EXACT。在实际项目中我们常常需要更灵活、更强大的匹配方式。Fiddler的AutoResponder支持多种匹配语法。4.1 常用匹配模式详解在规则编辑器的If request matches框中你可以手动输入或修改匹配模式。字符串匹配默认如果输入的不是以下任何关键字Fiddler会将其视为子字符串进行匹配。例如输入api/user则会匹配所有URL中包含api/user的请求如https://a.com/api/user/info和https://b.com/v1/api/user。不够精确容易误伤。正则表达式匹配推荐功能最强大。以REGEX:开头。例如REGEX:.*/api/v1/user/\\d$匹配所有以/api/v1/user/开头后接一个或多个数字结尾的请求如匹配/api/v1/user/123但不匹配/api/v1/user/123/order。REGEX:https?://(test|staging)\\.domain\\.com/.*匹配所有发往test.domain.com或staging.domain.com环境的请求。正则技巧.*匹配任意字符\d匹配数字$表示字符串结尾。使用正则可以非常精细地控制匹配范围。精确匹配以EXACT:开头。必须与请求的完整URL包括协议、域名、路径完全一致。适用于Mock某个绝对特定的请求。从会话列表拖拽生成的默认就是这种。方法匹配你还可以在模式中加入请求方法。例如METHOD:POST匹配所有POST请求。但通常我们结合URL一起使用如REGEX:.*/api/order.*并配合规则列表下方的Request Method筛选器但注意编辑器里的语法更强大。4.2 实战Mock不同场景的接口让我们用几个实例来感受高级匹配的威力。场景一Mock同一接口的不同返回状态假设有一个登录接口POST https://api.com/login你需要测试登录成功和密码错误两种情况。成功响应创建规则REGEX:https://api\\.com/login响应文件指向login_success.json包含token等信息。失败响应如何触发失败呢你不能用同样的URL。这时可以利用Fiddler的断点Breakpoint功能。先禁用或删除上一条规则。在Fiddler中选择Rules - Automatic Breakpoints - Before Requests。然后触发登录请求会在Fiddler暂停。在Inspectors的WebForms里将密码字段改成一个错误密码再点击绿色的Run to Completion按钮。这样请求会带着错误密码发往服务器你就能得到真实的错误响应。当然更彻底的Mock是直接创建另一条规则匹配一个“特殊”的请求比如在请求头或请求体里加一个特殊标记但这需要能修改客户端请求。场景二Mock动态路径接口比如Mock一个获取特定用户详情的接口路径模式是/api/user/{userId}。创建规则REGEX:https://api\\.com/api/user/\\d。这条规则会匹配所有用户ID为数字的详情请求。响应文件你可以准备一个通用的user_detail_mock.json。但问题是响应体里的用户ID需要和请求的ID对应吗对于简单测试可以不用对应。如果需要Fiddler的响应文件支持简单的文本替换但更复杂的需求可能需要用到FiddlerScript。场景三彻底屏蔽某个第三方资源模拟加载失败有时候需要测试某个CDN上的JS库加载失败对页面的影响。创建规则EXACT:https://cdn.example.com/some-library.v1.2.3.js响应文件你可以选择一个空的empty.js文件或者更直接地在Then respond with的下拉菜单中不选择文件而是直接选择*404: Not Found、*503: Service Unavailable或*DROP。*DROP会直接断开连接模拟网络超时或完全不可用效果非常真实。实操心得规则匹配的优先级是从上到下的。Fiddler会用请求依次匹配规则列表中的每一条使用第一条匹配成功的规则。因此你可以把最精确的规则如EXACT放在上面把更通用的规则如宽泛的REGEX放在下面。同时善用规则列表左侧的复选框可以快速启用/禁用单条规则方便你在不同Mock场景间切换。5. 模拟复杂场景延迟、修改响应头与状态码一个真实的测试场景不仅仅是返回正确的数据还需要模拟真实的网络行为比如慢速网络、服务器错误等。AutoResponder同样可以做到。5.1 模拟网络延迟弱网测试这是测试应用加载状态、超时处理逻辑的必备手段。在AutoResponder中选中或创建一条规则。在规则编辑器下方有一个Latency输入框单位是毫秒ms。输入你想要的延迟时间例如2000表示2秒延迟。保存规则。当下次请求匹配到该规则时Fiddler会在返回Mock数据前先等待你设定的时长。这完美模拟了弱网环境下接口响应慢的情况。延迟设置技巧结合场景列表接口可设500-1000ms关键操作接口如支付可设2000-5000ms测试前端超时提示。不要全局启用只对需要测试的特定接口规则添加延迟并勾选Unmatched requests passthrough避免影响其他正常操作的测试效率。5.2 自定义响应状态码与响应头默认情况下使用文件Mock响应状态码是200。但我们需要测试404、500等错误。使用内置模板在Then respond with下拉框中Fiddler提供了一系列预定义的错误响应模板如*404: Not Found、*502: Bad Gateway等。选择它们会直接返回对应的状态码和一个简单的错误页。完全自定义如果你需要返回一个状态码为500但响应体是特定JSON错误信息的响应就需要借助文件了。创建一个文本文件如error_500.json内容是你的错误JSON。然后在规则编辑器的Then respond with框中手动修改它的内容不仅仅是文件路径。例如原本可能是C:\MockData\error_500.json。你需要在前面加上状态码和响应头。修改为500 Content-Type: application/json; charsetutf-8 Custom-Header: SomeValue C:\MockData\error_500.json格式说明第一行HTTP状态码和描述可选。第二行及之后每行一个响应头。一个空行分隔响应头和响应体。最后一行响应体文件路径。Fiddler会读取该文件内容作为响应体。修改响应头如上例所示你可以在空行前添加任何你需要的响应头。这对于测试前端如何处理特定的Content-Type、Cache-Control或者自定义头部至关重要。5.3 一个综合案例模拟分页接口的慢速失败假设有一个分页查询接口GET /api/items?page2size10我们需要模拟它在弱网环境下第二页数据返回缓慢且最终超时的情况。准备Mock文件page_2_data.json包含第二页的模拟数据。创建规则匹配REGEX:.*/api/items\?page2.*精确匹配第二页请求。响应在编辑框中输入200 Content-Type: application/json; charsetutf-8 X-Delay: simulated C:\MockData\page_2_data.json延迟在Latency框中输入80008秒模拟超时边缘。测试前端发起第二页请求后会等待约8秒才收到数据。你可以借此观察前端的加载动画、超时重试或错误处理逻辑是否健全。6. 移动端Mock测试实战对手机App进行Mock测试是Fiddler的另一大高频应用场景。原理和Web端一样关键在于让手机的流量经过你电脑上的Fiddler。6.1 配置手机代理确保电脑和手机在同一局域网连接同一个Wi-Fi。查看电脑的局域网IP地址。在Fiddler中点击菜单Help - About Fiddler或者将鼠标悬停在右下角状态栏的Online字样上可以看到IP地址如192.168.1.100。在手机上配置代理iOS进入设置 - 无线局域网 - 点击当前Wi-Fi右侧的 (i) 图标 - 滑动到底部配置代理 - 手动。服务器填电脑IP如192.168.1.100端口填Fiddler端口默认8888。Android进入设置 - WLAN - 长按当前连接的Wi-Fi - 修改网络 - 高级选项 - 代理 - 手动。输入服务器和端口。在手机浏览器中安装Fiddler根证书这是解密HTTPS流量的关键。在手机浏览器中访问http://电脑IP:8888例如http://192.168.1.100:8888你会看到Fiddler的欢迎页面。点击页面底部的FiddlerRoot certificate链接下载并安装证书。iOS需要在设置 - 通用 - 关于本机 - 证书信任设置中对Fiddler的根证书启用完全信任。6.2 抓取并Mock移动端请求配置完成后手机上的所有网络请求都会出现在Fiddler的会话列表中。在手机上操作你的App触发你想要Mock的接口调用。在Fiddler中找到该请求可以通过域名或路径过滤。和Web端操作完全一样将该请求会话拖入AutoResponder关联你的Mock文件启用规则。回到手机App再次触发该请求App将收到你Mock的数据。踩坑记录移动端Mock最常见的问题是证书错误或网络不通。首先确保Fiddler的Allow remote computers to connect已勾选。其次部分App会使用“证书锁定Certificate Pinning”技术拒绝信任Fiddler安装的证书导致HTTPS连接失败。对于这类App常规的Fiddler代理方法可能无效需要更复杂的逆向工程手段这超出了基础Mock的范畴。此外安卓高版本对用户安装的证书权限有所限制可能需要将证书安装到系统级过程较为繁琐。7. 常见问题排查与性能优化技巧即使按照步骤操作你也可能会遇到Mock不生效的情况。这里汇总了一些常见问题和我积累的排查技巧。7.1 Mock规则为什么不生效问题现象可能原因排查步骤与解决方案请求未被拦截1. AutoResponder规则未启用。2.Unmatched requests passthrough未勾选且规则未匹配导致请求被丢弃。3. 请求是HTTPS但Fiddler未解密HTTPS流量。4. 客户端如浏览器未正确配置代理或使用了直连。1. 确认Enable rules已勾选。2.务必勾选Unmatched requests passthrough。3. 检查Tools - Options - HTTPS设置确认已启用HTTPS解密并信任根证书。4. 检查Fiddler是否处于Capturing状态检查浏览器代理设置确保指向127.0.0.1:8888。规则匹配不上1. URL匹配模式写错大小写、路径。2. 请求URL包含随机参数如时间戳_t162...。3. 使用了EXACT但URL有细微差别。1. 从会话列表拖动请求创建规则这是最准的。2. 对于带随机参数的请求使用REGEX匹配核心路径部分如REGEX:.*/api/data.*。3. 在规则编辑器中使用更宽松的匹配模式如字符串匹配或REGEX:.*part_of_url.*。响应内容不对1. Mock文件内容格式错误如JSON语法错误。2. 响应头如Content-Type不正确导致前端解析失败。3. 规则中指定了延迟导致响应慢被前端超时取消。1. 用文本编辑器检查Mock文件确保JSON格式正确。2. 在浏览器开发者工具的Network面板查看该请求的响应头与Mock规则中的响应头对比。对于JSON接口确保有Content-Type: application/json。3. 暂时去掉规则中的Latency延迟设置进行测试。移动端不生效1. 手机代理配置错误IP或端口。2. 手机未安装/信任Fiddler根证书。3. App使用了证书锁定。1. 确认电脑防火墙放行了8888端口。2. 在手机浏览器访问http://电脑IP:8888确认能打开Fiddler页面并成功安装证书。3. 对于证书锁定的App尝试在越狱/ROOT后的设备上使用特殊工具或寻找其他Mock方案如Charles的SSL Proxying设置更灵活。7.2 性能优化与最佳实践当Mock规则越来越多时管理和性能就需要考虑了。规则分组与注释Fiddler允许你为规则添加注释。在规则列表的Comments列双击即可输入。我习惯按功能模块或测试场景来分组规则并用注释标明例如# 用户模块-Mock登录成功、# 订单模块-模拟超时。关闭一个场景时可以批量禁用一组规则而不是删除。使用_前缀快速禁用在规则匹配表达式前加一个下划线_可以快速禁用单条规则而不删除它。例如将EXACT:https://api.com/test改为_EXACT:https://api.com/test。这在临时关闭某条规则进行对比测试时非常方便。Mock文件的组织不要把所有Mock文件放在桌面或下载文件夹。建立清晰的目录结构例如C:\FiddlerMockData\ ├── ProjectA\ │ ├── user\ │ │ ├── login_success.json │ │ └── profile.json │ └── order\ │ ├── list.json │ └── create_success.json └── ProjectB\ └── ...这样在规则中引用路径时一目了然也便于版本管理可以整个目录用Git管理。影响范围控制Mock是全局性的。一旦启用一条规则所有匹配该规则的请求无论来自哪个浏览器标签页或哪个应用都会受影响。因此在测试完成后务必记得及时禁用或删除不再需要的Mock规则以免干扰其他正常的浏览或开发工作。一个良好的习惯是为特定的测试任务创建一个独立的Fiddler会话File - New Session测试完成后直接关闭这个会话窗口。无法Mock WebSocket需要明确的是Fiddler Classic的AutoResponder主要针对HTTP/HTTPS请求。对于WebSocket连接它无法在建立连接后Mock其传输的数据帧。如果你需要Mock WebSocket数据可能需要寻找其他专门工具或在前端代码中模拟。8. 超越AutoResponderFiddlerScript与更灵活的Mock对于极其复杂的Mock场景比如需要根据请求参数动态生成响应内容AutoResponder的静态文件可能就不够用了。这时我们可以请出Fiddler的终极武器——FiddlerScript。FiddlerScript基于JScript .NET语言允许你编写脚本在请求/响应的生命周期中注入自定义逻辑。这打开了动态Mock的大门。8.1 入门修改静态响应内容假设你想在返回的JSON数据中总是将当前时间戳注入到一个字段里。打开FiddlerScript编辑器Rules - Customize Rules...或按CtrlR。这会打开一个CustomRules.js文件。我们需要在OnBeforeResponse函数中添加逻辑。这个函数在每个响应返回给客户端之前被调用。找到static function OnBeforeResponse(oSession: Session)函数在里面添加代码。例如我们想修改所有匹配/api/data的响应static function OnBeforeResponse(oSession: Session) { // 检查请求URL是否包含 /api/data if (oSession.uriContains(/api/data)) { // 禁止缓存确保每次都能执行我们的脚本 oSession.oResponse.headers.Remove(Cache-Control); oSession.oResponse.headers.Add(Cache-Control, no-cache); // 获取当前的响应体字符串 var responseBody oSession.GetResponseBodyAsString(); // 假设原响应体是JSON我们解析它这里简单演示实际应用需更严谨的JSON解析 // 例如原响应是 {time: old, value: 123} // 我们将其替换为 {time: 当前时间戳, value: 123} var newTime new Date().getTime(); // 获取当前时间戳 // 使用简单的字符串替换对于复杂JSON建议使用JSON解析库 var modifiedBody responseBody.replace(/time:\s*[^]*/, time: newTime ); // 将修改后的字符串设置回响应体 oSession.utilSetResponseBody(modifiedBody); } }保存脚本文件CtrlSFiddler会自动重新加载规则。之后所有匹配的请求其响应中的time字段都会被动态替换为最新时间戳。8.2 进阶完全动态生成响应更进一步我们可以不依赖任何外部文件完全用脚本生成响应。static function OnBeforeResponse(oSession: Session) { if (oSession.uriContains(/api/dynamicMock)) { // 直接设置状态码和响应头 oSession.responseCode 200; oSession.oResponse.headers.HTTPResponseStatus 200 OK; oSession.oResponse.headers[Content-Type] application/json; charsetutf-8; // 动态构造JSON响应体 var dynamicData { code: 200, message: Success from FiddlerScript, serverTime: new Date().toISOString(), randomNumber: Math.floor(Math.random() * 1000) // 生成一个随机数 }; // 将对象转换为JSON字符串 var jsonResponse JSON.stringify(dynamicData); // 设置响应体 oSession.utilSetResponseBody(jsonResponse); // 标记此会话为已修改防止其他处理 oSession[ui-color] orange; oSession[ui-bold] true; } }通过FiddlerScript你可以实现根据请求参数返回不同数据通过oSession.GetRequestBodyAsString()获取请求参数进行判断。模拟序列化行为比如一个创建订单接口每次Mock返回的订单号自动递增。实现复杂的条件逻辑根据请求头中的Token判断用户身份返回不同的数据。重要提示FiddlerScript功能强大但错误脚本可能导致Fiddler崩溃或行为异常。修改前建议备份原CustomRules.js文件。编写时注意语法可以利用Fiddler的日志输出功能FiddlerObject.log()进行调试。对于绝大多数日常Mock需求AutoResponder的静态文件方式已经足够高效和稳定。FiddlerScript更适合那些需要“智能化”响应的特殊测试场景。从简单的URL匹配替换到模拟网络延迟和错误状态再到移动端集成最后触及动态生成的边缘Fiddler为我们提供了一个低成本、高灵活性的本地Mock测试环境。它可能不是企业级持续集成中的方案但在开发、测试、调试的单个环节中其便捷性和即时性是无可替代的。掌握它就像在你的调试工具箱里放进了一把多功能瑞士军刀很多看似阻塞的问题都能迎刃而解。关键在于不要只把它当做一个抓包工具而是深度理解其代理机制和AutoResponder的工作原理然后大胆地去模拟任何你需要的测试场景。