Postman执行Collection Run时不等待Tests内setTimeout暂停是否为设计使然？

• 核心原因是你用的setTimeout(function(){}, 10000)是通用JS环境的异步宏任务，Postman的脚本执行机制从根上就不会等待这类任务。
• Postman对Tests、Pre-request面板的脚本执行逻辑是：只要当前同步代码块执行完毕，不管沙箱里有没有挂着未触发的异步回调，都会直接把当前步骤标记为完成。如果在Collection Run的控制台里看日志，会发现那个setTimeout的回调大概率要等整个Collection全部跑完之后才会触发，根本不会卡住中间的流程。
• 单独运行单个请求时你觉得功能正常，完全是场景巧合带来的错觉：单个请求的网络往返、响应渲染本来就有几秒的间隔，手动点完发送之后也会盯着界面等结果，自然会把这部分耗时误以为是setTimeout起的延迟作用。实际上你设置的10秒延迟大概率根本没到触发时间，脚本就已经跑完了。

• 用Postman官方提供的pm.setTimeout替代原生setTimeout。这个方法是直接接入Postman执行循环的，不管单跑还是Collection Run，系统都会等这个方法设置的超时回调执行完，才会推进到下一个步骤。
• 你完全可以动态计算延迟时长：比如上一个接口返回了异步任务的预计处理时间、或者轮询状态结果，就把计算出来的需要等待的秒数传给pm.setTimeout，不需要给所有步骤统一写死固定等待值。
• 没有特殊等待需求的步骤不用加任何延迟代码，保持原执行速度就行；只有需要等待下游任务就绪的节点，单独配置对应的动态延迟，不会给整个Collection Run增加不必要的等待成本。

常见踩坑点：pm.setTimeout和原生setTimeout名字相近，但执行逻辑完全独立，前者被执行链路托管，后者在沙箱里自生自灭，千万别混着用。

内容的提问来源于stack exchange，提问作者Guy