后端接口还没写完前端页面已经排期在前联调日期倒逼着进度依赖的三方接口不稳定常常调着调着就 500演示环境需要固定数据却不想在代码里写死一大堆 if else。这种时候Postman 的模拟服务Mock Server就是那个能立刻顶上来的临时后端。我最早接触 Postman Mock Server 是在一次前后端并行开发中后端还在搭数据库表结构前端已经需要调接口。总不能干等着也不能在代码里写一堆硬编码返回值。后来我发现用 Postman 基于请求的 Example 直接生成一个真实的 HTTPS 接口地址前端把 baseURL 换成这个模拟地址接口格式、异常分支、边界情况全部能提前跑通。而且它不需要写后端代码不需要搭服务器也不需要忍受抓包工具只能在本地生效的限制。本文不是给你念官方文档而是把我实际操作中的完整步骤、动态返回技巧、鉴权模拟、以及那几个容易被忽略的坑都梳理出来。1. 什么时候需要“造一个假后端”Mock 服务解决的痛点与选型1.1 你不是在偷懒而是在给联调解耦很多团队对 Mock 有偏见觉得“等后端写完再联调不就行了”。但实际开发中接口文档先行的项目越来越多。前端拿到的往往是一份接口说明里面定义了 URL、请求参数、响应结构。这时候如果你能先把响应数据写清楚、返回出来等于把“接口契约”落到了实处。我之前接手过一个数据大屏项目设计稿定完前端要展示折线图、地图、表格。后端接口当时只定义好了格式数据还在清洗。我用 Postman Mock Server 把折线图的 series、地图的 geoJson 字段、表格的分页结构全部按文档要求 mock 出来前端直接对着假数据开发。等后端联调时前端唯一要改的就是环境变量里的 baseURL从 Mock 域名切回真实域名其他代码基本不用动。Mock 服务真正解决的是“上下游开发节奏不一致”的问题。它把接口依赖从“阻塞式等待”变成了“并行开发”同时因为响应数据结构是前端自己定义的数据格式的问题在联调前就暴露得七七八八了。1.2 和 Fiddler 抓包重写、手写假数据接口的对比有人会问Fiddler 也能改响应我在本地拦截一个请求把响应替换成假数据不就行了确实可以但有个前提流量必须经过 Fiddler 的代理。如果你的代码跑在远端服务器、或者同事想访问你的 Mock 环境Fiddler 这套本地代理方案就行不通了。手写一个临时后端比如 Node Express、Spring Boot也能解决问题但维护成本不低。为了一个联调用例你可能要写路由、写控制器、手写一堆假数据生成逻辑这个过程本身也是代码也需要 review、调试、处理跨域实际上把简单问题复杂化了。Postman Mock Server 的优势在于它“开箱即用”。你在 Postman 里定义好请求和响应示例它就能生成一个可以直接访问的 HTTPS 地址带宽、并发、访问日志都不需要你操心。它和 Fiddler 的关系更像是互补场景推荐方案原因自己本机调试需要篡改真实接口返回Fiddler 或 Charles 响应重写需要真实请求经过代理才能看到篡改后的效果前端联调、团队共享一套假接口Postman Mock Server有独立 URL团队成员可直接访问不依赖本地代理没有后端、从零生成一套接口供开发使用Postman Mock Server / json-server数据结构可控改完立即生效需要非常复杂的自定义逻辑手写 Mock 服务模板语法有上限复杂逻辑还得上代码从我的实践看联调阶段优先考虑 Postman Mock Server它覆盖了至少 80% 的假数据需求。2. 十分钟跑通第一个 Postman Mock Server2.1 环境准备与版本差异Postman 现在的版本迭代比较快我写这篇的时候主流是 v10.x。Mock Server 功能在 v7 时代就有了所以如果你的版本不算太老基本都能用。有一点要注意Mock Server 是云端服务必须在 Postman 登录状态下使用免费账号就可以创建但每月模拟请求次数有限制之前是 1000 次/月量级后来调整过专业版和企业版额度更高。开发联调场景足够了但别拿它当生产接口。如果你的 Postman 还停留在非常老的版本建议直接去官网下载最新的。版本太旧可能功能入口不一样后面我写的操作路径会以 v10.x 为例。2.2 基于 Collection 创建 Mock Server 的两种路径Postman 的 Mock Server 并不是一个单独接口它本质上是从 Collection 里的请求和 Example示例响应生成映射关系。所以第一步不是创建 Mock Server而是先准备好 Collection 里的请求和 Example。第一种路径先建好 Collection再创建 Mock Server。我先新建一个 Collection比如叫demo-api。在 Collection 里添加一个请求比如GET /api/users这个请求的 URL 写什么都可以因为 Mock Server 会把 Mock 域名映射到 Collection 里的路径上。比如 Collection 里请求是http://localhost/api/users那么 Mock Server 生成了https://xxxx.mock.pstmn.io最终访问地址就是https://xxxx.mock.pstmn.io/api/users。然后我在这个请求的右键菜单里选择Add Example也就是添加一个示例响应。这个 Example 就是 Mock Server 要返回的数据。举个例子响应体写成{ code: 0, message: success, data: [ { id: 1, name: 张三, email: zhangsanexample.com }, { id: 2, name: 李四, email: lisiexample.com } ] }状态码选择 200响应头可以加上Content-Type: application/json。第二种路径在 Mock Server 创建向导里选择已有 Collection。左侧导航栏找到Mock Servers点击Create Mock Server选择刚才建好的 Collection输入 Mock Server 名称点击创建。创建完成后Postman 会生成一个https://xxxx.mock.pstmn.io这样的域名同时通常会帮你自动设置好环境变量。我个人的建议是如果你只是想快速验证用第二种路径因为它创建时会引导你选择 Collection 和环境一步到位。但如果你已经有一批成熟的 API 请求直接用第一种路径先整理请求、添加 Example再建 Mock。2.3 用实际请求验证第一个模拟接口创建完 Mock Server 之后怎么验证直接在 Postman 里新建一个请求URL 填生成的 Mock 域名加上对应路径GET https://xxxx.mock.pstmn.io/api/users发送请求返回的就是刚才在 Example 里写的 JSON 数据。这里有个细节必须提一下Postman 创建 Mock Server 时会默认生成一个环境变量一般是mock_server_url并把 Mock 域名存进去。如果你希望请求路径保持通用建议在请求 URL 里直接写{{mock_server_url}}/api/users这样以后切到真实后端时只要改环境变量里的mock_server_url即可不需要逐个改请求。我第一次用的时候没注意这个细节把 Mock 域名硬编码写在请求里后来真实后端上线我一个个改 URL改得头大。用环境变量统一管理这是第一个实操教训。3. 解锁 Mock Server 的动态响应能力从固定 JSON 到智能返回3.1 用内置动态变量生成随机数据如果 Mock 接口永远返回同一批固定数据那和死数据没区别。实际开发中我们需要各种各样的假数据创建用户接口返回不同 id、列表接口返回不同条数的数据、金额字段要随机变化。Postman Mock Server 支持动态变量也就是 Postman 文档里说的 Dynamic Variables。在响应体中我可以这样写{ id: {{$guid}}, name: {{$randomUserName}}, email: {{$randomEmail}}, createdAt: {{$timestamp}}, amount: {{$randomInt}} }这样每次请求都会返回不同的 id、用户名、邮箱、时间戳和随机整数。我整理了几个常用变量足够应付大多数场景动态变量作用{{$guid}}生成随机的 UUID 字符串{{$timestamp}}当前时间戳格式是 RFC 3339{{$randomInt}}随机整数{{$randomUserName}}随机用户名{{$randomEmail}}随机邮箱地址{{$randomCity}}随机城市名{{$randomColor}}随机颜色{{$randomPrice}}随机价格小数用动态变量的好处是前端在开发列表页时每次刷新能看到不同数据能够验证页面在不同数据长度、不同字符情况下的表现。比如用户名里有特殊字符邮箱域名多样化前端解析才不会出 bug。3.2 读取请求参数并回显固定随机数据还不够有时候 Mock 响应需要根据请求参数返回对应内容。比如GET /api/users?userId123期望返回 userId 对应的用户信息。Postman Mock Server 支持在响应体中使用{{$request.*}}表达式读取当前请求的查询参数、请求头、路径等。举个我用过的例子一个订单查询接口{ code: 0, message: success, data: { orderId: {{$request.query.orderId}}, status: paid, payAmount: {{$randomPrice}}, userId: {{$request.headers.x-user-id}} } }请求时带上?orderId10086响应里就会把这个 orderId 原样返回。这个特性在做接口联调时非常有用前端传了不同的 orderId就能看到回显的 orderId 是否正确同时也验证了请求参数是否真的传出去了。除了查询参数还有几个常见的取值方式表达式含义{{$request.query.参数名}}读取 URL 查询参数{{$request.headers.请求头名}}读取请求头{{$request.path}}读取请求完整路径{{$request.body}}读取原始请求体我个人最常用的是查询参数和请求头。比如模拟登录接口需要根据请求头里的Authorization值返回不同用户身份这个在第四章展开说。3.3 利用 Handlebars 模板做条件判断Postman Mock Server 的响应体不仅支持动态变量还支持一部分 Handlebars 模板语法。也就是说你可以在 JSON 响应里写简单的if/else逻辑根据请求条件返回不同的结构。举个例子模拟一个 VIP 用户查询接口{ code: 0, data: { userId: {{$request.query.userId}}, vipLevel: {{#if $request.query.isVip}}gold{{else}}normal{{/if}}, rights: {{#if $request.query.isVip}}[essay,video,download]{{else}}[essay]{{/if}} } }注意这个模板语法能处理简单的条件分支但不要期望它能像后端语言那样做复杂循环和函数调用。我踩过的坑是想在响应体里写{{#each}}遍历一个对象数组结果 Mock Server 不支持这种复杂的自定义数据源只能返回静态模板。需要更复杂的逻辑时可以配合 Collection 里的 Pre-request Script 或测试脚本动态生成数据但 Mock Server 的模板对复杂循环确实支持有限。实际操作中简单条件分支和请求参数回显已经能覆盖大多数联调需求。如果你发现 Mock Server 满足不了那就可以考虑升级成手写 Node 服务了。4. 鉴权、延迟与自定义域名把 Mock 服务做得更接近生产环境4.1 模拟登录鉴权按请求头分流很多接口需要登录后才能访问Mock 服务也应该模拟这种鉴权逻辑。刚开始我只建了一个 Example不管请求带不带 token 都返回 200后来前端测试登录过期场景时发现根本没有 401 数据可测。Postman Mock Server 支持为同一个请求配置多个 Example并通过请求头匹配来决定返回哪一份响应。这个功能的关键在于一个特殊响应头x-mock-match-request-headers。具体操作是这样的第一步在GET /api/userinfo请求下创建两个 Example。第二个 Example也就是“正常登录”的返回状态码 200响应体是用户数据。在这个 Example 的响应头里加x-mock-match-request-headers: Authorization然后在第二个 Example 的请求头里设置Authorization: Bearer test-token-123意思是当请求头里的Authorization值恰好是Bearer test-token-123时Mock Server 返回这个 200 响应。再创建第一个 Example状态码 401响应体是{ code: 401, message: unauthorized }这个作为默认分支不设置匹配规则。这样当请求头没有带 token 或者 token 值不对时就会匹配到这个 Example 返回 401。实测一下curl -H Authorization: Bearer test-token-123 https://xxxx.mock.pstmn.io/api/userinfo # 返回 200 用户数据 curl https://xxxx.mock.pstmn.io/api/userinfo # 返回 401 unauthorized这个机制非常实用前端可以分别验证登录态和登录过期两个分支。但有一点要提前说明一个请求的多个 Example 实际上是为了匹配不同场景官方文档推荐的方式就是通过x-mock-match-request-headers和x-mock-match-request-body做精细匹配。我第一次用的时候总想着在响应体里写逻辑判断 token结果发现完全没有必要直接用不同 Example 做匹配分支既清晰又稳定。4.2 模拟网络延迟与错误码联调时另一个常见需求是模拟慢接口。前端要测 loading 动画如果 Mock 接口秒回loading 状态根本不会被看到。Postman Mock Server 没有直接在界面上放一个“延迟”按钮但可以通过响应头配置实现。在 Example 的响应头中加一行x-mock-response-delay: 3000单位是毫秒实测下来不少版本是支持这个响应头的。你设置 3000请求就会在大约 3 秒后才返回。这个用法在社区里经常被提到但官方文档不一定写得很明确所以要确认一下你所在版本是否生效。如果这个头在你的环境不生效还有一个替代方案把 Postman 的 Collection 里加上预请求脚本用pm.sendRequest包一层或者直接在前端代码里临时模拟。但说实话最省事的还是这个响应头。错误码的模拟就简单多了创建 Example 时状态码直接选择 500、502、504响应体写对应错误信息。比如{ code: 500, message: 系统繁忙请稍后重试 }之后前端测各种异常情况只需要在请求头里加不同的匹配规则或者临时把默认 Example 改成 500 再改回来。这里有个小技巧不要把正常 Example 删掉用x-mock-match-request-headers加一个mock-scene: error请求头来分流异常场景这样想复现 500 时就在请求头加上这个标记想恢复正常就去掉不需要反复改响应体。4.3 域名绑定和 URL 复用免费版的 Mock Server 域名是一长串随机字符不好记也不方便前端配置。Postman 的自定义域名功能可以解决这个问题正常情况下是付费功能团队版或企业版里可用。绑定后域名会变成类似https://api-mock.yourcompany.com这样看起来正规得多。如果你没有自定义域名权限我的建议是把 Mock 地址统一收敛到环境变量里前端只关注一个 baseURL。例如环境变量配置{ baseUrl: https://xxxx.mock.pstmn.io }所有集合请求都用{{baseUrl}}开头。这样即使将来 Mock 域名变了只需要改一行配置不用在几十个请求里逐个替换。也可以创建多个环境比如 dev-mock、test-mock不同环境对应不同 Mock Server 域名这样不同分支、不同阶段的测试数据可以隔离。域名的问题本质上不是好不好记而是你能否在一个地方管理好它。我见过太多人把 Mock 地址直接写死在各个请求里项目一多必然失控。5. 在自动化测试和联调流程中落地 Mock Server5.1 配合 Runner 做不等后端的接口冒烟Postman 的 Runner 功能通常被用来跑自动化测试但很多人不知道它也能和 Mock Server 配合使用。当后端还没开发完成时我可以把整个 Collection 的 baseURL 指向 Mock Server然后直接用 Runner 跑一遍所有请求快速验证请求路径是否都能匹配到对应的 Example响应数据是否符合预先定义的 JSON 结构每个接口的响应时间、状态码是否正常是否有请求漏掉了 Example出现 404。操作上很简单Runner 运行前选择环境变量为 Mock 环境Collection 请求里使用{{baseUrl}}作为主机名Runner 会统一替换。跑完后看结果列表凡是出现 404 的请求说明这个接口的 Example 没建或者路径不匹配。我有一个习惯每次新版本迭代后先把所有请求在 Mock 环境上跑一遍相当于接口“自检”。这样后端接口还没写好我就能判断前端依赖的接口契约是否有缺口。等真实后端上线时再跑一遍同一套 Runner 用例如果 Mock 和真实响应结构有差异测试结果会直接暴露出来。5.2 在团队里共享一套 Mock 环境Postman 的 Collection 支持分享Mock Server 也跟着共享。团队协作时有几种方式一种是把 Collection 分享给团队成员成员登录 Postman 后可以直接查看所有请求和 Example也能看到 Mock Server 的请求记录。后端同学只需要维护好 Example 里的响应体前端同学就能拿到几乎真实的数据。另一种是配合 Postman 的 Team Workspace把 Collection 和环境变量都放到共享工作区。每次后端调整响应结构只需要改动 Example前端刷新请求就能看到最新返回。这个协作模式很接近“接口契约管理”后端是生产方前端是消费方Mock Server 是透明管道。我实际项目中用过 Team Workspace 的方式效果不错。后端的每个字段变更前端都能及时感知到不会出现联调当天才发现某个字段类型不对。团队成员也无需本地安装任何额外工具。但有一点要提醒共享 Collection 时要注意权限避免有人误改 Example 影响整个团队的 Mock 数据。Postman 有版本历史记录改错了可以回滚但高频的误改会打断别人的联调节奏。5.3 从 Postman 到 Newman 的 CLI 流程如果你想把 Mock 服务集成到 CI 流水线里Postman 命令行工具 Newman 是不可或缺的一环。Newman 可以直接运行 Collection并且读取指定的环境变量文件。例如我导出集合文件collection.json和环境变量文件env-mock.json然后执行newman run collection.json -e env-mock.json此时请求中的{{baseUrl}}会被替换成 Mock Server 地址整个集合会在命令行跑一遍输出每个请求的断言结果。结合 CI我一般这样配置后端接口文档更新后同步更新 Postman Collection 里的 Example提交 Collection 到仓库可以导出 JSON 后放 GitCI 流水线里运行 Newman对着 Mock Server 执行接口冒烟测试测试通过后再触发真正的后端构建和部署。这样的好处是接口契约的验证前置到了 CI 阶段。即使后端代码还没就绪前端和测试也能通过 Mock Server 提前把接口层的问题消化掉。等真实环境部署后再把 CI 里的环境变量切换成真实环境同一套用例继续跑。6. 我用 Postman Mock Server 踩过的坑与排查思路6.1 请求返回 404匹配规则与实际路径不一致Mock Server 返回 404 是我遇到最多的问题。明明创建了 Example为什么请求过去就是 404排查顺序一般是这样的先看 Collection 里请求的路径是什么。比如我建了一个GET /api/users的请求Mock 域名是https://xxxx.mock.pstmn.io那么访问地址必须完整拼成https://xxxx.mock.pstmn.io/api/users。如果我在 Collection 请求里写的路径是http://localhost:8080/api/usersPostman 生成 Mock 时会保留后面这段路径但如果我请求时写成了https://xxxx.mock.pstmn.io/users那当然匹配不上。还有一个容易忽略的是 HTTP 方法。Example 对应的是GET /api/users我拿 POST 去请求一样会 404。Mock Server 的匹配规则严格遵循方法和路径。排查时最有效的办法是打开 Mock Server 的 Call Logs。在 Mock Servers 列表里点进对应 Server里面有每次请求的日志显示命中路径、方法、匹配到的 Example 名称。我排查 404 时基本一眼就能看出是路径写错还是方法写错。6.2 动态变量没生效响应体里的模板语法写错了动态变量看起来简单但出错率不低。我第一次写{{$request.query.userId}}时写成了{{$request.query. userId}}多了一个空格结果返回的就是一段纯文本而不是真正的参数值。还要注意动态变量和 Handlebars 模板语法只能用在响应体里不要在响应头里写太复杂的模板。响应头里我一般只做简单拼接比如x-request-id: {{$guid}}这种。如果你发现动态变量返回的是字面量字符串比如返回了{{$randomInt}}而不是一个数字先检查拼写再检查是否引用了自定义变量但没有在环境变量里定义。Postman 的模板解析遇到未知变量时有时会原样输出。这个问题排查起来其实不难关键是要有“先看返回值再对照语法”的思路。6.3 Header、Cookie 和中文响应体的“玄学”中文乱码问题在 Mock Server 里也出现过。响应体虽然是 JSON但如果没有显式设置Content-Type: application/json; charsetutf-8某些客户端可能按默认编码解析中文就变成乱码。我在 Example 的响应头里固定加上 charsetContent-Type: application/json; charsetutf-8这个习惯帮我避免了不少后续麻烦。Cookie 的场景要特别注意。Mock Server 免费版对跨域、Cookie 的处理不像真实后端那样灵活前端如果依赖 Set-Cookie 保持登录态用 Mock Server 模拟可能不生效。这时候我一般就改用请求头传递 token或者在响应体里返回 token 字段前端自己存储并携带。逻辑上虽然不够“真实”但至少联调不会卡住。6.4 Mock Server 生效延迟与免费版配额修改 Example 后Mock Server 的数据理论上会很快生效但我确实遇到过延迟十几秒的情况。原因是服务端节点缓存特别是你刚修改完立即请求有时候拿到的是旧响应。遇到这种情况不用急着删掉重建先等半分钟再请求一次基本就正常了。免费版的模拟请求配额也要心里有数。之前我有一次跑自动化测试一个循环跑了上千次请求直接就把当月配额用完了。之后请求一直报错排查了半天才发现是配额问题。如果你的团队高频使用 Mock Server建议升级到付费版或者把不必要的循环请求收敛一下别拿 Mock Server 当压测工具用。这里再分享一个我平时处理“更新后不生效”的排查顺序先看响应头里的x-mock-response-*系列字段是不是你想要的那个 Example如果是说明匹配到了只是内容还是旧的如果箭头指向了别的 Example说明匹配规则有冲突请求头条件没有准确命中目标分支。整体上用下来Postman Mock Server 最大的价值不是“造假数据”本身而是把前后端协作从“你等我、我等它”改成了“先并行后对齐”。我现在做项目接口文档确定后前端同事会第一时间把不同场景的 Example 补齐所有联调都先跑在 Mock Server 上等后端真正就绪后切换环境变量即可完成无缝迁移。这套流程减少了大量等待时间也让接口契约在开发早期就被反复验证至少在接口格式这块不会再出现联调当天推倒重来的局面。