企业官网建设流程全解析

我们用抓包工具，说到底就两个目的：一是看清楚网络上到底跑了什么数据，二是让这些数据按我们的想法走。Fiddler 就是干这个的祖师爷级工具，从我开始做开发到现在，它一直躺在我电脑的固定收藏夹里，论资历、论免费程度、论折腾空间，都是抓包调试绕不开的那一个。

这篇文章不是官方文档的翻译，是我把自己的使用习惯、踩过的坑、还有那些网上翻半天才找到的细节整理了一遍。适合刚接触抓包的新手，也适合用了很久但总在某些配置上卡壳的老朋友。不管是前端排接口、后端查问题、客户端调联调，还是测试同学验证数据准确性，这篇文章都能让你少走几趟弯路。另外我特意把移动端抓包、HTTPS 解密、断点改包这些高频场景拆开写，方便你按需跳读。

1. 先搞清楚Fiddler到底能干什么

1.1 抓包工具怎么选：Fiddler、Charles、浏览器DevTools的取舍

总能遇到人问：浏览器 F12 不是能看网络请求吗，为什么还要单独装一个 Fiddler？这个问题其实问到点子上了。

浏览器 DevTools 的 Network 面板确实方便，但它只能看到浏览器自己发出的请求，而且对请求的“干预”能力很弱——你可以看、可以复制，但想拦下来改一下再放行，基本做不到。而 Fiddler 站在系统层面的位置上，全盘接管了指定范围内的 HTTP/HTTPS 流量，这意味着它不仅能看到，还能掐住、篡改、转发、延迟、重放。

拿 Fiddler 跟 Charles 比，其实是两种风格。Charles 界面舒服、上手快，但在 Windows 生态里，Fiddler 的普及率和资料量明显更大。而且 Fiddler 是免费的，它的免费版覆盖了绝大多数开发调试场景；Charles 免费版有 30 分钟使用限制，虽然破解满大街都是，但商业软件终归有授权风险。我个人的态度是：能在免费工具里解决的，不给公司添麻烦。

Fiddler 还有一个 Charles 很难比的优势——FiddlerScript。它有一套基于 C# 的脚本机制，让你能自动改写请求、响应、模拟异常、注入逻辑。有些老工程师能用它写出接近商业测试工具的效果，这是 Fiddler 的灵魂。

1.2 Fiddler的核心工作流程：相当于给车装了流量计

理解 Fiddler 的工作方式，最好用一个类比。假设你要检查一辆车从 A 到 B 的每一段路上被加了多少油、踩了几脚刹车，你不能只盯着终点看，得在路中间装一个观察站。Fiddler 就是这个观察站，默认情况下，它让自己成了一台“中间人”，所有走了系统代理的流量都会先经过它，登记完再继续上路。

整个流程可以拆成四步：

1. 客户端（浏览器或 App）的请求发出来，走的是系统代理，指向 Fiddler 监听的 8888 端口。
2. Fiddler 接收到请求后，在 OnBeforeRequest 阶段给你一个下手的机会——改 URL、改 Header、改请求体，都在这步。
3. 请求被转发给真正的服务器，服务器返回响应后，响应同样回到 Fiddler，在 OnBeforeResponse 阶段你还能再改一次。
4. 最后，Fiddler 把改过的响应交还给客户端。

正是因为请求和响应都要从中间人这里过一遍，Fiddler 才能做到“看得到”的同时还能“动手脚”。理解了这个模型，后面所有的断点、修改、模拟操作其实都是在这几个时间点上下文章。我见过不少人卡在“为什么改了没生效”的问题上，最后发现是他改的位置不对，要么改早了被覆盖，要么改晚了没机会。所以先把这个四步流程图刻在脑子里，后面会省很多事。

2. 安装与关键配置：装好只是开始

2.1 安装与基础界面

Fiddler 的安装包很小，装完打开后第一眼看到的是密密麻麻的两栏表格，很多新手瞬间就懵了。其实左侧就是请求列表，右侧是选中某个请求后的详情区域，顶部是工具栏，左下角是状态栏。信息量大但不复杂，多点点就熟了。

几个最常用的区域先说一遍：

