3. Fiddler 核心界面详解：Web Sessions 列表、Inspectors 面板、AutoResponder、Composer、Filters
说实话，Fiddler 这工具我用了快十年。刚入行那会儿，看着满屏的请求列表，心里直发怵。后来带团队，发现新人第一周基本都卡在界面上——按钮太多，不知道点哪个。
这一章，我就带你把这五个核心模块摸透。不用死记硬背，跟着我的思路走一遍，你自然就懂了。
本章核心脉络：Fiddler 的五个面板，分别对应抓包的五个阶段——看请求、查详情、改响应、发请求、筛数据。下面这张图帮你建立整体认知。
3.1 Web Sessions 列表——你的请求日志
打开 Fiddler 后，左边那个密密麻麻的表格就是 Web Sessions 列表。说白了，它就是所有经过 Fiddler 的 HTTP/HTTPS 请求的流水账。
每一行代表什么？
- #：请求序号，从 1 开始递增。我习惯用它来定位问题请求。
- Result：HTTP 状态码。200 正常，404 找不到，500 服务器炸了——这些你得一眼认出。
- Protocol：HTTP 版本，通常是 HTTP/1.1 或 HTTP/2。
- Host：请求发往的服务器域名。
- URL：请求路径和参数。注意看有没有敏感信息泄露。
- Body：响应体大小，单位字节。如果某个请求返回了 10MB 的 JSON……嗯，那肯定有问题。
- Content-Type：返回的数据类型，比如 text/html、application/json。
- Process：发起请求的进程，比如 Chrome.exe、你的 Java 后端。
我的小习惯：双击任意一行，右侧 Inspectors 面板会自动展示该请求的详细数据。另外，选中多行后按 Ctrl + C 可以复制为文本格式，方便贴到群里讨论。
颜色编码：Fiddler 默认用颜色区分请求类型——灰色是 CONNECT 隧道（HTTPS 握手），红色是服务端错误（5xx），黄色是客户端错误（4xx），绿色是图片等静态资源。我在项目中遇到过好几次，开发说“接口没问题啊”，结果我一看列表里飘红一片……嗯，你懂的。
3.2 Inspectors 面板——请求和响应的解剖台
Inspectors 面板在右侧，分上下两部分：上面是请求（Request），下面是响应（Response）。每个部分又有多个子视图。
请求部分常用视图：
- Headers：查看请求头，比如 Cookie、User-Agent、Referer。有一次我排查 CSRF 问题，就是在这里发现 Referer 头没带。
- Cookies：专门看 Cookie，支持增删改。调试登录态时特别有用。
- Raw：原始请求报文，纯文本格式。适合复制出来做对比。
- JSON：如果请求体是 JSON，这里会格式化展示。我几乎天天用。
响应部分常用视图：
- Headers：响应头，比如 Set-Cookie、Cache-Control、CORS 头。
- JSON：格式化后的 JSON 响应体。我最常用的视图，没有之一。
- ImageView：如果响应是图片，直接在这里预览。
- WebView：把 HTML 渲染成网页。不过说实话，我很少用，因为 Fiddler 的渲染引擎比较老。
注意：Raw 视图展示的是完整的 HTTP 报文，包括空行和换行符。如果你要手动构造请求，最好从 Raw 视图复制，而不是从 Headers 视图拼凑——我曾经因为少复制了一个换行符，排查了半小时。
3.3 AutoResponder——让服务器按你的剧本走
AutoResponder 是我个人最喜欢的模块。它的作用很简单：拦截某个请求，直接返回你指定的响应，而不去真的访问服务器。
什么时候用？
- 后端接口还没写好，前端需要先调试。
- 某个接口返回了错误数据，你想看看前端怎么处理。
- 想模拟超时、404、500 等异常场景。
怎么用？ 三步走：
- 从 Web Sessions 列表拖一个请求到 AutoResponder 面板。
- 勾选 “Enable rules” 和 “Unmatched requests passthrough”。
- 在下方选择 “Find a file…” 指定本地 JSON 文件，或者直接编辑响应内容。
举个例子：假设你的登录接口 /api/login 返回 {"token": "abc"}。你想测试前端在 token 为空时的表现。在 AutoResponder 里把响应改成 {"token": ""}，保存后刷新页面——前端直接拿到空 token，你就能观察它有没有做空值判断。
我曾经用 AutoResponder 模拟过一个第三方支付回调，省去了每次都要真金白银去调支付的麻烦。嗯，省了不少测试经费。
3.4 Composer——手搓 HTTP 请求
Composer 翻译过来是“作曲器”，说白了就是让你手动构造并发送 HTTP 请求的工具。
适用场景：
- 想复现某个请求，但不想重新操作页面。
- 想修改请求参数，看看后端会不会报错。
- 测试接口是否支持 GET/POST 以外的 HTTP 方法。
操作方式：
- 从 Web Sessions 列表拖一个请求到 Composer 面板。
- 修改 Method、URL、Headers 或 Body。
- 点击 “Execute”，请求会立即发出，结果出现在 Web Sessions 列表里。
我的经验：Composer 支持 Ctrl + Enter 快速发送请求。另外，如果你要批量测试，可以写一个简单的 Python 脚本配合 Fiddler 的 API，但那是进阶内容了。初学者先用 Composer 手搓就行。
常见坑：修改请求头时，注意 Content-Length 要跟 Body 实际长度一致。如果不一致，服务器会一直等待，直到超时。我曾经因为这个坑，被后端同事追着问“你是不是在搞我”。
3.5 Filters——从噪音中提取信号
默认情况下，Fiddler 会抓取所有流量。你打开一个网页，可能瞬间产生几十上百个请求——图片、CSS、JS、字体、埋点……看得眼花缭乱。
Filters 就是用来做减法的。
常用过滤规则：
| 过滤条件 | 说明 | 我的使用频率 |
|---|---|---|
| Hosts → Show only the following Hosts | 只显示指定域名的请求 | ⭐⭐⭐⭐⭐ |
| Request Headers → Hide if URL contains | 隐藏包含特定关键字的请求 | ⭐⭐⭐⭐ |
| Response Status Code → Show only | 只显示特定状态码（如 200、404） | ⭐⭐⭐ |
| Content-Type → Show only HTML/JS/CSS | 只显示特定类型的响应 | ⭐⭐⭐ |
怎么开启？ 点击 Filters 标签页，勾选 “Use Filters”，然后配置规则。注意：修改规则后要点击 “Actions → Run Filterset now” 才会生效。
避坑指南：我曾经在调试一个支付页面时，忘了关掉 “Show only the following Hosts” 规则，结果支付回调的请求来自另一个域名，直接被过滤掉了。我盯着列表看了十分钟，心想“怎么没回调？”，最后才发现是过滤器搞的鬼。所以，调试跨域请求时，记得检查过滤器。
进阶技巧：Filters 支持正则表达式。比如你想过滤掉所有包含 .min.js 或 .min.css 的请求，可以在 “Hide if URL contains” 里写 \.min\.(js|css)。正则表达式不熟？没关系，先用简单的字符串匹配，慢慢来。
好了，五个核心面板都讲完了。你可能会问：“这么多功能，我该先学哪个？” 我的建议是：先熟悉 Web Sessions 列表和 Inspectors 面板，这两个是日常调试的基石。AutoResponder 和 Composer 等你遇到具体需求时再学，上手很快。Filters 嘛……等你被海量请求淹没时，自然会想起它。