Postman怎么把返回ID用于后续查询_Postman创建查询接口关联方法-java教程-PHP中文网

结论：用pm.response.json()取值 + pm.variables.set()存变量 + {{variable_name}}在URL或Body里引用；需区分临时变量与环境变量，注意JSON路径、变量名一致性及双大括号引用格式。

postman怎么把返回id用于后续查询_postman创建查询接口关联方法

Postman里怎么提取响应里的ID并用在下个请求里

直接说结论：用pm.response.json()取值 + pm.variables.set()存变量 + {{variable_name}}在URL或Body里引用。关键不是“能不能”，而是“在哪取、怎么存、何时生效”。

常见错误是把pm.environment.set()和pm.variables.set()混用，或者在Tests里写对了，却忘了在后续请求的URL里用双大括号引用——结果ID根本没传过去，还怀疑接口有问题。

只在当前请求生命周期内生效的临时变量，用pm.variables.set("id", value)
要跨请求、跨标签页复用（比如登录后一直带着token），才用pm.environment.set("user_id", value)
环境变量必须提前在右上角「Environments」里创建好，否则pm.environment.set()会静默失败
URL中引用变量时，必须写成https://api.example.com/users/{{id}}，不能漏掉双大括号，也不能多加空格

Tests脚本里提取JSON响应中的ID字段

别硬记语法，先看返回体长什么样。如果响应是{"data": {"id": 123, "name": "test"}}，那pm.response.json().data.id才是对的；要是返回{"id": 123}，直接pm.response.json().id就行。错一层对象就undefined，后面全白搭。

建议加上防御性判断，避免因字段缺失导致脚本中断：

const res = pm.response.json();
if (res && res.data && res.data.id) {
    pm.variables.set("target_id", res.data.id);
} else if (res && res.id) {
    pm.variables.set("target_id", res.id);
} else {
    console.error("Failed to extract ID from response");
}

在下一个GET请求URL里正确使用提取的ID

很多人卡在「明明存了变量，URL里却还是{{id}}没替换」。检查三件事：变量名拼写是否一致、是否在发送前刷新过环境（小闪电图标）、该请求是否选对了环境（右上角下拉菜单）。

URL示例（注意格式）：

Postman 12.27.7

Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。

下载

https://api.example.com/v1/orders/{{target_id}}

如果ID带前缀（比如"order_abc123"），又不想手动截取，可以在Tests里处理后再存：

const fullId = res.data.id;
const cleanId = fullId.replace("order_", "");
pm.variables.set("target_id", cleanId);

POST请求Body里怎么插入提取的ID（比如作为关联字段）

Body选raw → JSON时，不能直接写"related_id": "{{target_id}"——JSON语法不认双大括号。必须用Pre-request Script提前把变量注入到Body字符串里。

操作步骤：

在下一个请求的「Pre-request Script」里写：pm.request.body.raw = pm.request.body.raw.replace(/{{target_id}}/g, pm.variables.get("target_id"));
Body内容写成：{"related_id": "{{target_id}}", "status": "pending"}
确保pm.variables.get("target_id")有值，否则会替换成undefined

复杂点在于：变量注入时机必须早于请求发送，且仅对当前请求生效；如果多个请求共用同一份Body模板，得靠不同变量名区分，不然容易串。