• 请求列表：每个会话一行，Type 代表请求类型，Host 是域名，URL 是路径，Body 是大小，Result 是状态码，Process 是哪个进程发出的请求。我最常用的排序方式是按 Process 分组，尤其是同时开着多个应用抓包时，能快速分清流量来源。
• 右侧顶部有 Statistics（字节统计）、Inspectors（请求/响应详情）、AutoResponder（自动响应）、Composer（请求构造器）等标签页。
• 左下角状态栏的 Capturing 标识，点一下可以暂停流量捕获。长时间挂机时我习惯先关掉，省得列表被噪音刷爆。

安装完后第一件事不是急着抓包，而是做几个基础配置，否则你只能看到 HTTP 请求，遇到 HTTPS 全是一堆“Tunnel to”标题的灰色条目，完全没法用。下面这些配置是必须做的。

2.2 必做的几项初始化配置

打开 Fiddler 后，按顺序走一遍：

首先，确认代理功能已经打开。在菜单栏点 Tools → Options → Connections，勾上 “Allow remote computers to connect”。这一步不仅影响手机抓包，有些本机不走默认代理的软件也要靠它才能把流量导进来。代理端口默认是 8888，一般不用改。要注意的是，如果你本机有别的服务恰好也占了 8888，比如某些开发框架的调试端口，那就得改一个冷门端口，否则 Fiddler 起不来。

然后确认 “Capture Network Traffic” 是开启状态，也就是 F12 按钮按下去后处于选中态。F12 是 Fiddler 的抓包总开关，很多人第一次打开工具发现看不到任何请求，多半是不知道按一下 F12 开启捕获。

第三个必选项是 HTTPS 解密。Tools → Options → HTTPS，勾选 “Capture HTTPS CONNECTs” 和 “Decrypt HTTPS traffic”。勾选后首次会弹窗让你信任 Fiddler 根证书，机器上的浏览器要选“是”，否则后面解密照样失败。这一步我放到下一节专门展开，因为它牵涉的东西比想象中多。

基础配置做完，最好立刻设置一下最小化到托盘。Tools → Options → General，勾选 “Minimize to System Tray” 和 “Systray when minimized”。很多后台抓包场景里，Fiddler 要一直开着但又不能老占着任务栏，这个设置非常实用，我记不清有多少次是靠着托盘里的 Fiddler 图标活下来的。

另外建议顺手把 “Quiet Mode” 的勾选取消掉，默认的提示音虽然有存在感，但在会议室里突然响一声还是挺尴尬的，能关赶紧关。

3. HTTPS抓包的原理与证书配置

3.1 为什么HTTPS默认抓不到明文

HTTP 的流量是明文传输，Fiddler 把它截下来直接就能读。但 HTTPS 不一样，它多了 TLS 加密层，真正内容的解密密钥只有客户端和服务器知道，第三方即使把数据包复制一份，拿到的也是一堆密文。

Fiddler 能解 HTTPS，靠的是“中间人”思路，也就是把自己伪装成一个被双方都信任的“邮差”。当客户端发出请求时，Fiddler 会伪造一份证书给客户端，客户端如果信任了这份证书，就会用它和 Fiddler 建立加密通道；Fiddler 再和真实服务器建立另一条加密通道。两条通道都掌握在 Fiddler 手里，所以它能把两边的密文都解开、阅读、甚至改掉再重新封上。

听起来像黑客技术，但其实这是所有抓包工具的标准做法。关键在于“客户端要信任 Fiddler 的根证书”——这就是证书配置的根本原因。如果你跳过证书信任这一步，看到的 HTTPS 请求会变成一个个 CONNECT 隧道请求，点进去只有一个锁图标，内容全是加密的，什么也看不了。

3.2 证书安装一条龙

证书操作听起来唬人，实际操作不难。我按步骤走一遍：

1. 在 Fiddler 里勾选 Decrypt HTTPS traffic，这时它会自动生成一份 Fiddler 根证书并装进 Windows 当前用户的信任区。
2. 桌面上打开 证书管理（Win+R 输入 certmgr.msc），在“受信任的根证书颁发机构”里能看到名为 DO_NOT_TRUST_FiddlerRoot 的证书，这就是刚才生成的那一份。
3. 如果是帮别人排查问题，或者浏览器不认这个证书，你需要手动导出：Fiddler 菜单 Tools → Options → HTTPS → Actions → Export Root Certificate to Desktop。导出的是一个 .cer 文件，双击安装时，存储位置要选“受信任的根证书颁发机构”，不要放错地方。

