Postman与Fiddler双剑合璧：从零到精通的接口测试与调试实战指南

📅 2026/7/4 12:32:31 👁️ 阅读次数 📝 编程学习
Postman与Fiddler双剑合璧：从零到精通的接口测试与调试实战指南

1. 项目概述：从“抓瞎”到“门清”的接口测试之路

刚入行做开发或者测试的时候，最怕的就是联调。前端说接口返回不对，后端说请求参数有问题，两边对着空气扯皮，问题在哪？不知道，感觉就像在“抓瞎”。后来，我逐渐把Postman和Fiddler这两款工具用成了“黄金搭档”，才真正把接口测试和调试这件事搞“门清”了。今天，我就以一个过来人的身份，手把手带你走一遍从零开始，用Postman和Fiddler完成一次完整API接口测试与调试的全过程。这不仅仅是工具操作，更是理解前后端数据流转、定位问题根源的实战思维。

Postman，你可以把它理解为一个功能极其强大的“高级浏览器地址栏”，专门用来构造、发送各种HTTP/HTTPS请求，并查看服务器返回的响应。它擅长主动出击，模拟客户端行为。而Fiddler，则更像一个部署在你自己电脑上的“交通警察”或“网络监听器”，它能捕获并记录你的电脑与互联网之间所有的HTTP/HTTPS通信流量，无论是浏览器、手机App还是Postman发出的请求，都逃不过它的“法眼”。它擅长被动监听，分析真实流量。一个负责“攻”（模拟请求），一个负责“守”（监听分析），两者结合，就能让你对接口的来龙去脉了如指掌。

无论你是刚接触接口测试的新手，还是希望优化现有工作流的开发者、测试工程师，这篇文章都能给你一套清晰、可落地的实操方案。我们会从最简单的GET请求开始，逐步深入到带复杂参数、身份认证的接口，再到如何利用Fiddler抓包分析、模拟异常场景，最后串联起来解决一个真实的调试问题。过程中所有步骤、截图和参数设置，你都可以直接“抄作业”。

2. 核心工具定位与协同工作流解析

2.1 Postman：你的专属接口“构造器”与“测试台”

Postman的核心价值在于其主动性和可编程性。它不是简单地发送请求，而是提供了一个完整的沙盒环境，让你能精细化地控制请求的每一个细节。

为什么是Postman，而不是浏览器地址栏或CURL？浏览器地址栏主要方便，但功能单一，只能发起简单的GET请求，难以设置复杂的请求头（Header）、请求体（Body），更别提自动化测试和参数化。CURL命令虽然强大，但命令行操作对新手不友好，且结果展示和用例管理不便。Postman提供了一个图形化界面，将HTTP协议的复杂性封装成直观的输入框、下拉菜单和标签页，大大降低了使用门槛。更重要的是，它支持集合（Collections）、环境变量（Environments）和测试脚本（Tests），这意味着你可以将一系列相关的接口请求组织起来，为不同环境（开发、测试、生产）配置不同的变量（如域名、密钥），并能编写JavaScript脚本对响应结果进行自动化的断言验证，实现半自动化甚至全自动化的接口测试。

一个典型的Postman工作流包括：

  1. 新建请求：选择方法（GET, POST, PUT, DELETE等），输入URL。
  2. 配置请求：在Params、Authorization、Headers、Body等标签页下，填写查询参数、认证信息、请求头和请求体（如JSON, Form-data）。
  3. 发送与查看：点击Send，在下方面板查看状态码、响应时间、响应头和响应体。
  4. 测试与自动化：在“Tests”标签页用JavaScript编写断言，验证响应状态码是否为200，响应体是否包含某个字段或值。
  5. 保存与管理：将请求保存到某个集合中，方便下次直接调用或与团队共享。

注意：很多新手会忽略“Pre-request Script”和“Tests”这两个标签页。前者可以在发送请求前执行脚本（如生成时间戳、计算签名），后者用于请求后验证。这是Postman从“工具”进阶到“平台”的关键。

