Postman Collection Runner 中环境变量全局共享导致迭代间互相污染，需用唯一 iteration ID 构造变量名（如 user_id_1730741160123_0）配合 pm.environment.set() 实现隔离，并在 Tests 中清理；或优先使用 pm.variables.set() 进行单请求内临时传递。
Postman 迭代运行（Collection Runner）时，如果多个数据行共用同一组变量（比如 token、cart_id），后一轮会覆盖前一轮的值，导致中间请求失败或断言误判。必须让每轮迭代拥有独立的变量空间。
为什么 pm.environment.set() 在迭代中会互相污染
环境变量是全局共享的——无论 Collection Runner 跑多少次，pm.environment.set("user_id", "1001") 总是写入同一个键。第二轮迭代执行时，user_id 就被新值覆盖，而第一轮后续依赖它的请求（比如删除用户）还在排队，这时取到的就是错误 ID。
- 变量作用域不随迭代隔离，只随环境切换隔离
- Collection Runner 不自动创建“迭代上下文”，需手动模拟
- 错误现象：第 1 行成功、第 2 行 404、第 3 行 401，但单步执行全 OK
用 pm.variables.set() + 唯一 key 实现每轮独立变量
pm.variables.set() 是 Postman v9.15+ 引入的局部变量 API，其值仅在当前请求生命周期内有效；但它不能直接用于跨请求传递。真正可行的是：在 Pre-request Script 中为本轮生成唯一变量名，并写入环境变量，再在 Tests 中清理。
- 在 Pre-request Script 中生成本轮标识：
const iterationId = pm.iterationData.get("id") || Date.now() + "_" + pm.iteration; - 用该 ID 构造变量名：
const userIdKey = `user_id_${iterationId}`; - 写入环境变量：
pm.environment.set(userIdKey, responseJson.data.id); - 在下游请求 URL 或 Header 中引用：
{{user_id_1730741160123_0}} - （可选）Tests 中清理：
pm.environment.unset(userIdKey);避免环境变量膨胀
用 data 变量 + 动态提取避免环境变量滥用
如果只是本请求链内部传递（如登录 → 获取 profile → 修改 profile），完全不必写环境变量。直接在 Tests 中解析响应，然后用 pm.variables.set() 存临时值，在下一个请求的 Pre-request Script 中读取即可：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
// 登录请求的 Tests
const res = pm.response.json();
pm.variables.set("auth_token", res.data.token);
pm.variables.set("user_email", res.data.email);
// 下一个请求的 Pre-request Script
const token = pm.variables.get("auth_token");
pm.request.headers.add({key: "Authorization", value: `Bearer ${token}`});
-
pm.variables的生命周期 = 单次请求从 Pre-request 到 Tests 结束 - 它不跨请求、不跨迭代、不污染环境，天然适配 Collection Runner
- 缺点：不能在 URL 栏里用
{{xxx}}插值（仅支持脚本读取）
迭代中调试变量冲突的三个关键检查点
遇到“单步 OK，批量失败”，优先查这三项：
- 是否在 Tests 中用了
pm.environment.set("token", ...)—— 改成带 iteration ID 的 key - 是否在 Pre-request Script 中读取了未初始化的变量，比如
pm.environment.get("order_id")返回 undefined 导致 URL 拼接出错 - 是否启用了「Clear environment variables before run」但没勾选「Persist variables after run」，导致下个请求读不到上个请求设的值
最易忽略的是变量命名空间缺失：所有团队项目都应该约定变量前缀，比如 iter_user_id_、iter_cart_token_，而不是裸写 user_id——否则哪怕加了 iteration ID，日志里也看不出来源。