这里有个极易踩的坑：有些软件不走 Windows 系统证书库，它们用自己的证书逻辑，比如 FireFox 早期版本就是独立证书管理。这种浏览器抓包时需要单独把 Fiddler 证书导入 FireFox 自己的证书列表，否则 Fiddler 里看到的还是 CONNECT 隧道。还有一个容易被忽略的小点：如果你之前装了老版本 Fiddler，后续更新了软件，最好把旧证书删了重新信任一次，很多“抓包突然失效”的现象就是证书版本对不上造成的。

3.3 移动端证书与特殊坑

手机抓包最大的坎就是证书。电脑上装证书只要点几下，手机端的流程要绕一大圈。

先把 Fiddler 的证书导出到桌面，然后想办法把它弄到手机上。最简单的办法是启动一个本地静态文件服务，让手机浏览器通过 电脑IP:端口 直接下载这个证书文件。也可以用数据线传到手机，或者发到聊天工具再转存都可以，方式不拘一格，核心是让手机应用商店以外的浏览器能安装这份证书。

Android 和 iOS 的安装方式不太一样。Android 上，我把证书文件下载后，在设置里搜索“证书安装”，选择 CA 证书。比较新的 Android 版本会警告你“此证书是第三方签发的系统级凭证”，确认安装即可。iOS 上则是下载后去“描述文件”里点击安装，装完还有一步容易漏：在“设置 → 通用 → 关于本机 → 证书信任设置”里打开开关，否则 Safari 认识但 App 不认识。

真正的坑在 Android 7.0 之后。这个版本开始，App 默认只信任系统证书，用户手里单独安装的证书会被当成“用户证书”放一边，很多 App 的 HTTPS 流量依然解密不了。这只影响你自己调试某些第三方 App 时看到的流量，开发自己 App 时通常不碍事，因为你可以调整应用的网络安全配置去信任用户证书。如果你只是排查自己的应用，建议先确认代码里的证书校验逻辑是不是默认值。如果实在要抓第三方 App 的流量，普通抓包工具都得绕一大圈，这个话题我不展开，但至少你要知道问题的根源在哪，别傻傻以为是 Fiddler 设置错了。

4. 移动端抓包调试：从PC到真机

4.1 局域网代理配置

手机抓包的场景太常见了：接口在电脑上跑得好好的，手机上却各种报错，十有八九是移动端环境的网络配置和 PC 不同步。Fiddler 就是用来把这种差异抹平的。

先把手机和电脑连到同一个局域网，避免用访客网络，有些访客网络开了“AP 隔离”，手机和电脑互相根本不通。电脑上确认 Fiddler 已经勾了 “Allow remote computers to connect”，记下电脑的局域网 IP——命令行里 ipconfig 就能看到，一般是 192.168.x.x 或 10.x.x.x 这种。

手机端 Wi-Fi 设置里，把代理改成手动，主机名填电脑的 IP，端口填 8888。保存之后，手机上的流量就会先经过 Fiddler。此时 Fiddler 的列表里能看到手机发出的请求，这就成功了。

这里有个很隐蔽的问题：手机代理配置完之后，如果手机上所有 App 的网络都断了，但浏览器能打开网页，那多半是代理本身通，但 HTTPS 证书不受信任造成的。浏览器能连是因为你装了证书，App 连不上是因为它们有独立的证书校验，这种问题不是在代理配置层面能解决的，得从证书信任角度入手排查。

4.2 Android/iOS真机抓包要点

Android 上抓包时，我最常遇到的是“连接成功但没有任何 App 流量”的情况。首先检查 App 是不是把系统代理给禁了，一些做得比较安全的 App 会显式忽略系统代理设置，流量直连路由器不走 Fiddler。碰到这种，Fiddler 无能为力，只能换更底层的方案，但那是另一条技术路线了，这里不展开。

iOS 抓包时的流程基本上和 Android 一样，但有个额外环节：装完证书去设置里信任一下。不少人在 iOS 上抓包失败，就是因为漏了“证书信任设置”这一层开关。另外 iOS 对代理配置的反应也比较“硬”，改代理后如果上一轮 HTTPS 请求还挂着，经常要等一会儿或者开关一下 Wi-Fi 才能生效，不是立刻切换。

无论 Android 还是 iOS，检查移动端流量时建议把 Fiddler 左下角的 “All Processes” 过滤条件改成只显示来自手机 IP 的会话，这样列表干净很多。在 Filters 标签页里勾选 “Show only traffic from”，填入手机 IP，这一步能救命。