2.2 Fiddler：网络流量的“显微镜”与“手术刀”

如果说Postman是你在明处打出的“拳”，那么Fiddler就是在暗处观察“拳路”和“对手反应”的摄像机。它是一个代理服务器，工作时会将自己设置为系统或应用程序的代理。所有流经它的网络请求和响应都会被记录下来。

Fiddler能帮你解决哪些Postman单独搞不定的问题？

  1. 查看“真实”的请求：你可能会疑惑，我在Postman里明明设置了这些参数，为什么后端说没收到？用Fiddler抓一下从Postman发出的包，你就能看到经过网络层后，请求体、请求头的最终形态，确认是否有编码错误、多余空格或格式问题。
  2. 调试前端问题：当网页或App出现接口错误时，你无法直接修改其请求代码。用Fiddler抓取前端发出的请求，分析其参数、Cookie、Token是否正确，甚至可以直接修改请求或响应进行调试（断点功能）。
  3. 模拟弱网与异常：Fiddler可以模拟低速网络（2G/3G）、高延迟和丢包，测试应用在网络不佳情况下的表现。还可以设置自动响应（AutoResponder），用本地文件或自定义数据替换服务器响应，模拟服务器返回错误码、超时等异常场景。
  4. 分析性能瓶颈：通过时间线视图，可以清晰地看到一个页面加载过程中各个请求的发起顺序、阻塞情况、耗时长短，精准定位性能瓶颈。

Fiddler Classic vs Fiddler Everywhere：目前Fiddler主要有两个版本。Classic是传统的Windows桌面应用，免费、功能强大，但界面相对老旧。Everywhere是跨平台（Win/Mac/Linux）的新版本，采用订阅制，界面更现代，但部分高级功能需要付费。对于初学者和大多数日常抓包需求，Fiddler Classic完全够用。本文演示也以Fiddler Classic为主。

2.3 双剑合璧：Postman + Fiddler 协同工作流

理解了各自的特长，就能设计出高效的协同流程。一个完整的调试过程通常是这样的：

  1. 初步验证（Postman）：拿到接口文档后，首先在Postman中构造请求，尝试能否成功调用。这一步是基础功能验证。
  2. 问题复现与抓包（Fiddler）：如果接口调用失败，或者返回结果不符合预期，打开Fiddler，确保其正在捕获流量（左下角“Capturing”为开启状态）。然后在Postman中重新发送一次问题请求。
  3. 流量分析（Fiddler）：在Fiddler的会话列表中找到刚才Postman发出的请求，查看其详细内容。对比你在Postman中设置的，和实际发出的，是否一致？重点检查URL、Headers（尤其是Content-Type、Authorization）、请求体。
  4. 修改与重试（Postman）：根据Fiddler的分析结果，回到Postman调整请求参数，再次发送。同时可以在Fiddler中清除旧会话，观察新的请求流量。
  5. 模拟与调试（Fiddler）：对于某些难以在开发环境复现的问题（如特定的服务器错误响应），可以使用Fiddler的AutoResponder功能，拦截指定请求并返回一个你预设的错误响应，然后在Postman或前端观察应用的处理逻辑是否正确。
  6. 自动化与回归（Postman）：问题解决后，将正确的请求配置和断言脚本在Postman中保存好，纳入测试集合，方便后续回归测试。

这个流程将主动测试和被动监听完美结合，让你既能“制造”请求，又能“看见”通信，真正做到心中有数。

3. 实战第一步：用Postman完成基础接口测试

让我们从一个最经典的场景开始：测试一个用户登录接口。假设接口文档如下：

  • URL:https://api.example.com/v1/auth/login
  • 方法: POST
  • 请求体 (Body): JSON格式，{"username": "testuser", "password": "123456"}
  • 成功响应: 状态码200，返回JSON包含{"code": 0, "message": "success", "data": {"token": "eyJhbGciOiJ..."}}

3.1 安装与初识Postman

首先，去Postman官网下载安装包。安装过程很简单，一路下一步即可。安装完成后打开，可能会提示你登录或注册。对于个人基础使用，可以点击左下角“Skip and go to the app”暂时跳过。主界面主要分为左侧的导航栏（侧边栏）和右侧的工作区。

