盯着一屏Fiddler会话列表翻了三分钟只为了找那条502的请求这种体验做过接口联调的人都不陌生。几十上百行记录里每条长得都差不多接口一多眼睛直接看花全靠滚动条一点点扫效率极低。我的做法是给Fiddler定制一套自动着色规则让它在会话出现的第一时间就根据字段和状态给请求上色该红的红、该绿的绿该加粗的加粗。一眼扫过去就知道哪些请求需要点开看哪些可以直接忽略。这篇文章以Fiddler Classic经典版为例讲清楚规则脚本的修改入口、核心API以及按状态码、域名、URL关键字、响应内容、耗时等维度实现标红的完整写法每个场景都给出可以直接套用的代码块最后整理几个规则不生效和颜色串台的坑。适合正在折腾抓包调试、前后端联调、接口排障的开发者。1. 先搞明白Fiddler的会话着色机制1.1 需求拆解“字段”和“状态”到底指什么标题里的“字段”和“状态”对应的是Fiddler会话列表里两个维度的信息。字段类条件通常是会话列表第一列到第五列展示的内容Host请求域名、Method请求方法、URL关键字、Content-Type响应类型、自定义请求头/响应头等。状态类条件则是另一层信息HTTP状态码200、302、404、500、502、请求耗时、响应体内容里是否出现业务错误码等。把这两个维度拆开之后标红规则就变成了一段逻辑判断代码。本质上就是遍历每个会话检查它是否命中我们设置的条件命中就给这行的背景色或前景色赋值。想按哪个字段标红就把哪个条件写进判断里判断条件之间还可以自由组合。有一点需要提前讲清楚Fiddler会话列表的颜色信息最终是通过SessionFlag会话标志实现的。修改会话的ui-backcolor、ui-forecolor这类标志列表就会即时刷新成对应颜色。我们写的所有规则最后都是落在这些flag上。1.2 为什么用脚本自动着色而不是手工Highlight很多人一开始用的是Fiddler自带的右键Highlight功能选中一条会话挑个颜色完事。我刚开始也是这么干的但用了几次就放弃了。原因很简单手工Highlight只能一条条操作请求量大时完全不现实刷新列表或者工具重启之后颜色信息直接丢失团队里换个环境联调又得重新标一遍纯重复劳动。脚本规则的好处是“一劳永逸”。CustomRules.js保存后立即生效之后每个新产生的会话都会自动按规则着色。条件随便写颜色随便挑规则可以跟着项目走一套脚本吃遍所有环境。更重要的是规则是明文代码团队之间直接共享一个文件视觉标准就统一了。Fiddler本身也有内置的自动高亮规则但内置规则能匹配的条件非常有限而且对“根据字段或状态定制”这种需求支持得很弱。要真正解放双手还是得打开脚本自己写。2. Fiddler规则脚本入口CustomRules.js从哪里改2.1 打开脚本的正确姿势Fiddler的规则脚本入口只有一个核心文件CustomRules.js。打开方式很简单菜单栏点击 Rules - Customize Rules有些汉化版本叫“自定义规则”默认用记事本或系统关联编辑器打开。这个动作等效于直接打开文件它的物理位置一般在%USERPROFILE%\Documents\Fiddler2\Scripts\CustomRules.js如果你的系统文档目录被迁移到了其他盘以资源管理器打开后的实际路径为准。点击菜单后脚本会自动打开不必手动去翻文件夹。首次打开这个文件的人可能会被吓一跳里面已经有一大段默认代码定义了OnBeforeRequest、OnBeforeResponse两个静态函数还有一些辅助类。我们不需要理解全部内容只往这两个函数里添加判断逻辑就行。保存文件之后Fiddler会在一两秒内自动检测到脚本变更并重新加载不需要重启工具。如果保存后发现规则没有生效可以在Fiddler底部QuickExec命令行输入!reload强制重载一次。编辑脚本前建议先把原文件复制一份备份防止改坏了又没有留底。2.2 关键事件选择OnBeforeRequest和OnBeforeResponseCustomRules.js里有两个最关键的事件函数理解它们各自的触发时机是规则能不能生效的前提。第一个是OnBeforeRequest它在请求发出之前触发。这个阶段能拿到的是请求行、请求头、URL、Host、Method这些请求侧数据。所以凡是依赖请求字段的判断比如按域名标红、按URL关键字标红、按请求方法标红都应该写在这里。第二个是OnBeforeResponse它在响应返回之后触发。这个阶段才能拿到状态码、响应时间、响应头和响应体。按状态码标红、按接口耗时标红、按响应内容包含特定字段标红都只能放在这个事件里。如果你在OnBeforeRequest里判断状态码拿到的会是初始值判断永远不成立。有个容易被坑的细节如果在OnBeforeRequest里给某个会话设置了颜色而后请求走到了OnBeforeResponse另一个规则又给它设了别的颜色后者会覆盖前者。所以当规则变多之后最好把着色逻辑抽成公共函数两个事件都去调用让颜色由同一个逻辑决定而不是各写各的互相覆盖。后面展开说。2.3 设置颜色的核心APISessionFlagFiddler为每个会话维护了一组键值对叫做SessionFlag。其中这几个固定键和颜色、样式相关Flag键作用取值示例ui-backcolor会话行背景色#FF0000 或 redui-forecolor会话行字体颜色#FFFFFF 或 whiteui-bold字体加粗trueui-italic字体斜体trueui-underline下划线true在脚本里赋值的方式是直接操作oSession对象oSession[ui-backcolor] #FFCCCC; oSession[ui-forecolor] #CC0000; oSession[ui-bold] true;颜色格式支持两种命名颜色red、blue、green等和十六进制色值#FF0000这类。命名颜色简单但可选的少要精细控制深浅还是用十六进制方便。我习惯在规则文件顶部定义一套配色常量不同场景用不同颜色后面讲实战时会给出具体配色方案。这里稍微说明一下为什么用字符串true而不是布尔值true。SessionFlag存储的类型本质上是字符串虽然写true很多时候也能转成字符串但为了减少类型判断的意外我习惯显式写字符串形式。3. 实战按不同字段和状态写标红规则3.1 按HTTP状态码标红最基础的保命规则状态码着色是所有规则里最实用的一条它解决的是“满屏请求里快速锁定错误请求”的刚需。逻辑很简单4xx说明是客户端问题5xx说明是服务端故障300系列则是重定向。public static function OnBeforeResponse(oSession: Session) { // 服务端错误深红底 白字最醒目 if (oSession.responseCode 500) { oSession[ui-backcolor] #FF0000; oSession[ui-forecolor] #FFFFFF; oSession[ui-bold] true; } // 客户端错误浅红提示请求有问题但不至于崩 else if (oSession.responseCode 400) { oSession[ui-backcolor] #FFCCCC; } // 重定向浅黄方便观察跳转链路 else if (oSession.responseCode 300) { oSession[ui-backcolor] #FFFFCC; } }这段代码必须放在OnBeforeResponse里因为responseCode在请求发出前是拿不到的。实际体验下来5xx500、502、503、504用深红底白字加粗是整个列表里最有视觉冲击力的一个组合扫一眼就能定位到故障请求。4xx用浅红不打扰但又能明显区分正常请求。另外一个小建议如果页面上刷了一堆静态资源在OnBeforeRequest阶段先对静态资源请求做个短路判断比如.js、.css、.png结尾的请求压根不用走后面的状态码判断省得每次都得过一遍条件。public static function OnBeforeRequest(oSession: Session) { var url oSession.url.toLowerCase(); if (url.endsWith(.js) || url.endsWith(.css) || url.endsWith(.png)) { return; } }3.2 按域名Host区分标红联调环境一目了然联调时最痛苦的事就是浏览器一打开页面请求里的测试环境域名、线上域名、第三方域名全混在一起想找某个环境下的接口全靠肉眼识别主机名。按域名标红的逻辑写在OnBeforeRequest里最合适因为请求还没出去Host字段是现成的。public static function OnBeforeRequest(oSession: Session) { // 测试环境域名浅红背景提醒别搞混了 if (oSession.HostnameIs(api-test.example.com)) { oSession[ui-backcolor] #FFCCCC; oSession[ui-bold] true; } // 线上环境域名浅绿背景代表正常环境 if (oSession.HostnameIs(api-prod.example.com)) { oSession[ui-backcolor] #D5F5E3; } }这里的HostnameIs是精确匹配不带端口号。如果你的请求里带了端口比如api-test.example.com:8080用HostnameIs匹配可能会落空。更稳妥的做法是用oSession.host这个属性做indexOf包含判断var host oSession.host.toLowerCase(); if (host.indexOf(api-test) 0) { oSession[ui-backcolor] #FFCCCC; oSession[ui-bold] true; }域名一多靠散落的if语句维护起来会很费劲。我通常在脚本头部定义一个环境域名数组用循环去匹配规则文件看起来清爽很多。后面4.6小节会再展开。3.3 按URL关键字和请求方法标红精准锁定目标接口上面两小节解决了“哪些请求出错了”和“哪些环境要关注”两个问题。但在业务联调里经常要盯的是某一个特定业务接口比如下单、支付、登录。这时按URL关键字标红是最精准的做法。public static function OnBeforeRequest(oSession: Session) { // 包含order关键字的接口橙色背景重点关注 if (oSession.uriContains(order)) { oSession[ui-backcolor] #FFCC66; oSession[ui-bold] true; } // 登录接口浅蓝背景 if (oSession.uriContains(login)) { oSession[ui-backcolor] #CCE5FF; } // POST写操作字体标红加粗区分读和写 if (oSession.HTTPMethodIs(POST)) { oSession[ui-forecolor] #CC0000; oSession[ui-bold] true; } }这里补充一个易混点oSession.fullUrl是完整地址带协议和域名oSession.url是路径加查询串部分uriContains判断的是url内容。如果只想匹配某个具体路径片段直接写关键字即可比如uriContains(/api/v1/pay)和uriContains(pay)的命中范围完全不一样写的时候心里要有数。按方法标红有个用处POST、PUT、DELETE这类写操作比GET更需要关注字体标红能提个醒。但要注意这里用的是ui-forecolor只改字体颜色不改背景色可以避免和背景色规则叠在一起的时候视觉冲突。3.4 按响应内容包含关键字标红业务错误码的兜底方案状态码标红只能抓到HTTP层的错误但更常见的情况是接口返回200业务体里却写着errorCode: 50001。这种业务错误如果只靠状态码规则永远不会被标出来。解决办法是读取响应体在里面查业务关键字。public static function OnBeforeResponse(oSession: Session) { // 只对API接口做检查静态资源跳过 if (oSession.uriContains(/api/)) { var body oSession.GetResponseBodyAsString(); if (body body.Contains(errorCode) !body.Contains(\errorCode\:\0\)) { oSession[ui-backcolor] #FF9999; oSession[ui-bold] true; } } }这段代码的意图很直白凡是API接口响应里出现了errorCode字段而且值不是0假设0代表成功就标成粉红。用Contains做判断前一定先判空因为GetResponseBodyAsString在某些情况下返回的是空值直接调用会报错。还有个细节如果响应是Gzip压缩过的Fiddler在脚本层默认会自动解压文本流所以一般能直接读到可识别的字符串。遇到乱码或者读不到内容的情况先检查一下该会话的响应头里Content-Encoding字段确认是不是压缩格式没被解出来。3.5 按响应耗时标红提前暴露性能问题定位接口慢这个问题纯靠人工眼睛一遍遍刷新列表看Time列逐个比较几百毫秒和几秒的差异效率很低。更直接的做法是让超过阈值的慢请求自动变色。因为Fiddler内置的计时属性在不同版本上有细微差别我用一个通用的方案在OnBeforeRequest里记录当前时间戳存到会话的自定义flag里然后在OnBeforeResponse里读出来算差值。public static function OnBeforeRequest(oSession: Session) { // 记录发起时间 oSession[x-request-start] String(new Date().getTime()); } public static function OnBeforeResponse(oSession: Session) { var start parseInt(oSession[x-request-start]); if (!isNaN(start)) { var elapsed new Date().getTime() - start; if (elapsed 5000) { oSession[ui-backcolor] #FFFFCC; oSession[ui-bold] true; // 顺手把耗时写到备注列鼠标悬停能看 oSession[ui-notes] 耗时: elapsed ms; } } }超过5秒的请求标成淡黄色背景同时把具体耗时写进备注列排查时不用再自己去算差值。这个场景特别适合和老接口做性能回归的时候用阈值调到3000还是5000取决于具体项目直接在文件头部用常量控制会更好。这里注意一点存时间戳的flag名字不能和Fiddler内置flag冲突用x-前缀比较保险。同理写其他自定义flag也建议加前缀避免误覆盖系统字段。3.6 组合条件与优先级控制多规则不会乱成花猫如果上面的规则都往脚本里堆不加任何管理一个会话可能同时命中多个条件背景色和字体色被后写的语句覆盖来覆盖去最后呈现的颜色完全随机反而失去意义。我现在的做法是把着色逻辑统一收口到一个公共函数里按优先级从高到低依次判断一旦命中高优先级规则就直接return不再继续往下执行低优先级规则。两个事件统一调用这个函数。public static function ColorizeSession(oSession: Session) { // 重置颜色防止旧状态残留 oSession[ui-backcolor] ; // 优先级1服务端错误最高优先 if (oSession.responseCode 500) { oSession[ui-backcolor] #FF0000; oSession[ui-forecolor] #FFFFFF; oSession[ui-bold] true; return; } // 优先级2客户端错误 if (oSession.responseCode 400) { oSession[ui-backcolor] #FFCCCC; return; } // 优先级3慢请求 var start parseInt(oSession[x-request-start]); if (!isNaN(start)) { var elapsed new Date().getTime() - start; if (elapsed 5000) { oSession[ui-backcolor] #FFFFCC; return; } } // 优先级4指定域名和业务接口 if (oSession.HostnameIs(api-test.example.com) || oSession.uriContains(order)) { oSession[ui-backcolor] #FFCC66; oSession[ui-bold] true; } } public static function OnBeforeRequest(oSession: Session) { oSession[x-request-start] String(new Date().getTime()); ColorizeSession(oSession); } public static function OnBeforeResponse(oSession: Session) { ColorizeSession(oSession); }这样一套组合下来任何会话最多只有一种颜色而且颜色表达的含义是确定的深红是服务端挂了浅红是请求错了淡黄是太慢了橙色是命中了关注接口。整个列表看下来视觉层级非常清楚。4. 规则不生效、颜色串台常见问题与调试技巧实录4.1 保存后规则不生效规则写好后保存Fiddler却纹丝不动这是最常见的翻车现场。按以下顺序排查确认保存的文件确实是当前生效的CustomRules.js。有些机器上存在多个副本菜单打开的路径是最权威的参考别用文件夹里翻到的另一个文件改了半天。在QuickExec命令行输入!reload强制重载并观察Fiddler LogView - Log里有没有脚本报错信息。检查函数签名是否正确。OnBeforeRequest、OnBeforeResponse必须写成public static function少一个关键词Fiddler都不会调用。如果脚本里出现了语法错误整个脚本都会加载失败规则的失效范围是整个文件不只是写错的那一段。4.2 颜色一闪而过或者被其他规则覆盖场景是OnBeforeRequest里明明标了红色请求发完响应回来后颜色没了或变成了别的颜色。原因多半是你在两个事件里分别写了着色逻辑后触发的OnBeforeResponse里的赋值把前面的颜色覆盖了。这是新手最容易踩的坑也正好印证了前面3.6小节的方案把着色逻辑抽成公共函数两个事件统一调用从根上避免各写各的互相打架。还有一个小概率情况Fiddler对某些会话在内部会重置样式比如对某些自动请求或隧道请求。遇到这种判断一下该会话的类型在规则开头跳过非HTTP会话就行。4.3 颜色太刺眼或者满屏都是颜色规则加多了之后很容易出现下一页屏幕全是粉色橙色看着很热闹实际信息量没有提升。我的经验是控制颜色使用量深红背景只给5xx这种真正需要立刻处理的会话浅红给4xx不刺眼又能区分淡黄给慢请求浅绿给线上环境请求业务重点接口用橙色但数量必须少最好一个项目只标两三个。还有一种做法是“不加背景只加粗”。对于需要提醒但不紧急的会话设置ui-bold true就够了让背景颜色留给真正需要聚焦的错误和慢请求。4.4 JScript.NET语法坑导致整个规则文件崩掉Fiddler的脚本语言是JScript.NET语法上接近JavaScript但和浏览器里的JavaScript还是有一些差异。几个容易踩的坑字符串必须用双引号或单引号括完整漏了一个引号整个脚本直接编译失败方法名区分大小写Contains、HostnameIs、GetResponseBodyAsString大小写写错了不会报错但函数不执行函数里声明变量尽量用var避免隐式全局变量带来莫名其妙的变量污染公共函数必须写在两个事件函数之外不能嵌在事件函数里面。写完一段规则就保存一次这是最土但最有效的自检方式。等你一次性写完几百行再保存编译器报错之后定位错误位置是很痛苦的一件事。4.5 快速验证规则是否生效验证规则最快的方法是制造一个已知会命中条件的环境。比如你刚写完状态码标红就用浏览器去访问一个不存在的路径让服务器返回404看列表里那条记录有没有变成浅红或者故意用来一个返回500的测试接口看有没有变成深红。如果颜色没变说明规则没写对或脚本没重载按4.1的顺序排查。Fiddler自带的示例会话也适合用来验证脚本。菜单 File - Load Sample Sessions会生成一批带各种状态码的示例请求保存规则之后加载一批瞬间就能看出颜色逻辑是否正确。每次验证前可以先按CtrlX清空会话列表免得旧数据干扰观察。4.6 多套环境的规则管理最后聊点规则文件的工程化经验。如果你同时维护多个项目的调试环境建议把环境差异都收敛到脚本头部做成配置常量规则逻辑只读取这些常量不改中间判断。var TIMEOUT_MS 5000; var TEST_HOSTS [api-test.example.com, admin-test.example.com]; var BIZ_KEYWORDS [order, pay, refund];换项目时只改头部这一段颜色体系和判断逻辑完全不用动。规则文件做好命名备份比如CustomRules-order.js、CustomRules-pay.js在项目切换时直接替换文件再!reload即可。这套做法看起来简单但真正能省下不少切换环境时反复改脚本的功夫。我自己用这套规则大概五六年了最大的感受是它把“找问题”从主动扫描变成了被动接收颜色一亮目光就会自动聚焦过去根本不用从上到下翻列表。规则别贪多颜色别太满挑几个真正影响判断的状态和字段去标比什么都标红更实用。照着上面几个场景从状态码标红开始试慢慢往上加你会回来感谢这条规则的。
盯着一屏Fiddler会话列表翻了三分钟只为了找那条502的请求这种体验做过接口联调的人都不陌生。几十上百行记录里每条长得都差不多接口一多眼睛直接看花全靠滚动条一点点扫效率极低。我的做法是给Fiddler定制一套自动着色规则让它在会话出现的第一时间就根据字段和状态给请求上色该红的红、该绿的绿该加粗的加粗。一眼扫过去就知道哪些请求需要点开看哪些可以直接忽略。这篇文章以Fiddler Classic经典版为例讲清楚规则脚本的修改入口、核心API以及按状态码、域名、URL关键字、响应内容、耗时等维度实现标红的完整写法每个场景都给出可以直接套用的代码块最后整理几个规则不生效和颜色串台的坑。适合正在折腾抓包调试、前后端联调、接口排障的开发者。1. 先搞明白Fiddler的会话着色机制1.1 需求拆解“字段”和“状态”到底指什么标题里的“字段”和“状态”对应的是Fiddler会话列表里两个维度的信息。字段类条件通常是会话列表第一列到第五列展示的内容Host请求域名、Method请求方法、URL关键字、Content-Type响应类型、自定义请求头/响应头等。状态类条件则是另一层信息HTTP状态码200、302、404、500、502、请求耗时、响应体内容里是否出现业务错误码等。把这两个维度拆开之后标红规则就变成了一段逻辑判断代码。本质上就是遍历每个会话检查它是否命中我们设置的条件命中就给这行的背景色或前景色赋值。想按哪个字段标红就把哪个条件写进判断里判断条件之间还可以自由组合。有一点需要提前讲清楚Fiddler会话列表的颜色信息最终是通过SessionFlag会话标志实现的。修改会话的ui-backcolor、ui-forecolor这类标志列表就会即时刷新成对应颜色。我们写的所有规则最后都是落在这些flag上。1.2 为什么用脚本自动着色而不是手工Highlight很多人一开始用的是Fiddler自带的右键Highlight功能选中一条会话挑个颜色完事。我刚开始也是这么干的但用了几次就放弃了。原因很简单手工Highlight只能一条条操作请求量大时完全不现实刷新列表或者工具重启之后颜色信息直接丢失团队里换个环境联调又得重新标一遍纯重复劳动。脚本规则的好处是“一劳永逸”。CustomRules.js保存后立即生效之后每个新产生的会话都会自动按规则着色。条件随便写颜色随便挑规则可以跟着项目走一套脚本吃遍所有环境。更重要的是规则是明文代码团队之间直接共享一个文件视觉标准就统一了。Fiddler本身也有内置的自动高亮规则但内置规则能匹配的条件非常有限而且对“根据字段或状态定制”这种需求支持得很弱。要真正解放双手还是得打开脚本自己写。2. Fiddler规则脚本入口CustomRules.js从哪里改2.1 打开脚本的正确姿势Fiddler的规则脚本入口只有一个核心文件CustomRules.js。打开方式很简单菜单栏点击 Rules - Customize Rules有些汉化版本叫“自定义规则”默认用记事本或系统关联编辑器打开。这个动作等效于直接打开文件它的物理位置一般在%USERPROFILE%\Documents\Fiddler2\Scripts\CustomRules.js如果你的系统文档目录被迁移到了其他盘以资源管理器打开后的实际路径为准。点击菜单后脚本会自动打开不必手动去翻文件夹。首次打开这个文件的人可能会被吓一跳里面已经有一大段默认代码定义了OnBeforeRequest、OnBeforeResponse两个静态函数还有一些辅助类。我们不需要理解全部内容只往这两个函数里添加判断逻辑就行。保存文件之后Fiddler会在一两秒内自动检测到脚本变更并重新加载不需要重启工具。如果保存后发现规则没有生效可以在Fiddler底部QuickExec命令行输入!reload强制重载一次。编辑脚本前建议先把原文件复制一份备份防止改坏了又没有留底。2.2 关键事件选择OnBeforeRequest和OnBeforeResponseCustomRules.js里有两个最关键的事件函数理解它们各自的触发时机是规则能不能生效的前提。第一个是OnBeforeRequest它在请求发出之前触发。这个阶段能拿到的是请求行、请求头、URL、Host、Method这些请求侧数据。所以凡是依赖请求字段的判断比如按域名标红、按URL关键字标红、按请求方法标红都应该写在这里。第二个是OnBeforeResponse它在响应返回之后触发。这个阶段才能拿到状态码、响应时间、响应头和响应体。按状态码标红、按接口耗时标红、按响应内容包含特定字段标红都只能放在这个事件里。如果你在OnBeforeRequest里判断状态码拿到的会是初始值判断永远不成立。有个容易被坑的细节如果在OnBeforeRequest里给某个会话设置了颜色而后请求走到了OnBeforeResponse另一个规则又给它设了别的颜色后者会覆盖前者。所以当规则变多之后最好把着色逻辑抽成公共函数两个事件都去调用让颜色由同一个逻辑决定而不是各写各的互相覆盖。后面展开说。2.3 设置颜色的核心APISessionFlagFiddler为每个会话维护了一组键值对叫做SessionFlag。其中这几个固定键和颜色、样式相关Flag键作用取值示例ui-backcolor会话行背景色#FF0000 或 redui-forecolor会话行字体颜色#FFFFFF 或 whiteui-bold字体加粗trueui-italic字体斜体trueui-underline下划线true在脚本里赋值的方式是直接操作oSession对象oSession[ui-backcolor] #FFCCCC; oSession[ui-forecolor] #CC0000; oSession[ui-bold] true;颜色格式支持两种命名颜色red、blue、green等和十六进制色值#FF0000这类。命名颜色简单但可选的少要精细控制深浅还是用十六进制方便。我习惯在规则文件顶部定义一套配色常量不同场景用不同颜色后面讲实战时会给出具体配色方案。这里稍微说明一下为什么用字符串true而不是布尔值true。SessionFlag存储的类型本质上是字符串虽然写true很多时候也能转成字符串但为了减少类型判断的意外我习惯显式写字符串形式。3. 实战按不同字段和状态写标红规则3.1 按HTTP状态码标红最基础的保命规则状态码着色是所有规则里最实用的一条它解决的是“满屏请求里快速锁定错误请求”的刚需。逻辑很简单4xx说明是客户端问题5xx说明是服务端故障300系列则是重定向。public static function OnBeforeResponse(oSession: Session) { // 服务端错误深红底 白字最醒目 if (oSession.responseCode 500) { oSession[ui-backcolor] #FF0000; oSession[ui-forecolor] #FFFFFF; oSession[ui-bold] true; } // 客户端错误浅红提示请求有问题但不至于崩 else if (oSession.responseCode 400) { oSession[ui-backcolor] #FFCCCC; } // 重定向浅黄方便观察跳转链路 else if (oSession.responseCode 300) { oSession[ui-backcolor] #FFFFCC; } }这段代码必须放在OnBeforeResponse里因为responseCode在请求发出前是拿不到的。实际体验下来5xx500、502、503、504用深红底白字加粗是整个列表里最有视觉冲击力的一个组合扫一眼就能定位到故障请求。4xx用浅红不打扰但又能明显区分正常请求。另外一个小建议如果页面上刷了一堆静态资源在OnBeforeRequest阶段先对静态资源请求做个短路判断比如.js、.css、.png结尾的请求压根不用走后面的状态码判断省得每次都得过一遍条件。public static function OnBeforeRequest(oSession: Session) { var url oSession.url.toLowerCase(); if (url.endsWith(.js) || url.endsWith(.css) || url.endsWith(.png)) { return; } }3.2 按域名Host区分标红联调环境一目了然联调时最痛苦的事就是浏览器一打开页面请求里的测试环境域名、线上域名、第三方域名全混在一起想找某个环境下的接口全靠肉眼识别主机名。按域名标红的逻辑写在OnBeforeRequest里最合适因为请求还没出去Host字段是现成的。public static function OnBeforeRequest(oSession: Session) { // 测试环境域名浅红背景提醒别搞混了 if (oSession.HostnameIs(api-test.example.com)) { oSession[ui-backcolor] #FFCCCC; oSession[ui-bold] true; } // 线上环境域名浅绿背景代表正常环境 if (oSession.HostnameIs(api-prod.example.com)) { oSession[ui-backcolor] #D5F5E3; } }这里的HostnameIs是精确匹配不带端口号。如果你的请求里带了端口比如api-test.example.com:8080用HostnameIs匹配可能会落空。更稳妥的做法是用oSession.host这个属性做indexOf包含判断var host oSession.host.toLowerCase(); if (host.indexOf(api-test) 0) { oSession[ui-backcolor] #FFCCCC; oSession[ui-bold] true; }域名一多靠散落的if语句维护起来会很费劲。我通常在脚本头部定义一个环境域名数组用循环去匹配规则文件看起来清爽很多。后面4.6小节会再展开。3.3 按URL关键字和请求方法标红精准锁定目标接口上面两小节解决了“哪些请求出错了”和“哪些环境要关注”两个问题。但在业务联调里经常要盯的是某一个特定业务接口比如下单、支付、登录。这时按URL关键字标红是最精准的做法。public static function OnBeforeRequest(oSession: Session) { // 包含order关键字的接口橙色背景重点关注 if (oSession.uriContains(order)) { oSession[ui-backcolor] #FFCC66; oSession[ui-bold] true; } // 登录接口浅蓝背景 if (oSession.uriContains(login)) { oSession[ui-backcolor] #CCE5FF; } // POST写操作字体标红加粗区分读和写 if (oSession.HTTPMethodIs(POST)) { oSession[ui-forecolor] #CC0000; oSession[ui-bold] true; } }这里补充一个易混点oSession.fullUrl是完整地址带协议和域名oSession.url是路径加查询串部分uriContains判断的是url内容。如果只想匹配某个具体路径片段直接写关键字即可比如uriContains(/api/v1/pay)和uriContains(pay)的命中范围完全不一样写的时候心里要有数。按方法标红有个用处POST、PUT、DELETE这类写操作比GET更需要关注字体标红能提个醒。但要注意这里用的是ui-forecolor只改字体颜色不改背景色可以避免和背景色规则叠在一起的时候视觉冲突。3.4 按响应内容包含关键字标红业务错误码的兜底方案状态码标红只能抓到HTTP层的错误但更常见的情况是接口返回200业务体里却写着errorCode: 50001。这种业务错误如果只靠状态码规则永远不会被标出来。解决办法是读取响应体在里面查业务关键字。public static function OnBeforeResponse(oSession: Session) { // 只对API接口做检查静态资源跳过 if (oSession.uriContains(/api/)) { var body oSession.GetResponseBodyAsString(); if (body body.Contains(errorCode) !body.Contains(\errorCode\:\0\)) { oSession[ui-backcolor] #FF9999; oSession[ui-bold] true; } } }这段代码的意图很直白凡是API接口响应里出现了errorCode字段而且值不是0假设0代表成功就标成粉红。用Contains做判断前一定先判空因为GetResponseBodyAsString在某些情况下返回的是空值直接调用会报错。还有个细节如果响应是Gzip压缩过的Fiddler在脚本层默认会自动解压文本流所以一般能直接读到可识别的字符串。遇到乱码或者读不到内容的情况先检查一下该会话的响应头里Content-Encoding字段确认是不是压缩格式没被解出来。3.5 按响应耗时标红提前暴露性能问题定位接口慢这个问题纯靠人工眼睛一遍遍刷新列表看Time列逐个比较几百毫秒和几秒的差异效率很低。更直接的做法是让超过阈值的慢请求自动变色。因为Fiddler内置的计时属性在不同版本上有细微差别我用一个通用的方案在OnBeforeRequest里记录当前时间戳存到会话的自定义flag里然后在OnBeforeResponse里读出来算差值。public static function OnBeforeRequest(oSession: Session) { // 记录发起时间 oSession[x-request-start] String(new Date().getTime()); } public static function OnBeforeResponse(oSession: Session) { var start parseInt(oSession[x-request-start]); if (!isNaN(start)) { var elapsed new Date().getTime() - start; if (elapsed 5000) { oSession[ui-backcolor] #FFFFCC; oSession[ui-bold] true; // 顺手把耗时写到备注列鼠标悬停能看 oSession[ui-notes] 耗时: elapsed ms; } } }超过5秒的请求标成淡黄色背景同时把具体耗时写进备注列排查时不用再自己去算差值。这个场景特别适合和老接口做性能回归的时候用阈值调到3000还是5000取决于具体项目直接在文件头部用常量控制会更好。这里注意一点存时间戳的flag名字不能和Fiddler内置flag冲突用x-前缀比较保险。同理写其他自定义flag也建议加前缀避免误覆盖系统字段。3.6 组合条件与优先级控制多规则不会乱成花猫如果上面的规则都往脚本里堆不加任何管理一个会话可能同时命中多个条件背景色和字体色被后写的语句覆盖来覆盖去最后呈现的颜色完全随机反而失去意义。我现在的做法是把着色逻辑统一收口到一个公共函数里按优先级从高到低依次判断一旦命中高优先级规则就直接return不再继续往下执行低优先级规则。两个事件统一调用这个函数。public static function ColorizeSession(oSession: Session) { // 重置颜色防止旧状态残留 oSession[ui-backcolor] ; // 优先级1服务端错误最高优先 if (oSession.responseCode 500) { oSession[ui-backcolor] #FF0000; oSession[ui-forecolor] #FFFFFF; oSession[ui-bold] true; return; } // 优先级2客户端错误 if (oSession.responseCode 400) { oSession[ui-backcolor] #FFCCCC; return; } // 优先级3慢请求 var start parseInt(oSession[x-request-start]); if (!isNaN(start)) { var elapsed new Date().getTime() - start; if (elapsed 5000) { oSession[ui-backcolor] #FFFFCC; return; } } // 优先级4指定域名和业务接口 if (oSession.HostnameIs(api-test.example.com) || oSession.uriContains(order)) { oSession[ui-backcolor] #FFCC66; oSession[ui-bold] true; } } public static function OnBeforeRequest(oSession: Session) { oSession[x-request-start] String(new Date().getTime()); ColorizeSession(oSession); } public static function OnBeforeResponse(oSession: Session) { ColorizeSession(oSession); }这样一套组合下来任何会话最多只有一种颜色而且颜色表达的含义是确定的深红是服务端挂了浅红是请求错了淡黄是太慢了橙色是命中了关注接口。整个列表看下来视觉层级非常清楚。4. 规则不生效、颜色串台常见问题与调试技巧实录4.1 保存后规则不生效规则写好后保存Fiddler却纹丝不动这是最常见的翻车现场。按以下顺序排查确认保存的文件确实是当前生效的CustomRules.js。有些机器上存在多个副本菜单打开的路径是最权威的参考别用文件夹里翻到的另一个文件改了半天。在QuickExec命令行输入!reload强制重载并观察Fiddler LogView - Log里有没有脚本报错信息。检查函数签名是否正确。OnBeforeRequest、OnBeforeResponse必须写成public static function少一个关键词Fiddler都不会调用。如果脚本里出现了语法错误整个脚本都会加载失败规则的失效范围是整个文件不只是写错的那一段。4.2 颜色一闪而过或者被其他规则覆盖场景是OnBeforeRequest里明明标了红色请求发完响应回来后颜色没了或变成了别的颜色。原因多半是你在两个事件里分别写了着色逻辑后触发的OnBeforeResponse里的赋值把前面的颜色覆盖了。这是新手最容易踩的坑也正好印证了前面3.6小节的方案把着色逻辑抽成公共函数两个事件统一调用从根上避免各写各的互相打架。还有一个小概率情况Fiddler对某些会话在内部会重置样式比如对某些自动请求或隧道请求。遇到这种判断一下该会话的类型在规则开头跳过非HTTP会话就行。4.3 颜色太刺眼或者满屏都是颜色规则加多了之后很容易出现下一页屏幕全是粉色橙色看着很热闹实际信息量没有提升。我的经验是控制颜色使用量深红背景只给5xx这种真正需要立刻处理的会话浅红给4xx不刺眼又能区分淡黄给慢请求浅绿给线上环境请求业务重点接口用橙色但数量必须少最好一个项目只标两三个。还有一种做法是“不加背景只加粗”。对于需要提醒但不紧急的会话设置ui-bold true就够了让背景颜色留给真正需要聚焦的错误和慢请求。4.4 JScript.NET语法坑导致整个规则文件崩掉Fiddler的脚本语言是JScript.NET语法上接近JavaScript但和浏览器里的JavaScript还是有一些差异。几个容易踩的坑字符串必须用双引号或单引号括完整漏了一个引号整个脚本直接编译失败方法名区分大小写Contains、HostnameIs、GetResponseBodyAsString大小写写错了不会报错但函数不执行函数里声明变量尽量用var避免隐式全局变量带来莫名其妙的变量污染公共函数必须写在两个事件函数之外不能嵌在事件函数里面。写完一段规则就保存一次这是最土但最有效的自检方式。等你一次性写完几百行再保存编译器报错之后定位错误位置是很痛苦的一件事。4.5 快速验证规则是否生效验证规则最快的方法是制造一个已知会命中条件的环境。比如你刚写完状态码标红就用浏览器去访问一个不存在的路径让服务器返回404看列表里那条记录有没有变成浅红或者故意用来一个返回500的测试接口看有没有变成深红。如果颜色没变说明规则没写对或脚本没重载按4.1的顺序排查。Fiddler自带的示例会话也适合用来验证脚本。菜单 File - Load Sample Sessions会生成一批带各种状态码的示例请求保存规则之后加载一批瞬间就能看出颜色逻辑是否正确。每次验证前可以先按CtrlX清空会话列表免得旧数据干扰观察。4.6 多套环境的规则管理最后聊点规则文件的工程化经验。如果你同时维护多个项目的调试环境建议把环境差异都收敛到脚本头部做成配置常量规则逻辑只读取这些常量不改中间判断。var TIMEOUT_MS 5000; var TEST_HOSTS [api-test.example.com, admin-test.example.com]; var BIZ_KEYWORDS [order, pay, refund];换项目时只改头部这一段颜色体系和判断逻辑完全不用动。规则文件做好命名备份比如CustomRules-order.js、CustomRules-pay.js在项目切换时直接替换文件再!reload即可。这套做法看起来简单但真正能省下不少切换环境时反复改脚本的功夫。我自己用这套规则大概五六年了最大的感受是它把“找问题”从主动扫描变成了被动接收颜色一亮目光就会自动聚焦过去根本不用从上到下翻列表。规则别贪多颜色别太满挑几个真正影响判断的状态和字段去标比什么都标红更实用。照着上面几个场景从状态码标红开始试慢慢往上加你会回来感谢这条规则的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