4.3 WebSocket与网络条件模拟

移动端调试经常涉及长连接场景，比如 IM 消息、实时定位、在线状态的推送。Fiddler 对 WebSocket 的支持是内建的，但默认界面不显眼。抓到 WebSocket 请求后，右侧 Inspector 里会多出一个 “WebSocket” 标签页，里面能看到帧消息列表，每个消息都可以单独选中查看明文内容。

想看这类长连接能不能在弱网下顶住，用 Fiddler 的 “Simulate Modem Speeds” 功能就够了。菜单 Rules → Performance → Simulate Modem Speeds，打开后所有请求都会被限速到 56kbps 拨号时代的速度，用来测弱网交互体验很粗暴但有效。如果想更精细地控制上传和下载带宽、丢包率，可以写 FiddlerScript 在 OnBeforeRequest 里给 session 加oSession["request-trickle-delay"]这种属性，按毫秒为单位模拟任意延迟。这种灵活程度在别的工具里得找半天，Fiddler 里就是几行代码的事。

5. 断点调试与请求篡改：核心玩法

5.1 全局断点与命令断点

Fiddler 最让我上头的，是它能把请求“掐住”改完再放出去。全局断点就是这样一个开关：菜单 Rules → Automatic Breakpoints 里选择 Before Requests，所有请求都会在发出去之前暂停，列表里对应会话左侧会出现一条红色小竖杠。此时点击请求，在右侧 Inspector 里修改任何东西，改完点 “Run to Completion” 放行；响应也是同理，在 After Responses 模式下所有响应会卡在手里，你可以改完响应内容再还给客户端。

全局断点的杀伤力太大，同时开着多个请求要一个个点放行，繁琐得让人崩溃。实际工作中我更常用命令行断点：在 Fiddler 左下角 QuickExec 输入框里直接敲bpu example.com，这会在 URL 包含 example.com 的请求上打断点，命中后再输入bpu（不带参数）就取消。响应断点则是bpafter。

拿一个最常见的排查场景说：前端页面调接口，接口字段返回了 null，但你怀疑后端其实返回了数据，只是前端解析错了。这时用bpafter 接口地址打断点，响应回来后先不发给页面，你在 JSON 响应里把那个字段改成预期值，再放行。页面如果正常显示，就说明前端解析没问题，问题定位到后端；页面还是空白，说明前端解析确实有 bug。一个断点就能把责任边界划得清清楚楚。

5.2 用AutoResponder实现本地替换

AutoResponder 是 Fiddler 的“影子武器”。它能在请求不离开本机的情况下，直接返回你指定好的响应。最典型的用途是：接口挂了、后端还没写好、或者响应数据结构不合理，你用它临时返回一份预期的 JSON，让前端开发不阻塞。

操作流程：右键一个请求 → Save → Response → Save Response Body，把响应存成文件；然后在 AutoResponder 标签页勾选 Enable rules，点 Add Rule，上面填匹配规则，下面选择刚才那个文件。这么一来，所有符合匹配规则的请求都会直接用本地文件应答，这只“替身”甚至不会真的打到服务器。

有个细节值得留意：如果请求里带了时间戳或签名参数，直接匹配 URL 会失效。你可以把匹配规则设置成带正则的形式，比如regex:(?insx).*\/api\/user.*，再结合匹配优先级调整。另外调试完千万记得关掉 AutoResponder 总开关，我自己最少有三次忘了关，导致“线上环境怎么变了”的乌龙，最后发现是本机规则在捣乱。这种低级错误一犯再犯，所以现在养成习惯：每次离开电脑前，看一眼 AutoResponder 是否处于关闭状态。

5.3 Composer：手工构造请求

Composer 在 Fiddler 右侧最上方标签页里，功能是让你手工构造一个请求并发送。看起来简单，用好了非常强。排查线上问题时，你需要验证“不带 Header 会怎样”“参数少了会怎样”，直接在 Composer 里改完点 Execute，几秒内就能看清服务端响应，完全不用动代码。

最关键的使用技巧是：先在左侧列表里选中一条真实请求，右键 → Copy → Headers Only 或者 Copy → Full Request，然后切到 Composer 粘贴，基要内容全部带上了，你只需要改自己想改的几个字段。这比从零敲一个请求靠谱一百倍，因为实际请求里的 Cookie、UA、时间戳等细节少一个，结果都可能完全不同。