创建你的第一个请求：

  1. 点击左上角的“New”按钮，选择“HTTP Request”。这会创建一个新的请求标签页。
  2. 在请求方法下拉框中，选择“POST”。
  3. 在地址栏输入完整的URL：https://api.example.com/v1/auth/login。
  4. 切换到“Body”标签页。
  5. 选择“raw”，并在右侧格式下拉框中选择“JSON”。
  6. 在下方的编辑区，输入我们的JSON请求体：
    { "username": "testuser", "password": "123456" }
  7. 点击巨大的蓝色“Send”按钮。

发送后，下方会弹出响应面板。你会看到状态码（如200 OK）、响应时间、以及响应体。如果接口正常，响应体里应该能看到返回的token。

实操心得：在输入URL时，注意http和https的区别。现在绝大多数API都使用https。如果遇到SSL证书错误，可以在Postman的设置（Settings）中暂时关闭“SSL certificate verification”，但这仅用于测试环境，生产环境切勿关闭。

3.2 玩转请求参数与认证

实际接口远比登录复杂。我们来看看Postman如何处理各种常见参数。

1. 查询参数（Query Params）对于GET请求，参数通常以?key1=value1&key2=value2的形式附在URL后面。在Postman中，你不需要手动拼接。只需切换到“Params”标签页，以键值对的形式输入即可，Postman会自动帮你拼接到URL里。例如，测试一个获取用户列表的接口：GET https://api.example.com/v1/users，需要分页参数page=1&size=10。在Params页添加两行，Postman会自动生成URL为https://api.example.com/v1/users?page=1&size=10。

2. 路径参数（Path Variables）当URL中包含动态部分时，如GET /v1/users/{userId}。在Postman中，你可以直接在URL里写https://api.example.com/v1/users/123。更优雅的方式是使用变量：写https://api.example.com/v1/users/:userId，然后在Params标签页的“Path Variables”子选项卡中，为:userId设置值123。这种方式在参数需要频繁更改时非常方便。

3. 请求头（Headers）很多接口需要在请求头中传递信息，如Content-Type（声明请求体格式）、Authorization（身份令牌）。Postman的“Headers”标签页用于管理它们。当你选择Body格式为JSON时，Postman通常会自动添加Content-Type: application/json。对于认证，常见的Bearer Token认证，你需要手动添加一个Header：Key为Authorization，Value为Bearer your_token_here。

4. 授权（Authorization）Postman提供了更专门的“Authorization”标签页来简化认证流程。对于上述的Bearer Token，你可以直接在Type下拉框选择“Bearer Token”，然后在Token字段粘贴你的token，Postman会自动帮你生成正确的Header。它还支持Basic Auth、OAuth 1.0/2.0等多种认证方式。

5. 复杂请求体（Body）除了JSON，Body还支持：

  • form-data：常用于文件上传。格式类似HTML表单，可以添加文本字段和文件字段。
  • x-www-form-urlencoded：标准的表单编码格式，参数以key=value形式编码，和查询参数类似，但放在请求体内。
  • binary：发送二进制文件（如图片、PDF），选择文件即可。
  • GraphQL：用于发送GraphQL查询。

注意事项：Content-Type必须与Body的实际格式严格匹配。如果Body是JSON但Content-Type是text/plain，服务器很可能无法正确解析，返回400错误。Postman在切换Body格式时通常会同步更新Content-Type，但如果你手动修改了Header，需要确保一致性。

3.3 环境变量与集合：提升效率的利器

当你在开发、测试、生产等多个环境切换时，每次改URL前缀（如https://dev-api.example.com到https://api.example.com）非常麻烦。Postman的环境变量（Environments）就是为此而生。

