Postman 用 postman.setNextRequest() 模拟轮询实现异步任务状态查询，需固定请求名、在 Tests 中判断退出条件（如 status 为 success/failed）、限制最大次数（如30次）、检查响应码与关键字段，并优先用环境变量传递 task_id。
Postman 本身不支持原生循环，但可以用 postman.setNextRequest() 模拟轮询，这是最轻量、最可控的异步任务状态查询方式。
用 postman.setNextRequest() 实现自循环轮询
核心是让一个请求在 Tests 脚本里判断是否继续调自身。它不是“定时器”，而是“每次响应后决定下一次发什么”。适合图像生成、视频合成、订单创建这类返回 task_id 后需轮询 task_query 的场景。
- 必须把轮询请求命名为固定名称（比如叫 “Poll Task Status”），否则
postman.setNextRequest("Poll Task Status")会找不到目标 - 轮询逻辑写在该请求的 Tests 标签页里，不能写在 Pre-request Script（那时还没收到响应）
- 一定要加退出条件，否则无限循环卡死 Runner；常见退出依据是响应中
status字段值为"success"或"failed" - 建议加延时控制：用
setTimeout不行（Postman 沙箱不支持），改用pm.environment.set("delay", 2000)配合 Collection Runner 的 Delay 设置更稳妥
如何安全提取并传递 task_id
创建任务接口（如 realman_broadcast）返回的 task_id 必须可靠存下来，供轮询请求读取。全局变量（pm.globals）看似方便，但在并发或多次运行时容易污染；推荐优先使用环境变量（
pm.environment）。
- 在创建请求的 Tests 中写：
pm.environment.set("task_id", pm.response.json().task_id) - 轮询请求的 URL 填成：
{{base_url}}/api/task/query?task_id={{task_id}} - 如果创建接口返回的是嵌套结构（例如
{"data": {"task_id": "xxx"}}），记得路径写全：pm.response.json().data.task_id - 务必加空值校验，避免轮询请求因
task_id为空而 400 报错：if (pm.response.json().task_id) { ... }
轮询终止条件与超时保护
真实业务中，任务可能卡住、失败或永远不完成。只靠 status === "success" 不够，必须叠加次数或时间维度限制。
- 用环境变量记录轮询次数：
let count = pm.environment.get("poll_count") || 0; pm.environment.set("poll_count", count + 1); - 在 Tests 中加硬性退出：
if (count >= 30) { postman.setNextRequest(null); }（即最多查 30 次） - 检查响应状态码和字段完整性：除了
status，还要确认video_url或image_url是否存在，避免状态为 success 但结果字段为空 - 错误响应（如 500、timeout）也要触发终止，否则可能陷入无效重试：
if (pm.response.code !== 200) { postman.setNextRequest(null); }
真正难的不是写几行 JS，而是设计轮询边界——什么时候该停、停了之后怎么通知人、失败日志留哪些字段可追溯。这些细节不提前想清楚，跑起来就是一堆 “task_id 找不到” 或 “轮询到第 50 次还在 pending”。