构造请求时习惯性检查几个点：POST 请求的 Content-Type 是否和接口文档一致、Cookie 是否带全、是否有必要的签名参数。还有一点经验：Composer 里的请求默认不经过断点规则，就是说它更“直愣愣”地直接发出去。需要走断点调试时，用菜单里的 “Replay” 功能更合适，重放的请求会完整经过 Fiddler 的各项规则，更容易配合断点定位问题。

6. FiddlerScript与实用插件扩展

6.1 先用FiddlerScript解决重复工作

FiddlerScript 是 Fiddler 最有深度的地方，说白了它就是在每次请求和响应经过 Fiddler 时触发的一段 C# 脚本。默认脚本在 Fiddler 菜单 Tools → FiddlerScript Editor 里打开，里面有 OnBeforeRequest 和 OnBeforeResponse 两个主要方法，你写的代码就嵌在函体里执行。

举一个我经常用的例子。后端接口列表返回里有个字段叫debugtrace，联调时我需要看到它，但正常响应里它被压成了一个很深的 JSON 节点，每次都要去 Inspector 里层层展开。写几行脚本：

if (oSession.HostnameIs("api.example.com") && oSession.PathAndQuery.Contains("/user/list")) { oSession["ui-color"] = "red"; oSession["ui-bold"] = "true"; }

这段代码没有改数据，只是把符合规则的请求在列表里标记成红色加粗，方便在海量请求里一眼锁定。再比如自动给所有响应插入一个调试 Header：

static function OnBeforeResponse(oSession: Session) { if (oSession.oResponse != null) { oSession.oResponse.headers.Add("X-Debug-Server", "fiddler-proxy"); } }

这类小把戏一方面节省重复劳动，另一方面能帮你在团队里建立“这就是老手”的形象。遇到更复杂的需求，脚本里还能调用 .NET 类库，读取文件、操作正则、外发请求都不在话下。你在网上看到的各种花式玩法，九成都是靠这段脚本实现的。

6.2 值得装的几类插件

Fiddler 的插件生态不算活跃了，但有几类插件我认为还是能显著提升效率的。

第一类是语法高亮插件。Fiddler 自带的 Inspectors 对 JSON 的处理说不上友好，内容一长就难读。装一个语法高亮插件后，JSON、XML、JavaScript 的响应内容会分行着色，字段名一目了然，逻辑很快就捋清了。

第二类是响应对比插件。两个请求响应内容不同，肉眼比对太费劲，这类插件提供类似文本 diff 的视图，直接把差异行标出来。排查回归测试里“这个版本改了什么”的时候，效率提升非常明显。

第三类是自动化相关的小工具，比如批量保存响应、批量导出会话的扩展。这类工具看起来不起眼，但当你需要把 200 个请求的响应全部保存下来分析时，它们能救你一命。插件的安装方式一般就是下载 DLL 放进 Fiddler 的 Scripts 目录，重启后就在 View 或 Tools 菜单里出现。实在找不到合适的插件，也可以自己在 FiddlerScript 里实现大半功能。

6.3 数据导出与自动化集成

Fiddler 抓到的东西不只是看看，很多时候要沉淀成文档给别人用，或者喂给自动化检查系统。

导出最常用的是右键选中若干请求，File → Export Sessions → Selected Sessions，格式里我最常用的是 HTTPArchive v1.2 格式，也就是 .har 文件。这个格式是行业通用的，可以直接导入很多在线分析工具，也能用脚本做后续处理。写接口调试记录时，导出一份 .har 发给对接方，比截图靠谱得多，因为它包含完整的请求与响应数据。

更进一步，你完全可以把 Fiddler 变成自动化测试基础设施的一部分。之前在某个项目里做过一个脚本：定时从 Fiddler 导出 .har 文件，再用 Python 解析，自动找出 4xx/5xx 请求并按 URL 统计数量，最后把报告发到消息群。整个流程没有任何商业工具的依赖，仅凭 Fiddler 的导出能力和日常脚本就能完成。这个思路值得参考，很多人以为 Fiddler 只是个“看得见的工具”，忘了它背后还有可以编程化使用的数据出口。

7. 高频异常与排查手册

7.1 连接被拒绝/代理不起作用的排查

最让人抓狂的问题是：Fiddler 明明开着，抓包列表就是空的，或者某个 App 完全连不上网络。