创建和使用环境变量：

  1. 点击右上角眼睛图标旁边的下拉框，选择“Manage Environments”。
  2. 点击“Add”，创建一个新环境，命名为“Dev”。
  3. 在下方表格中添加变量，例如：base_url，初始值填写https://dev-api.example.com。还可以添加api_token等。
  4. 保存后，在右上角选择刚创建的“Dev”环境。
  5. 回到请求标签页，在URL中就可以使用双花括号引用变量了：{{base_url}}/v1/auth/login。发送请求时，{{base_url}}会被自动替换为https://dev-api.example.com。

集合（Collections）则是管理一组相关请求的文件夹。你可以把登录、获取用户信息、修改资料等属于用户模块的接口都放在一个叫“User Module”的集合里。集合支持批量运行、导出分享，并且可以在集合级别设置公共的请求头、前置脚本和测试脚本，非常利于团队协作和自动化。

一个进阶技巧：在Tests脚本中设置环境变量。登录接口的响应中包含了token，后续接口都需要这个token。我们可以写一个测试脚本，自动提取token并保存到环境变量。 在登录请求的“Tests”标签页，输入以下JavaScript代码：

// 检查响应状态码是否为200 pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); // 解析JSON响应 var jsonData = pm.response.json(); // 检查响应结构是否正确 pm.test("Login successful", function () { pm.expect(jsonData.code).to.eql(0); pm.expect(jsonData.data.token).to.be.a('string'); }); // 将返回的token设置到环境变量中 pm.environment.set("auth_token", jsonData.data.token);

发送登录请求后，如果成功，脚本会自动将token存入当前环境的auth_token变量。在其他需要认证的请求中，就可以在Authorization标签页直接使用{{auth_token}}了。这实现了接口间的数据传递，是自动化测试的基础。

4. 实战第二步：用Fiddler捕获与分析网络流量

当Postman请求出错，或者你想看看前端到底发了什么时，就该Fiddler上场了。

4.1 Fiddler基础配置与抓包准备

下载安装Fiddler Classic后打开。首次运行，它可能会提示安装证书以解密HTTPS流量，务必点击“Yes”安装，否则你只能看到一堆乱码的HTTPS请求。

确保抓包开启：看Fiddler左下角，有一个“Capturing”的按钮。如果显示“Capturing”且按钮是凹陷状态，说明正在捕获流量。如果显示空白，点击它开启捕获。

捕获目标设定：默认情况下，Fiddler会捕获所有系统的HTTP/HTTPS流量，包括浏览器、其他软件等，信息会很杂。为了专注，我们可以：

  1. 点击菜单栏的File -> Capture Traffic可以快速开关捕获。
  2. 点击右下角的All Processes，可以只显示特定进程的流量（如你的浏览器或Postman）。
  3. 在Filters标签页可以设置各种过滤规则，比如只显示主机包含“example.com”的请求。

现在，打开你的浏览器访问一个网页，或者回到Postman发送一个请求，你会在Fiddler主窗口的会话列表（Web Sessions）中看到一条条记录。

4.2 解读Fiddler会话详情：请求与响应的解剖

双击任意一条会话，右侧会显示详情，主要关注两个标签页：“Inspectors”和“AutoResponder”。

Inspectors标签页：这是分析请求和响应的核心区域。它分为上下两部分，上半部分是请求（Request），下半部分是响应（Response）。每一部分又有很多视图：

  • Headers：显示所有的请求头或响应头。这是排查问题最常用的视图。你可以在这里清晰地看到Content-Type、Cookie、Authorization、User-Agent等关键信息。
  • TextView / SyntaxView：以文本或语法高亮形式查看请求体或响应体。对于JSON、XML响应，SyntaxView非常友好。
  • WebForms：如果请求是表单格式，这里会以键值对形式解析出来。
  • Auth、Cookies、Raw：分别查看认证信息、Cookies和原始的HTTP报文。

一个典型的问题排查场景：你在Postman调用一个接口返回400错误。在Fiddler中抓到该请求后，查看Request的Headers，发现Content-Type是application/json，再看TextView中的请求体，发现你的JSON格式有误，比如最后一个属性后面多了一个逗号。服务器因为无法解析这个无效的JSON，所以返回了400。这个错误在Postman的界面里可能不那么直观，但在Fiddler的Raw视图里，你能看到原始的、未经任何美化的HTTP报文，问题一目了然。

