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工作流包括新建请求选择方法GET, POST, PUT, DELETE等输入URL。配置请求在Params、Authorization、Headers、Body等标签页下填写查询参数、认证信息、请求头和请求体如JSON, Form-data。发送与查看点击Send在下方面板查看状态码、响应时间、响应头和响应体。测试与自动化在“Tests”标签页用JavaScript编写断言验证响应状态码是否为200响应体是否包含某个字段或值。保存与管理将请求保存到某个集合中方便下次直接调用或与团队共享。注意很多新手会忽略“Pre-request Script”和“Tests”这两个标签页。前者可以在发送请求前执行脚本如生成时间戳、计算签名后者用于请求后验证。这是Postman从“工具”进阶到“平台”的关键。2.2 Fiddler网络流量的“显微镜”与“手术刀”如果说Postman是你在明处打出的“拳”那么Fiddler就是在暗处观察“拳路”和“对手反应”的摄像机。它是一个代理服务器工作时会将自己设置为系统或应用程序的代理。所有流经它的网络请求和响应都会被记录下来。Fiddler能帮你解决哪些Postman单独搞不定的问题查看“真实”的请求你可能会疑惑我在Postman里明明设置了这些参数为什么后端说没收到用Fiddler抓一下从Postman发出的包你就能看到经过网络层后请求体、请求头的最终形态确认是否有编码错误、多余空格或格式问题。调试前端问题当网页或App出现接口错误时你无法直接修改其请求代码。用Fiddler抓取前端发出的请求分析其参数、Cookie、Token是否正确甚至可以直接修改请求或响应进行调试断点功能。模拟弱网与异常Fiddler可以模拟低速网络2G/3G、高延迟和丢包测试应用在网络不佳情况下的表现。还可以设置自动响应AutoResponder用本地文件或自定义数据替换服务器响应模拟服务器返回错误码、超时等异常场景。分析性能瓶颈通过时间线视图可以清晰地看到一个页面加载过程中各个请求的发起顺序、阻塞情况、耗时长短精准定位性能瓶颈。Fiddler Classic vs Fiddler Everywhere目前Fiddler主要有两个版本。Classic是传统的Windows桌面应用免费、功能强大但界面相对老旧。Everywhere是跨平台Win/Mac/Linux的新版本采用订阅制界面更现代但部分高级功能需要付费。对于初学者和大多数日常抓包需求Fiddler Classic完全够用。本文演示也以Fiddler Classic为主。2.3 双剑合璧Postman Fiddler 协同工作流理解了各自的特长就能设计出高效的协同流程。一个完整的调试过程通常是这样的初步验证Postman拿到接口文档后首先在Postman中构造请求尝试能否成功调用。这一步是基础功能验证。问题复现与抓包Fiddler如果接口调用失败或者返回结果不符合预期打开Fiddler确保其正在捕获流量左下角“Capturing”为开启状态。然后在Postman中重新发送一次问题请求。流量分析Fiddler在Fiddler的会话列表中找到刚才Postman发出的请求查看其详细内容。对比你在Postman中设置的和实际发出的是否一致重点检查URL、Headers尤其是Content-Type、Authorization、请求体。修改与重试Postman根据Fiddler的分析结果回到Postman调整请求参数再次发送。同时可以在Fiddler中清除旧会话观察新的请求流量。模拟与调试Fiddler对于某些难以在开发环境复现的问题如特定的服务器错误响应可以使用Fiddler的AutoResponder功能拦截指定请求并返回一个你预设的错误响应然后在Postman或前端观察应用的处理逻辑是否正确。自动化与回归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”暂时跳过。主界面主要分为左侧的导航栏侧边栏和右侧的工作区。创建你的第一个请求点击左上角的“New”按钮选择“HTTP Request”。这会创建一个新的请求标签页。在请求方法下拉框中选择“POST”。在地址栏输入完整的URLhttps://api.example.com/v1/auth/login。切换到“Body”标签页。选择“raw”并在右侧格式下拉框中选择“JSON”。在下方的编辑区输入我们的JSON请求体{ username: testuser, password: 123456 }点击巨大的蓝色“Send”按钮。发送后下方会弹出响应面板。你会看到状态码如200 OK、响应时间、以及响应体。如果接口正常响应体里应该能看到返回的token。实操心得在输入URL时注意http和https的区别。现在绝大多数API都使用https。如果遇到SSL证书错误可以在Postman的设置Settings中暂时关闭“SSL certificate verification”但这仅用于测试环境生产环境切勿关闭。3.2 玩转请求参数与认证实际接口远比登录复杂。我们来看看Postman如何处理各种常见参数。1. 查询参数Query Params对于GET请求参数通常以?key1value1key2value2的形式附在URL后面。在Postman中你不需要手动拼接。只需切换到“Params”标签页以键值对的形式输入即可Postman会自动帮你拼接到URL里。例如测试一个获取用户列表的接口GET https://api.example.com/v1/users需要分页参数page1size10。在Params页添加两行Postman会自动生成URL为https://api.example.com/v1/users?page1size10。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认证你需要手动添加一个HeaderKey为AuthorizationValue为Bearer your_token_here。4. 授权AuthorizationPostman提供了更专门的“Authorization”标签页来简化认证流程。对于上述的Bearer Token你可以直接在Type下拉框选择“Bearer Token”然后在Token字段粘贴你的tokenPostman会自动帮你生成正确的Header。它还支持Basic Auth、OAuth 1.0/2.0等多种认证方式。5. 复杂请求体Body除了JSONBody还支持form-data常用于文件上传。格式类似HTML表单可以添加文本字段和文件字段。x-www-form-urlencoded标准的表单编码格式参数以keyvalue形式编码和查询参数类似但放在请求体内。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就是为此而生。创建和使用环境变量点击右上角眼睛图标旁边的下拉框选择“Manage Environments”。点击“Add”创建一个新环境命名为“Dev”。在下方表格中添加变量例如base_url初始值填写https://dev-api.example.com。还可以添加api_token等。保存后在右上角选择刚创建的“Dev”环境。回到请求标签页在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流量包括浏览器、其他软件等信息会很杂。为了专注我们可以点击菜单栏的File - Capture Traffic可以快速开关捕获。点击右下角的All Processes可以只显示特定进程的流量如你的浏览器或Postman。在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. 断点BreakpointsFiddler允许你在请求发送前或响应返回前设置断点拦截并修改数据。请求前断点在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这是模拟后端接口行为的“大杀器”。你可以设定规则当匹配到某个请求时不转发到真实服务器而是直接返回一个本地文件或手动编辑的响应。操作步骤抓取到你想要模拟的请求比如GET https://api.example.com/v1/user/1。在AutoResponder标签页勾选“Enable rules”和“Unmatched requests passthrough”让不匹配的请求正常通过。将左侧会话列表中的这个请求拖到右侧的规则列表中。在规则条目的最右侧点击“Rule Editor”选择“Find a file...”选择一个本地的JSON文件作为模拟响应或者选择“*200_Plain.txt”并编辑响应内容。保存后规则生效。以后任何应用浏览器、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/submitMethod: POSTHeaders:Content-Type: application/jsonBody:{ 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请求。找到后双击打开详细检查。关键检查点Request Headers确认Content-Type确实是application/json; charsetUTF-8。有时前端框架可能会偷偷加上charset这通常是没问题的。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建立一个“负面测试用例”。在Postman中将那个包含全角逗号的错误请求保存下来。在“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); });将这个请求放入你的接口测试集合中。这样每次回归测试都会验证服务器对错误格式的容错性是否符合预期。同时我们也可以用Fiddler的AutoResponder做一个快速演示给前端看创建一个规则拦截/api/submit请求返回一个写有“发现全角逗号”的400响应让前端同学直观地看到问题。6. 常见问题排查与操作技巧实录在实际使用中你会遇到各种各样的小问题。这里我整理了一份“踩坑记录”希望能帮你少走弯路。6.1 Postman常见问题1. 发送请求后一直处于“Sending...”状态无响应。可能原因网络代理问题、服务器未启动或地址错误、Postman本身故障。排查步骤首先检查URL是否正确特别是localhost和端口号。打开Fiddler看请求是否成功发出。如果Fiddler里都看不到请求问题可能在Postman或网络配置。检查Postman的设置Settings - Proxy确认是否配置了错误的代理。可以尝试关闭代理。尝试用一个绝对可靠的公共API测试如GET https://jsonplaceholder.typicode.com/posts/1。如果这个能通说明问题在你的目标服务器或网络环境。2. 返回状态码401未授权/403禁止访问。可能原因缺少或错误的身份认证信息Token/API Key。排查步骤检查请求的“Authorization”标签页或“Headers”里是否有正确的认证头。Token可能已过期尝试重新获取。有些接口需要将Token放在查询参数或Cookie中仔细阅读接口文档。使用Fiddler抓包对比一个成功请求和失败请求的Headers差异重点看Authorization、Cookie等字段。3. 返回状态码400错误请求。可能原因请求参数错误这是最常见的问题。排查步骤首要工具Fiddler。抓包查看原始请求确认请求体格式JSON/Form-data和Content-Type头是否匹配。检查JSON格式括号是否配对逗号是否正确末尾不能有逗号字符串引号是否为英文双引号。检查参数名是否拼写错误是否符合接口文档要求大小写敏感。检查参数类型接口要求传数字123你传了字符串123也可能导致错误。4. 环境变量不生效。可能原因未正确选择环境、变量名拼写错误、变量作用域问题。排查步骤确认右上角下拉框选中的是你定义变量的环境。在请求的URL或参数中使用变量时格式为{{variable_name}}注意是双花括号。点击Postman右上角的眼睛图标查看“Current Value”是否已赋值。如果没有可能需要通过脚本如登录后的Tests脚本来动态设置。变量有作用域全局变量Globals、环境变量Environment、集合变量Collection Variables、局部变量Local。局部变量优先级最高。检查是否有同名变量覆盖。6.2 Fiddler常见问题1. Fiddler抓不到HTTPS流量显示“Tunnel to...”。可能原因HTTPS解密未正确配置或应用程序不走系统代理。排查步骤确保已安装Fiddler根证书。打开Fiddler进入Tools - Options - HTTPS勾选“Decrypt HTTPS traffic”如果证书未安装会提示你安装务必信任该证书。有些应用如Chrome新版、某些移动App可能默认不使用系统代理。对于浏览器可以安装SwitchyOmega等插件强制走代理。对于其他应用可能需要在其设置中手动配置代理为127.0.0.1:8888Fiddler默认监听端口。检查Fiddler左下角是否正在“Capturing”。2. 手机无法连接Fiddler代理。前提手机和电脑需要在同一局域网连接同一个Wi-Fi。步骤在Fiddler中进入Tools - Options - Connections记住“Fiddler listens on port”的端口号默认8888并勾选“Allow remote computers to connect”。在电脑上按WinR输入cmd打开命令行输入ipconfig找到无线局域网适配器的IPv4地址如192.168.1.100。在手机Wi-Fi设置中找到当前连接的Wi-Fi修改代理为“手动”主机名填写电脑的IP地址192.168.1.100端口填写Fiddler的端口8888。在手机浏览器中访问http://电脑IP:端口例如http://192.168.1.100:8888下载并安装Fiddler根证书通常是一个FiddlerRoot.cer文件。在手机系统设置中信任该证书iOS需要在“通用-关于本机-证书信任设置”中完全信任Android在“安全-加密与凭据-安装证书”中安装。现在手机上的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看看网络层面到底发生了什么。多实践几次你就能形成自己的调试直觉效率自然会大幅提升。