先按这个顺序排查：

1. 确认 Fiddler 处于捕获状态，左下角 Capturing 是否高亮。这个小问题占了四成以上“抓不到包”的原因。
2. 确认代理端口没有冲突。Win 上可以命令行执行netstat -ano | findstr 8888看看端口被谁占用。
3. 确认抓包对象走的确实是系统代理设置。有些软件不读系统代理，比如一些游戏、命令行工具，这种情况 Fiddler 默认是抓不到的，需要单独配置应用内代理，或者做端口转发。
4. 抓本机回环流量时，如果客户端连接的是 localhost 或 127.0.0.1，WinHTTP 默认不走代理，Fiddler 会悄悄漏过这些流量。解决办法是在 QuickExec 里执行!looptrick命令，或者在 FiddlerScript 里把请求的 Host 改写为机器名再放行。

还有个非常灵异的现象：Fiddler 开着的时候全部网站都上不去。这通常不是 Fiddler 的问题，而是系统代理被设置成指向 Fiddler，但 Fiddler 没正常监听。检查 Options → Connections 里端口是否真的在监听，以及是否被防火墙拦截了。Win 防火墙初次运行时弹窗如果选了“取消”，后续 Fiddler 基本就没法接受外部连接了，需要手动放行。

7.2 证书问题的典型场景

证书问题在抓包领域是老大难，我把高频场景整理成速查表：

证书问题有一个通用心态：别浮躁，仔细确认每一步的信任层级。多数失败不是大方向的问题，而是中间某层没信任到位。另外抓包结束后，Fiddler 的根证书会一直留在机器里，敏感环境下建议抓完包就把证书删掉，别留后门。

7.3 性能相关：慢、卡、丢包

Fiddler 本身是个轻量级工具，但如果你把它开在大流量环境里，出现卡顿并不奇怪。我在一次压力测试场景里遇到过一个特别离谱的现象：开着 Fiddler 当观察窗口，结果上千个并发请求全挤在一起，UI 彻底卡成 PPT。

这种情况下的最优解是：不要把 Fiddler 当成流量记录仪长时间挂着，而是用它的脚本机制把不关心的会话直接丢弃。比如：

if (oSession.uriContains(".png") || oSession.uriContains(".jpg") || oSession.uriContains(".css")) { oSession["ui-hide"] = "true"; }

把它加在 OnBeforeRequest 里，图片和样式资源请求就自动隐藏了，列表里的噪音立刻少很多。如果想省内存，还可以在上面的逻辑里直接oSession.oRequest.FailRequest()终止一些完全无关的资源加载，不过这个方法要小心，它真的会切断客户端的资源请求。

7.4 我的一些操作习惯

整理几条习惯，都是我实际工作中沉淀下来的，有些是在吃亏之后才形成的。

第一条是勤用 QuickExec 命令行。Fiddler 左下角那个输入框远不止 bpu、bpafter 两个命令，cls可以清空列表，select可以按类型过滤，hide和show可以隐藏显示特定会话。熟练之后工作效率完全不一样。

第二条是有意识地使用 Filter 而不是靠眼睛找。顶部 Filters 标签页提供了丰富的过滤条件，比如只显示某个域名、只显示某个状态码、只显示自定义 regex 匹配的内容。我在排查接口问题时，都会先把这些条件设置好，再开始操作，这样整个调试过程不会被无关流量干扰。

第三条是给常用请求建“收藏夹”。右键一个请求 → Add to Session Archive，之后在右侧的 Archives 面板里随时能调出来。调试同一个接口时，每次重放之前的收藏请求比重新构造节省大量时间。

最后再说两句

写了这么多，现在反而觉得 Fiddler 最厉害的地方不是某个具体功能，而是它把“查看流量”和“操控流量”这两件事揉成了一个整体。你用浏览器开发者工具也能看，用模拟器也能测，但只有当你真的能在请求发出去的瞬间改掉它、在响应回来的路上调整它，很多刁钻问题才真正有了下手点。我自己的体会是，学 Fiddler 最好的方式就是把一个真实接口反复玩——下载响应、改参数、断点放行、模拟超时，一套流程走完，比看十篇教程都有用。

如果你以后遇到一个看似诡异的问题，记得先打开 Fiddler 看一眼真实数据再下结论。很多时候答案就藏在那条被人忽略的请求里。