调一次接口，计执等三秒。行脚调十次，计执等三十秒。行脚写脚本的计执时候最烦的不是代码本身，是行脚那种"点一下、等一会儿、计执看结果"的行脚节奏。API Post 的计执预执行脚本功能，解决的行脚就是这个事——它让你在请求真正发出去之前，先跑一段 JavaScript。计执

这个功能藏在哪？行脚打开 API Post，选中一个请求，计执找到"预执行脚本"或"Pre-request Script"标签页，行脚点进去就是计执一个代码编辑器。你可以在这里写任意 JS，操作环境变量、生成签名、修改请求参数，甚至发一个额外的 HTTP 请求去拿 token。

为什么需要"执行前"这一步

很多接口不是你把 URL 和 body 填好就能直接调的。最典型的就是鉴权。比如某个 API 要求请求头里带一个 sign 字段，值是 appKey + timestamp + body 拼起来再做 MD5。你每次手动算？不现实。预执行脚本里写三行代码就搞定了：

const timestamp = Date.now().toString(); const raw = pm.environment.get("appKey") + timestamp + JSON.stringify(pm.request.body); const sign = CryptoJS.MD5(raw).toString(); pm.request.headers.add({  key: "sign", value: sign }); pm.request.headers.add({  key: "timestamp", value: timestamp });

这段脚本在请求发出前跑完，header 自动带上去了。你点"发送"的时候，sign 已经算好了。不用切终端，不用开另一个工具。

变量操作是核心

API Post 的预执行脚本能读写环境变量和全局变量，这是它最实用的地方。我见过一个场景：测试一套订单流程，创建订单返回 orderId，后续的查询、取消、退款接口都要用这个 ID。手动复制粘贴？一次两次还行，跑回归测试的时候就是灾难。

预执行脚本配合测试脚本就能串起来。在创建订单的"测试脚本"里把 orderId 写进环境变量，在后续接口的"预执行脚本"里读出来塞进 URL 或 body。整条链路自动跑通。这种用法在 API Post 里很常见，官方文档也给了示例，但真正用起来的人不算多——很多人还是习惯手动改参数。

有个细节：预执行脚本里访问请求体，用的是 pm.request.body，但它的格式取决于你选的 body 类型。raw JSON 和 form-data 拿到的结构不一样。我踩过这个坑，脚本里 JSON.stringify 之后发现多了一层转义，排查了半天。后来干脆在脚本里先 console.log 一下，确认结构再写逻辑。

还能干点别的

预执行脚本不只能算签名。有人用它做请求参数的动态替换——比如从 CSV 文件读测试数据，每次请求换一组参数。也有人用它做条件跳过：如果某个环境变量没设置，直接 pm.execution.skipRequest()，请求就不发了。这个在批量跑集合的时候很有用，避免无效请求污染测试结果。

还有人在预执行脚本里发一个登录请求，拿到 token 再塞给当前请求。这相当于把"登录"这一步前置了，省得你单独调一次登录接口再复制 token。不过要注意，预执行脚本里发请求是异步的，得用 pm.sendRequest 配合回调，写起来比同步代码绕一点。

几个实际使用中的注意点

脚本执行时间算在请求总耗时里。如果脚本里做了复杂计算或者发了额外请求，接口响应时间会变长。调试的时候别被这个误导，以为服务端慢了。

另外，预执行脚本的作用域是单个请求。如果你有十个请求都要算同样的签名，要么每个都复制一份脚本，要么用集合级别的预执行脚本——API Post 支持在集合层级写脚本，集合内所有请求都会执行。这个层级的脚本适合放公共逻辑，比如统一鉴权。

最后提一句，脚本里 pm.environment.set() 设的变量，在当前请求的测试脚本里能读到，在下一个请求的预执行脚本里也能读到。但如果你在集合运行器里跑，变量是跨请求持久的。这个特性用好了，整条测试链路就是自动化的；用不好，变量互相覆盖，排查起来很头疼。建议变量命名带上前缀，比如 order_id、user_token，别用 id、token 这种通用词。

说到底，预执行脚本就是把"请求发出前需要做的杂活"代码化了。你用不用它，接口都能调通。但当你一天要调五十次同一个接口，每次都要手动改时间戳、算签名、换 token 的时候，写一次脚本的投入，几分钟就回本了。

(责任编辑：综合)