4.3 高阶功能：断点、重发与模拟

1. 断点（Breakpoints）Fiddler允许你在请求发送前或响应返回前设置断点，拦截并修改数据。

  • 请求前断点：在Fiddler菜单栏选择Rules -> Automatic Breakpoints -> Before Requests。之后，所有发出的请求都会被暂停在Fiddler。你可以在Inspectors中修改请求的任何部分（URL、Header、Body），然后点击“Run to Completion”放行。这常用于测试服务器对异常参数的处理。
  • 响应后断点：选择Rules -> Automatic Breakpoints -> After Responses。服务器返回的响应会被暂停，你可以修改响应状态码、响应体，再返回给客户端。这常用于模拟服务器错误或返回特定数据，测试客户端的容错性。

警告：设置全局断点后，所有网络请求都会被拦截，可能导致浏览器或其他应用卡住。调试完成后，务必通过Rules -> Automatic Breakpoints -> Disabled来禁用断点。

2. 重发与修改（Replay & Composer）在会话列表右键点击一个请求，选择“Replay -> Reissue Requests”可以重发一次相同的请求。选择“Replay -> Reissue and Edit...”则可以在重发前编辑请求。 更强大的是“Composer”标签页。你可以把抓到的请求直接拖到Composer中，它会自动填充所有信息。然后你可以任意修改方法、URL、Headers、Body，再点击Execute发送。这相当于一个内置的、基于真实请求的Postman，非常适合做接口的探索性测试。

3. 自动响应器（AutoResponder）这是模拟后端接口行为的“大杀器”。你可以设定规则，当匹配到某个请求时，不转发到真实服务器，而是直接返回一个本地文件或手动编辑的响应。操作步骤：

  1. 抓取到你想要模拟的请求，比如GET https://api.example.com/v1/user/1。
  2. 在AutoResponder标签页，勾选“Enable rules”和“Unmatched requests passthrough”（让不匹配的请求正常通过）。
  3. 将左侧会话列表中的这个请求拖到右侧的规则列表中。
  4. 在规则条目的最右侧，点击“Rule Editor”，选择“Find a file...”选择一个本地的JSON文件作为模拟响应，或者选择“*200_Plain.txt”并编辑响应内容。
  5. 保存后，规则生效。以后任何应用（浏览器、Postman、手机App）发起这个请求，都会收到你预设的响应。

应用场景：

  • 前端开发联调：后端接口还没开发好，前端可以用Fiddler拦截接口，返回Mock数据，实现并行开发。
  • 异常测试：模拟服务器返回500、404、超时等异常情况，测试客户端的错误处理和用户体验。
  • 数据替换：将接口返回的某些敏感数据或大量数据替换为更小、更安全的测试数据。

5. 实战第三步：双工具联调，定位并解决一个真实问题

让我们模拟一个真实场景，并用Postman和Fiddler联手解决它。

问题描述：前端同学反馈，在提交一个表单（POST到/api/submit）时，偶尔会收到服务器返回的“400 Bad Request: Invalid JSON format”错误，但并非每次都会出现。前端坚称发送的数据格式正确。

我们的调试目标：复现问题，定位是前端数据问题，还是网络传输问题，或是服务器解析问题。

5.1 第一步：用Postman尝试复现

首先，我们向前端同学要来了接口文档和一份他们声称“正确”的请求示例。

  • URL:https://test-api.example.com/api/submit
  • Method: POST
  • Headers:Content-Type: application/json
  • Body:
{ "orderId": "ORD-20231027-001", "items": [ {"id": 1, "quantity": 2}, {"id": 3, "quantity": 1} ], "remark": "请尽快发货" }

我们在Postman中照此配置，发送请求。结果返回200成功。这说明接口本身和这个示例数据是没问题的。问题在于“偶尔”出现，且前端发送的数据可能和示例有细微差别。

5.2 第二步：用Fiddler捕获前端真实请求

