Postman 怎么保存请求示例：Examples、响应体与文档预览核对

接口调试的时候，明明刚拿到符合预期的响应结果，过几天回头找，已经记不清当时的状态码和返回样例是什么了。Postman 的 Example 刚好能解决这个问题：它把一个请求和一份对应响应保存成可复查的样本，后续还能在集合文档里展示。实际操作的关键不是点一下 Save Response 就完事，而是保存后检查请求、响应和文档三个位置是否一致。

先把请求放进 Collection，再开始保存

操作前建议先确认请求的归属。打开 Postman 左侧的 Collections，进入目标集合，再打开需要记录的对应请求。请求标题、HTTP 方法和 URL 先调整到稳定状态，尤其不要在未保存的临时标签页里反复改完 URL 后直接保存示例。

一个 Example 是请求与响应的配对存档。请求部分至少要核对方法、URL、Params、Headers 和 Body；响应部分则要核对状态码、响应 Headers 与 Body。这样存出来的样本才有复查价值，不会只剩一段孤立的 JSON 内容。

发送响应并保存为 Example

打开目标请求后点击 Send，先确认响应区域显示的是这次要留档的结果。核对完状态码和响应体没问题，在响应面板选择 Save Response，再跟着界面提示操作就能存为 Example。

弹出名称输入框的时候，不要填“成功返回”这种没法区分不同场景的名字。可以用“200 - 正常详情”或“404 - 资源不存在”这类命名方式，同一个请求下的多个结果扫一眼就能分清。

重新打开 Example，核对三组内容

保存结束后回到请求所在的 Collection，展开对应请求下的 Example 列表。不要看到列表多了一行就认为操作完成，打开刚存的示例，按下面三组内容逐项核对。

• 请求组：方法、URL、查询参数和请求体是否仍指向本次测试的接口。
• 响应组：状态码、响应体和关键响应头是否来自刚才那次返回。
• 展示组：Example 名称是否准确表达了对应场景，JSON 格式是否完整可读，错误响应有没有保留必要的排查字段。

如果之后你修改了基础请求的参数，记得回头打开旧 Example 再对比一次。旧示例应该保留它创建时的原始请求和响应内容，不会因为你后来修改了基础请求就自动变成别的场景。

从 API 文档预览做最后验收

存好的 Examples 不仅可以用于本地调试参考，也能直接用来生成 API 文档展示，还能给 Mock Server 提供响应匹配依据。这里先验收文档展示效果：打开集合的文档预览页面，找到对应请求，确认示例名称、请求方法、状态码和响应体的内容符合预期，普通读者也能轻松看懂。

这里有个很容易踩的误区：文档能正常打开，不代表示例内容就正确。如果文档里显示了旧 URL、空响应体或者错误的状态码，先回到工作区检查 Example 本身的内容，不要上来就反复刷新文档页面。

常见问题

为什么 Save Response 选项看不到？

先确认请求已经成功发送、下方出现了完整的响应区域，再确认当前请求属于某个 Collection。没有可保存的响应内容，或者请求还停留在临时标签页的状态下，保存入口可能不会按预期显示出来。

一个请求能保存多个状态码示例吗？

可以。同一个请求下可以保存多个 Examples，比如分别存 200 正常响应和 404 错误响应的结果，各自保留对应的响应内容，命名的时候标注清楚场景就行。

保存 Example 会不会自动修改原请求？

它保存的是创建那一刻的请求与响应样本。要是你之后修改了基础请求的配置，仍然可以随时打开旧 Example 查看它最初存下的 URL、参数和响应内容。

把保存动作变成可复查的工作习惯

一套很稳的验收顺序是：确认请求归属到指定 Collection → 发送请求拿到目标响应 → 点 Save Response 存为示例 → 打开 Example 核对本地内容 → 进到文档预览校验展示效果。每一步都留意页面上的可见状态，不要把“示例列表里多了一条记录”当成最终操作成功。尤其是错误响应，保留真实状态码和关键字段，往往比只存 200 成功样本实用得多。