Postman Mock Server 怎么返回指定响应：Examples、环境变量与匹配规则

前端页面还没接上真实后端时，Postman Mock Server 可以先把接口契约跑起来。但第一次配置时，最容易遇到的不是“服务没启动”，而是请求明明打到了 mock 地址，返回的却是另一个 Example。排查时先盯住四件事：HTTP 方法、路径变量、请求体匹配开关，以及是否用了明确的响应选择头。

先把 Postman Mock Server 的最小链路搭起来

准备一个名为 shop-api 的 collection，新增 GET /orders/:orderId 请求。在请求右侧打开保存菜单，选择保存为 Example，并把响应命名为 order-found。响应体保持小而明确：

{
  "orderId": "A1001",
  "status": "paid",
  "total": 128
}

接着从左侧 Services 进入 Mock Servers，创建一个绑定 shop-api 的 mock。创建窗口里确认三处：选择正确的 collection，是否需要私有访问，以及是否把 mock URL 保存成环境变量。建议勾选保存变量，并命名为 mock_url。

创建完成后，在环境的当前值中检查 mock_url 是否有实际地址。请求改成 {{mock_url}}/orders/A1001，悬停变量能看到解析后的值，再点击 Send。若返回 order-found 的 JSON，说明入口链路已经通了。

Example 里最容易漏掉的四个界面状态

Mock Server 不会凭空生成业务响应，它会从绑定 collection 的 saved examples 中找最接近的一条。因此，下面四项必须在 Example 页面逐项对齐：

这里有一个很实用的核对动作：在 collection 侧栏展开请求，点击 Example 名称进入详情，确认请求栏和响应栏都已经保存。只改了响应 Body、没有更新 Example 的情况，往往会让调试过程看起来像“改了但没生效”。

环境变量只负责换地址，不负责替你选 Example

把 mock 地址写成 {{mock_url}}，解决的是本地 mock、测试环境和线上地址之间的切换。它不会改变 Mock Server 的匹配算法，也不会自动让服务返回某一个响应。

变量解析异常时，先看请求右上角的变量面板：

1. 确认当前环境已经选中，而不是停留在 No Environment。
2. 确认 mock_url 的 Current value 有值，且没有被同名的更窄作用域覆盖。
3. 悬停 URL 中的变量，核对实际展开出来的地址和路径。

不要把固定的 mock 地址同时写进 URL 和环境变量。这样一旦切换环境，很难判断问题来自地址、路径还是响应匹配。

多个 Example 返回不确定时，按匹配优先级收窄

假设同一个 GET /orders/:orderId 下保存了 order-found 和 order-cancelled 两个 Example。只改变响应 Body，而不改变请求方法、路径变量或状态码时，两条记录的匹配得分可能相同，Mock Server 返回哪一条就不再是一个可靠的选择。

最省事的做法是给请求加一个明确的响应选择头：

x-mock-response-name: order-cancelled

如果名称可能重复，改用 x-mock-response-id。还可以用 x-mock-response-code: 404 按状态码筛掉无关 Example。需要让请求体参与判断时，在 Mock Server 配置里打开 request body matching，并保证请求和 Example 都有相同的 Content-Type: application/json。

保存、提交、验收：用一次可重复请求收尾

配置完成后，不要只点一次 Send 就结束。用下面三组请求做验收，结果应该能稳定复现：

• GET {{mock_url}}/orders/A1001：返回 order-found，状态码为 200。
• 同一地址增加 x-mock-response-name: order-cancelled：返回取消订单的响应，不被默认 Example 抢走。
• 删掉当前环境的 mock_url 值：URL 中的变量应出现红色提示，说明问题是环境值缺失，而不是服务端返回异常。

验收时建议打开 Postman Console 看最终请求地址和请求头；响应区再核对 Example 名称、状态码和字段。三处证据一致，才算把“接口地址正确”和“响应匹配正确”分开验证。

常见问题

为什么 Mock Server 总返回同一个 Example？

先检查多个 Example 是否使用了完全相同的请求方法和路径变量。若匹配得分相同，用不同路径变量、request body matching，或添加 x-mock-response-name 明确指定。

为什么 {{mock_url}} 在 URL 中变红？

通常是当前环境未选中、变量没有 Current value，或同名变量被关闭。打开变量面板并悬停检查实际值即可。

为什么打开请求体匹配后仍然返回旧响应？

确认请求和 Example 的 Content-Type 一致，JSON 字段和值也一致；同时检查 Mock Server 配置中的 request body matching 已保存。

什么时候应该用 x-mock-response-id？

当 Example 名称不唯一，或者团队希望用固定 UID 选择响应时使用它。名称适合快速调试，ID 更适合自动化请求。

Postman Mock Server 的关键不是多建几个响应，而是让每个 Example 都有可辨认的请求条件。先用环境变量稳定入口，再用方法、路径、请求体和响应选择头逐层收窄，最后在 Console 和响应区同时验收，后续接入前端或自动化脚本时就不会靠“碰巧返回正确”。