我们请前端同学在出问题的页面上操作一次，同时我们打开Fiddler并确保正在捕获流量（注意过滤掉其他无关请求）。让前端触发一次提交。

在Fiddler的会话列表中，我们寻找主机为test-api.example.com、路径为/api/submit的POST请求。找到后，双击打开详细检查。

关键检查点：

  1. Request Headers：确认Content-Type确实是application/json; charset=UTF-8。有时前端框架可能会偷偷加上charset，这通常是没问题的。

  2. Request Body：切换到TextView或SyntaxView，仔细查看JSON内容。我们需要像校对文稿一样，逐字逐句对比。很快，我们可能就会发现一个可疑点：

    { "orderId": "ORD-20231027-001", "items": [ {"id": 1, "quantity": 2}， {"id": 3, "quantity": 1} ], "remark": "请尽快发货" }

    注意看items数组的第一个元素末尾，逗号是中文全角逗号“，”，而第二个元素末尾是英文半角逗号“,”！JSON标准只允许使用英文半角符号。当这个JSON字符串被生成时，如果混合了全角符号，在某些严格的JSON解析器下就会报格式错误。

    但为什么是“偶尔”出错呢？这可能和前端数据拼接的逻辑有关。也许“remark”字段是从用户输入框获取的，当用户输入了特定内容或从某些地方复制粘贴时，可能引入了全角字符。而在某些情况下，前端代码可能做了额外的字符过滤或清理，所以有时又能成功。

5.3 第三步：在Postman中模拟和验证

现在我们在Postman中复现这个错误。将Body修改为捕获到的有问题的JSON（带全角逗号），发送请求。果然，服务器返回了400错误，提示JSON格式无效。这证实了我们的猜想。

为了进一步验证是逗号问题，我们可以做一个对照实验：

  • 实验A：使用纯英文半角符号的JSON，发送，预期成功。
  • 实验B：将任意一个逗号替换为中文全角逗号，发送，预期失败。

结果与预期一致。

5.4 第四步：解决方案与回归测试

定位到问题根源是前端JSON序列化时混入了全角标点。解决方案是：在前端代码中，在将JavaScript对象转换为JSON字符串发送前，对字符串进行过滤，确保所有JSON相关的符号（引号、逗号、冒号、括号）都是半角的。或者，使用更健壮的JSON库，避免手动拼接字符串。

作为测试或后端，我们可以做什么？我们可以用Postman建立一个“负面测试用例”。

  1. 在Postman中，将那个包含全角逗号的错误请求保存下来。
  2. 在“Tests”标签页，编写一个断言，专门检查当发送非法JSON时，服务器是否返回了预期的400状态码和明确的错误信息（而不是500内部错误）。
    pm.test("Invalid JSON should return 400", function () { pm.response.to.have.status(400); pm.response.to.have.jsonBody('error', 'Invalid JSON format'); });
  3. 将这个请求放入你的接口测试集合中。这样，每次回归测试，都会验证服务器对错误格式的容错性是否符合预期。

同时，我们也可以用Fiddler的AutoResponder做一个快速演示给前端看：创建一个规则，拦截/api/submit请求，返回一个写有“发现全角逗号！”的400响应，让前端同学直观地看到问题。

6. 常见问题排查与操作技巧实录

在实际使用中，你会遇到各种各样的小问题。这里我整理了一份“踩坑记录”，希望能帮你少走弯路。

6.1 Postman常见问题

1. 发送请求后一直处于“Sending...”状态，无响应。

  • 可能原因：网络代理问题、服务器未启动或地址错误、Postman本身故障。
  • 排查步骤：
    1. 首先检查URL是否正确，特别是localhost和端口号。
    2. 打开Fiddler，看请求是否成功发出。如果Fiddler里都看不到请求，问题可能在Postman或网络配置。
    3. 检查Postman的设置（Settings -> Proxy），确认是否配置了错误的代理。可以尝试关闭代理。
    4. 尝试用一个绝对可靠的公共API测试，如GET https://jsonplaceholder.typicode.com/posts/1。如果这个能通，说明问题在你的目标服务器或网络环境。

