Postman集合中请求执行顺序由postman.setNextRequest()控制而非界面拖动；其参数须为集合内已保存请求的全名，大小写和符号需完全一致，多次调用仅最后一次生效，设为null可终止流程。
Postman 集合中请求的执行顺序，不是靠“拖动”就万事大吉的——尤其当存在依赖、分支或循环逻辑时，仅靠界面排序会失效，必须用 postman.setNextRequest() 控制。
Collection Runner 界面拖动只影响默认线性执行
在 Collection Runner 界面里拖动请求，确实能改变「无脚本干预时」的执行顺序。但它只起作用于以下场景：
- 所有请求的
Tests或Pre-request Script中都没有调用postman.setNextRequest() - 你勾选了全部请求（未勾选的请求会被跳过，哪怕它排在第一位）
- 不涉及条件跳转、失败重试、轮询等动态流程
一旦某个请求里写了 postman.setNextRequest("xxx")，Runner 就会立刻接管流程控制，界面顺序完全失效。这时候拖动只是心理安慰。
用 postman.setNextRequest() 指定下一个请求名
这是真正可控、可编程的排序方式，必须写在 Tests（推荐）或 Pre-request Script 里。注意几个硬约束：
- 参数必须是集合内**已保存的请求全名**，大小写、空格、符号都要完全一致，比如
postman.setNextRequest("Login - v2")，写成"login - v2"或"Login-v2"都会静默失败 - 同一个脚本里多次调用，只有最后一次生效；不要在
if分支外再写一条兜底语句，容易覆盖逻辑 - 设为
null表示终止流程：postman.setNextRequest(null)（注意是小写null，不是字符串"null"） - 目标请求如果在 Runner 中未被勾选，流程会直接中断，后续任何请求都不会执行
示例：想实现 A → C → B → D 的跳转链，在对应请求的 Tests 中写：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
/* A 的 Tests */
postman.setNextRequest("C");
<p>/<em> C 的 Tests </em>/
postman.setNextRequest("B");</p><p>/<em> B 的 Tests </em>/
postman.setNextRequest("D");带条件的顺序控制：用 if + postman.setNextRequest()
接口返回结果决定下一步走哪条路，这是真实测试中最常见的需求。关键点在于：必须先解析响应，再做判断，且避免未定义字段导致脚本崩溃。
- 用
pm.response.json()安全取值，配合?.可选链或typeof判断 - 分支目标请求名必须全部存在于当前集合中，否则跳转失败后流程卡住
- 不要遗漏 else 分支，否则未命中条件时会退回到默认线性顺序（可能执行你不希望的请求）
示例：登录成功跳转订单查询，失败则跳转错误日志上报：
const res = pm.response.json();
if (res.code === 0 && res.data?.token) {
postman.setNextRequest("Order List");
} else {
postman.setNextRequest("Log Error");
}循环和轮询必须加退出条件，否则跑飞
用 postman.setNextRequest() 指向自身或前置请求，很容易构成无限循环。Postman 不会自动检测或中断，它会一直跑直到超时或手动停止。
- 每次循环前应检查状态变量（如全局变量
pm.globals.get("retry_count")），超过阈值就设为null - 轮询类请求（如查任务状态），必须基于响应体中的字段（如
status === "success"）决定是否继续，不能只靠计数 - 记得在循环入口请求里初始化计数器，否则每次运行都从 undefined 开始判断
最容易被忽略的是：postman.setNextRequest() 在 Pre-request Script 中执行时，会影响当前请求是否发出——它不会阻止当前请求发送，但会改变下一轮调度。这个时序细节，不调试根本看不出来。