2. 返回状态码401（未授权）/403（禁止访问）。

  • 可能原因：缺少或错误的身份认证信息（Token/API Key）。
  • 排查步骤：
    1. 检查请求的“Authorization”标签页或“Headers”里是否有正确的认证头。
    2. Token可能已过期，尝试重新获取。
    3. 有些接口需要将Token放在查询参数或Cookie中，仔细阅读接口文档。
    4. 使用Fiddler抓包，对比一个成功请求和失败请求的Headers差异，重点看Authorization、Cookie等字段。

3. 返回状态码400（错误请求）。

  • 可能原因：请求参数错误，这是最常见的问题。
  • 排查步骤：
    1. 首要工具：Fiddler。抓包查看原始请求，确认请求体格式（JSON/Form-data）和Content-Type头是否匹配。
    2. 检查JSON格式：括号是否配对，逗号是否正确（末尾不能有逗号），字符串引号是否为英文双引号。
    3. 检查参数名是否拼写错误，是否符合接口文档要求（大小写敏感）。
    4. 检查参数类型：接口要求传数字123，你传了字符串"123"也可能导致错误。

4. 环境变量不生效。

  • 可能原因：未正确选择环境、变量名拼写错误、变量作用域问题。
  • 排查步骤：
    1. 确认右上角下拉框选中的是你定义变量的环境。
    2. 在请求的URL或参数中使用变量时，格式为{{variable_name}}，注意是双花括号。
    3. 点击Postman右上角的眼睛图标，查看“Current Value”是否已赋值。如果没有，可能需要通过脚本（如登录后的Tests脚本）来动态设置。
    4. 变量有作用域：全局变量（Globals）、环境变量（Environment）、集合变量（Collection Variables）、局部变量（Local）。局部变量优先级最高。检查是否有同名变量覆盖。

6.2 Fiddler常见问题

1. Fiddler抓不到HTTPS流量，显示“Tunnel to...”。

  • 可能原因：HTTPS解密未正确配置，或应用程序不走系统代理。
  • 排查步骤：
    1. 确保已安装Fiddler根证书。打开Fiddler，进入Tools -> Options -> HTTPS，勾选“Decrypt HTTPS traffic”，如果证书未安装，会提示你安装，务必信任该证书。
    2. 有些应用（如Chrome新版、某些移动App）可能默认不使用系统代理。对于浏览器，可以安装SwitchyOmega等插件强制走代理。对于其他应用，可能需要在其设置中手动配置代理为127.0.0.1:8888（Fiddler默认监听端口）。
    3. 检查Fiddler左下角是否正在“Capturing”。

2. 手机无法连接Fiddler代理。

  • 前提：手机和电脑需要在同一局域网（连接同一个Wi-Fi）。
  • 步骤：
    1. 在Fiddler中，进入Tools -> Options -> Connections，记住“Fiddler listens on port”的端口号（默认8888），并勾选“Allow remote computers to connect”。
    2. 在电脑上按Win+R，输入cmd打开命令行，输入ipconfig，找到无线局域网适配器的IPv4地址（如192.168.1.100）。
    3. 在手机Wi-Fi设置中，找到当前连接的Wi-Fi，修改代理为“手动”，主机名填写电脑的IP地址（192.168.1.100），端口填写Fiddler的端口（8888）。
    4. 在手机浏览器中访问http://电脑IP:端口，例如http://192.168.1.100:8888，下载并安装Fiddler根证书（通常是一个FiddlerRoot.cer文件）。
    5. 在手机系统设置中信任该证书（iOS需要在“通用-关于本机-证书信任设置”中完全信任；Android在“安全-加密与凭据-安装证书”中安装）。
    6. 现在手机上的App流量就能被Fiddler捕获了。

3. 抓包数据太多，如何过滤？

  • 使用Filters：在Fiddler右侧的“Filters”标签页，勾选“Use Filters”。
    • 在“Hosts”区域，可以指定只显示（或隐藏）特定域名的流量。例如，在“No Zone Filter”下拉选“Show only the following Hosts”，然后在下方输入example.com;api.example.com。
    • 还可以根据请求方法、状态码、响应类型等进行过滤。
  • 关注进程：点击右下角的“All Processes”，可以只显示特定浏览器或程序的流量。

6.3 联调进阶技巧

1. 对比请求差异当某个功能在A环境正常，在B环境异常时，可以分别在两个环境下用Fiddler抓取同一个操作的请求。然后将两个请求的Raw数据复制到文本对比工具（如Beyond Compare, VS Code）中，逐行比对，差异点往往就是问题所在。

2. 性能瓶颈分析在Fiddler的会话列表中，每个请求都有时间线。点击菜单栏的Statistics标签页，可以看到所有请求的耗时统计。更直观的是，点击Timeline标签页，会以瀑布流形式展示请求的起止时间、阻塞、DNS查询、TCP连接、SSL握手、发送请求、等待响应、接收响应等各个阶段的耗时。哪个请求拖慢了整个页面，一目了然。

3. 编写自定义脚本Fiddler支持使用JScript.NET编写自定义脚本（Rules -> Customize Rules...），实现更复杂的自动化功能。例如，可以写一个脚本，自动将所有请求中的某个特定Header值替换掉，或者将响应中的敏感信息（如手机号、身份证号）打码后再显示，保护测试数据隐私。

从对接口测试“抓瞎”到利用Postman和Fiddler做到“门清”，关键在于建立起一套主动构造与被动监听相结合的系统性方法。Postman让你能精准地“问”，Fiddler让你能清晰地“听”和“看”。这套组合拳不仅能解决日常开发调试中99%的接口问题，更能深化你对HTTP协议、前后端交互的理解。工具是死的，思维是活的。下次再遇到接口问题时，别慌，先打开Postman构造一个最小化请求验证基础路径，再打开Fiddler看看网络层面到底发生了什么。多实践几次，你就能形成自己的调试直觉，效率自然会大幅提升。

编程学习 技术分享 实战经验

相关新闻

多维聚合实战：Slice、Dice、Pivot与Drill-down动态数据折叠术

2026/7/4 12:32:03

JMeter性能测试实战：从脚本开发到结果分析完整指南

2026/7/4 12:31:57

如何快速配置Windows安全防护：终极管理工具使用指南

2026/7/4 12:31:37

最新新闻

如何3步成为MapleStory游戏资源编辑专家：终极工具使用教程

2026/7/4 13:28:25

国产大模型双雄对决：混元3.0与DeepSeek V4的技术范式分野

2026/7/4 13:28:03

异常检测面试心法：从点/上下文/集合异常到工程落地四重校验

2026/7/4 13:28:03

机器学习工程师必读的12个硬核技术博客推荐

2026/7/4 13:27:44

Ohook：开源社区如何重新定义Office功能增强方案

2026/7/4 13:27:44

YOLO26一键分析工具：模型性能指标自动化评估

2026/7/4 13:27:44

日新闻

STM32F745VG与MC6470 IMU的高性能姿态控制系统设计

2026/7/4 0:01:52

Docker容器安全加固：从零构建定制化Seccomp白名单策略

2026/7/4 0:02:07

机器不消费，人何以生存

2026/7/4 0:02:07

周新闻

Figma中文界面插件终极指南：5分钟快速上手完整教程

2026/7/4 8:14:21

Windows字体自定义终极方案：No!! MeiryoUI完全指南

2026/7/4 8:14:21

WinBtrfs终极实战指南：3种配置方案解锁Windows Btrfs文件系统完整功能

2026/7/3 21:20:39

月新闻

[C++]内存管理：串顺序存储的内存回收

2026/7/4 8:14:52

足球口袋教练 HarmonyOS 离线应用实战（03/20）：ArkUI 首页仪表盘搭建

2026/7/3 18:00:20

抖音内容监控助手：告别手动刷新，让优质内容主动找你

2026/7/4 8:14:44