Postman时间戳自动生成：从动态变量到预请求脚本

我平时帮着联调接口的时候，最常被问到的问题之一就是：Postman 里请求参数怎么自动填当前时间戳。问的人既有刚学接口测试的新人，也有写了好几年业务代码、但没怎么抠过调试工具的老前端。这个需求听起来很小，无非是让 timestamp 这个参数别让我每次手动复制粘贴，但真要把它做得干净、好用、兼容各种签名校验场景，里面其实藏着不少细节。

这篇文章我就从零开始把这件事拆开讲。核心场景是 Postman 请求参数中需要携带当前时间戳，尤其是前后端联调、写接口自动化脚本、或者对接第三方平台签名时特别常见。适合前端工程师、测试工程师、后端开发在日常接口调试中使用。我会把几种实现方式、它们的适用边界、以及我在实际项目里踩过的坑全部整理出来，尽量让你看完就能照着配、照着用。

1. 为什么请求参数里要带时间戳，手工填为什么靠不住

1.1 时间戳在接口调用中的真实用途

先说个基本问题：后端为什么要看时间戳？我见过很多刚入行的同学，会把 timestamp 当作一个“形式参数”，后端要什么就传什么，从不关心它的业务含义。但实际项目中，时间戳这个字段通常承担着几类重要职责。

最常见的是接口签名校验。很多团队的开发现状是：前端调用后端接口时，除了传业务参数，还要额外传一个 timestamp 和一个 sign。sign 的生成规则通常是“将请求参数按字典序拼接，再拼上 timestamp 和密钥，做 MD5 或者 HMAC 加密”。这里 timestamp 的作用，就是告诉后端“这条请求是哪一刻生成的”。后端拿到请求后，会检查 timestamp 与当前服务器时间的差值。如果超过例如 5 分钟，直接判定为过期请求，拒绝执行。这能有效防止有人抓包后反复重放同一个请求，也就是俗称的“时间戳防重放”。

第二种常见场景是生成唯一标识。比如你提交订单时，前端生成一个订单号，字符串后面往往跟着“yyyyMMddHHmmss”这种时间拼接串，保证同一秒内的并发请求也能区分开。第三种是数据时间范围查询。比如拉取用户操作日志，参数里带 startTime 和 endTime，这本质上也是时间戳的一种变体。第四种是缓存控制。一些网关会根据请求中的时间戳决定是否命中缓存，或者在指定时间窗口内允许重复请求，窗口外重新执行。

我举一个自己实际遇到的例子。之前对接一家物流平台的开放接口，文档里清清楚楚写着：请求头需要传 Timestamp，用 Unix 秒级时间戳，且与服务器时间差不能超过 120 秒。刚开始我在 Postman 里手动填了一个时间，第一次调试是过了，可等我调完一个字段，再点一次 Send，后端就返回“请求过期”。原因很简单：我填的时间是五分钟前开网页工具复制过来的，早就超出 120 秒窗口了。这就是手工填时间戳最大的痛点——你根本没法保证“复制的那一刻”和“点击发送的那一刻”是同一种时间状态。

1.2 手工填时间戳的三大弊端

手工填时间戳看起来只是麻烦一点，其实还存在三个不容易察觉的问题。

第一，时间不同步引发签名校验失败。如果接口的签名算法把 timestamp 作为参与因子，你手工填的时间一旦与后端服务器时间差太多，即使业务参数完全正确，后端也能通过签名值比对发现异常。签名算出来的是一个固定字符串，但它参与的输入里包含了一个你不容易精确控制的时间，这就导致你每次调试都可能在同一个问题上反复折腾。

第二，操作耗时不可控。你打开在线时间戳工具，复制结果，回到 Postman 粘贴，再点击发送。这个流程快的话 5 秒，慢的话 30 秒。如果接口的过期时间比较严格，比如 5 秒或者 10 秒，很可能你刚粘贴完还没点发送，这个时间戳就已经失效了。我见过一些对接支付接口的同事，为了赶在时间窗口内发出去，练就了一手“秒开秒贴”的操作，根因就在这。

第三，批量调试时根本无法手工维护。当你有几百个请求，每个请求都要带不同的 timestamp，或者同一个请求要连续执行多次做参数校验时，手工填写的劣势会被无限放大。你根本做不了循环测试，因为每次都要重新去复制时间戳。所以真正成熟的解决办法，是让 Postman 在每次发送请求时自动生成当前时间戳，并填入参数。

1.3 两种主流自动取时间戳的思路

Postman 要自动取当前时间戳，本质上只有两套思路。

第一套思路是使用 Postman 自带的动态变量。你不需要写任何代码，直接在 URL、Headers、Body 里写 {{$timestamp}}，Postman 会在请求发出前的瞬间生成一个秒级 Unix 时间戳替换进去。这是最简单、最不动脑子的方式，但它的功能也相对固定。

第二套思路是使用 Pre-request Script（预请求脚本）来生成时间戳，并写入环境变量或者全局变量。你可以把 timestamp 设置成普通变量 {{timestamp}}，脚本里用 JavaScript 计算出当前时间戳并赋值给它。这种方式的好处是：你可以控制时间戳的精度、格式、偏移量，可以在同一份脚本里生成多个相关参数，甚至可以配合签名算法一起算好 sign，一次性把参数全部填好。

这两套思路没有绝对的好坏，关键是看你的使用场景。我个人的建议是：只是临时调试一下，用 {{$timestamp}}；自己长期维护的接口集合，或者需要签名逻辑的，用 Pre-request Script。下面我会把两个方案都展开讲透。

2. 方案一：利用 Postman 内置动态变量，一行配置搞定临时需求

2.1 {{$timestamp}} 的配置流程

Postman 内置动态变量的使用方式很简单，但很多人第一次用的时候容易忽略一个关键点：这个变量不是像普通环境变量那样先在变量管理里定义好，而是直接嵌入到请求参数中。

比如你的请求 Body 是一段 JSON：

json复制{
    "productId": "p_1001",
    "timestamp": "{{$timestamp}}"
}

当你点击 Send 时，Postman 会把 {{$timestamp}} 替换成当前时间的 Unix 秒级时间戳。注意看，这里加了双引号，替换后的值也是字符串格式，比如 "1742567890"。如果你接口定义的是数值类型，那可以把双引号去掉，写成：

json复制{
    "timestamp": {{$timestamp}}
}

替换后 JSON 里的值就没有引号，直接是数字类型。这种细节在对接严格的后端接口时很重要，因为有些后端框架对 JSON 类型校验非常严格，字符串和数字混用会导致反序列化报错。

同理，如果 timestamp 是放在 URL 查参里，比如 GET 请求的链接是：

text复制https://api.example.com/order/query?timestamp={{$timestamp}}

那 Postman 同样会自动替换。放在 Header 里也一样：

text复制Timestamp: {{$timestamp}}

这个方法说实话真的快，整个配置过程不到十秒，不需要写代码，也不需要考虑变量作用域。

2.2 常用的几个动态变量一揽

使用 {{$timestamp}} 时，大家最常弄混的是它和 {{$isoTimestamp}} 的区别。前者生成的是 Unix 秒级时间戳，一般是 10 位数字，比如 1742567890；后者生成的是 ISO 8601 格式的带时区时间字符串，比如 2025-03-21T15:58:10+0800。两个值一个是纯数字，一个是人类可读的字符串，接口文档里如果只说传“时间戳”，多半是指前者；如果明确要求标准时间格式，就用后者。

Postman 的动态变量远不止这两个。我再列几个我实际用过的：

如果你只是想快速调试一个不需要精确控制时间格式的接口，{{$timestamp}} 完全够用。但要注意，这个方式有个很隐蔽的小问题：同一个请求里，如果你在多个地方引用了 {{$timestamp}}，它们生成的值是同一个，还是不同？我实测过很多次，结论是：在同一次请求中，Postman 会为同一个动态变量生成同一个值。也就是说，URL 里的 {{$timestamp}} 和 Body 里的 {{$timestamp}} 会是同一个时间戳，不会出现一个早一秒一个晚一秒的错位情况。这个特性在有签名校验的场景里特别关键，因为签名必须基于同一个时间戳去计算，如果两边时间戳不一致，后端验签必然失败。

2.3 内置动态变量的局限

内置动态变量虽然简单，坑也相当明显。

首先，{{$timestamp}} 默认生成的是秒级时间戳，而且你没法让它生成毫秒级。有些后端接口为了更高的唯一性要求，会要求传 13 位毫秒时间戳。这时候你就不能用内置动态变量了，因为它完全不受你控制，只能输出 10 位秒级值。

其次，你没法做时间偏移。举个实际场景：你测试一个“token 有效期 30 分钟”的功能，想模拟一个已经过期的 token，就需要生成一个“当前时间减去 31 分钟”的时间戳。用内置动态变量做不到。你必须在脚本里写 Date.now() - 31 * 60 * 1000，再除以 1000 取整。

第三，格式固定，不能定制。比如你想生成 yyyy-MM-dd HH:mm:ss 这种字符串给表单参数用，内置动态变量同样满足不了。

所以我把内置动态变量的定位概括为“临时救急”。它适合你刚装完 Postman、只是想验证一下接口通不通的场景。一旦你开始写接口自动化测试脚本，或者要维护一套团队共用的接口环境，就应该转用第二种方案。

3. 方案二：Pre-request Script 脚本生成，覆盖绝大多数复杂场景

3.1 预请求脚本的原理

Pre-request Script 是 Postman 在发送请求之前执行的一段 JavaScript 脚本。你可以把它视为“请求之前的一个钩子”，在请求真正发出去之前，先把变量、签名、加密逻辑都准备好。

它的执行顺序是：你点击 Send → Postman 读取当前环境变量/全局变量 → 执行 Pre-request Script → 脚本中通过 pm 对象设置变量 → 请求携带这些变量发出。这意味着脚本有足够的时间计算时间戳、拼接签名、随机数、甚至是做一次 AES 加密。

我在做接口自动化时，几乎每个 Collection 都会配一个统一的 Pre-request Script。因为你想想看：一个 Collection 里可能有几十个接口，如果每个请求都重复配置一遍时间戳生成逻辑，维护起来就是灾难。而脚本可以放在 Collection 级别，让下面所有请求自动生效，这才能让你从重复劳动里解放出来。

3.2 最常用的时间戳生成脚本

先看一个最简单、也最实用的脚本：

javascript复制// 生成当前时间的秒级时间戳
var timestamp = Math.floor(Date.now() / 1000);

// 写入一个普通变量，后续请求参数里用 {{timestamp}} 引用
pm.variables.set("timestamp", timestamp.toString());

// 同时写入环境变量，方便查看
pm.environment.set("timestamp", timestamp.toString());

这段脚本的核心就一行：Math.floor(Date.now() / 1000)。Date.now() 返回的是毫秒级时间戳，所以除以 1000 再向下取整，得到秒级时间戳。为什么要 floor 而不是 round？因为这跟后端通常对时间戳的定义保持一致。后端一般用 System.currentTimeMillis() / 1000 这种整数除法，小数部分直接舍去。如果你用 round，遇到刚好带上半秒的边界情况，可能比后端多 1 秒，就容易出现时间戳超前。

配置步骤我拆细一点，方便照着做：

1. 打开你要配置的请求，点击顶部“Pre-request Script”标签页。
2. 将上述代码粘贴进去。
3. 点击请求的 Body 或 Params，新增一个参数，名称为 timestamp，值为 {{timestamp}}。
4. 点击 Send，发送完成后把鼠标悬停在 Body 的参数上，就能看到实际被替换后的值。

我在实际操作中更喜欢用 pm.variables.set 而不是 pm.environment.set。原因有两个：一是 pm.variables.set 设置的变量优先级较高，请求中引用时会优先取到这个值；二是它不会污染环境变量面板，避免脚本运行一次就往环境变量里写入一堆临时数据。但如果你需要在请求之后继续使用这个时间戳，比如在 Tests 脚本里校验，那么设置成 environment 或者 variables 都可以，因为 Tests 脚本也能读取到。

3.3 生成 13 位毫秒级时间戳

有些接口要求时间戳是毫秒级，尤其是一些高并发的支付、订单系统。方法很简单，把 Math.floor(Date.now() / 1000) 改成 Date.now() 即可。

javascript复制// 毫秒级时间戳
var timestamp = Date.now();
pm.variables.set("timestamp", timestamp.toString());

这里有个细节容易踩坑：Date.now() 返回的是一个 number 类型，直接用于 JSON 参数中没问题，但如果后端要求字符串类型，你就要先转成字符串，否则 Postman 在替换变量时可能会因为类型问题导致 JSON 序列化方式不同。稳妥起见，我一般统一用 .toString() 转换。

还有一个更细的坑：13 位时间戳如果直接用数字传给后端，有些后端语言（比如 Java 的 int 类型）会溢出，因为 13 位数字超出了 int 的最大范围。所以很多接口会要求传字符串形式的毫秒时间戳。我的经验是：除非接口文档明确说传 long 或 number，否则优先用字符串，至少字符串不会引发类型溢出问题。

3.4 生成自定义格式的时间戳

时间戳并不一定非得是 Unix 数字。有些老系统，或者说某些由 PHP 后端开发的接口，更习惯接收 Y-m-d H:i:s 这样的日期时间字符串。

在 Postman 的脚本里没有内置的日期格式化函数，但你可以手写一个。我把自己常用的一个函数贴出来：

javascript复制function formatTimestamp(date) {
    var y = date.getFullYear();
    var m = String(date.getMonth() + 1).padStart(2, '0');
    var d = String(date.getDate()).padStart(2, '0');
    var h = String(date.getHours()).padStart(2, '0');
    var min = String(date.getMinutes()).padStart(2, '0');
    var s = String(date.getSeconds()).padStart(2, '0');
    return y + '-' + m + '-' + d + ' ' + h + ':' + min + ':' + s;
}

pm.variables.set("timestamp", formatTimestamp(new Date()));

这个脚本在接口调试中非常实用。尤其是不需要 Unix 时间戳，而是要在 Body 表单里传一个“下单时间”的场景。你直接引用 {{timestamp}}，得到的值就是 2025-03-21 15:58:10 这种可读格式。

不过要提醒一点：上面这段脚本生成的日期是本地时区的时间，不是 UTC。如果你的后端部署在海外，或者团队统一使用 UTC 时间，那么要把 getHours()、getMinutes()、getSeconds() 换成 getUTCHours()、getUTCMinutes()、getUTCSeconds()，否则就会出现“前端填的下午三点，后端看到的是晚上十一点”这种时区错位问题。

3.5 同一个请求里多个参数需要同一个时间戳怎么办

在签名接口中，一个请求往往不止一个地方需要时间戳。比如请求头里有一个 Req-Timestamp，Body 里也有一个 timestamp，签名脚本里还要用一个相同的时间戳去计算 sign。这时候如果你在三个位置都直接写 {{$timestamp}}，虽然 Postman 会给同一个值，但你无法控制签名脚本里读到的值是否一致。

更好的做法是全部交给脚本控制。我在实际项目中经常这样写：

javascript复制var timestamp = Math.floor(Date.now() / 1000).toString();

// 写入 header 变量
pm.variables.set("headerTimestamp", timestamp);

// 写入 body 变量
pm.variables.set("bodyTimestamp", timestamp);

// 计算签名并写入变量
var signStr = "productId=p_1001&timestamp=" + timestamp + "&key=your_secret_key";
var sign = CryptoJS.MD5(signStr).toString();
pm.variables.set("sign", sign);

然后在 Header 里写 {{headerTimestamp}}，Body 里写 {{bodyTimestamp}}，签名参数里写 {{sign}}。这样三个位置的时间戳都来自同一个 timestamp 变量，签名计算过程也因为变量统一而不会出现错位。

这个技巧极其重要。我遇到过不止一次：一个同事把自己关在工位上排查三个多小时，发现后端一直报验签失败。最后我看了一眼他的签名脚本，发现他用的是请求发送后的 Tests 脚本里重新生成了一次时间戳，而不是用请求前生成的那个，导致签名内容与实际发送的请求参数不一致。这种问题如果不统一时间戳生成源，排查难度非常高。

3.6 脚本中的 CryptoJS 从哪来

可能有人会问，上面代码里用的 CryptoJS 是哪里来的？这是我的另一个习惯：尽量在脚本开头引入 Postman 内置的 crypto-js 库。

Postman 的脚本运行环境内置了 CryptoJS，所以你不需要专门去安装什么依赖，直接使用即可。不过要注意大小写，我用的是 CryptoJS.MD5，而不是 crypto-js。

javascript复制var timestamp = Math.floor(Date.now() / 1000).toString();
var sign = CryptoJS.MD5("timestamp=" + timestamp + "&key=secret").toString();
pm.variables.set("sign", sign);

如果你们公司用的是 SHA256、HMAC-SHA256 之类的算法，CryptoJS 也能满足。我在实践中发现，Postman 内置的 CryptoJS 版本对不同算法的支持比较齐全，基本够用。唯一要注意的是后端签名算法里字符串拼接的规则千差万别，有的要 URL encode，有的要按 ASCII 码排序，这些不是本文的重点，但每个团队都应该把自己的签名规则沉淀成一段公共脚本，放在 Collection 级别。

4. 方案三：全局变量与 Collection 级脚本组合，团队协作更省心

4.1 把时间戳放进全局变量还是环境变量

很多人一开始是在某个请求的 Pre-request Script 里即时生成时间戳，这样确实能用，但一旦接口多了，就会发现每个请求要重复配置脚本，改起来也麻烦。

我的做法是：把“生成时间戳”这个逻辑提升到 Collection 级别，在 Collection 的 Pre-request Script 里统一生成，然后全部写入全局变量或者环境变量。

先说全局变量和环境变量的区别。全局变量的作用域是整个 Postman 应用，你切换环境也好，切换集合也好，都能访问到。环境变量则是跟着环境走的，你在“生产环境”设置的值，切换到“测试环境”就是另一套值。时间戳这个变量比较特殊，它每次请求都应该重新生成，所以理论上放在哪里都行。但如果你团队里同时存在多个环境，我建议把与请求业务无关的、每次生成的时间戳放在全局变量，把与特定环境相关的接口域名、密钥放到环境变量。这样职责清晰，也方便不同环境基于同一个时间戳做签名。

Collection 级别的 Pre-request Script 我一般这样写：

javascript复制// Collection 级别统一生成时间戳
var timestamp = Math.floor(Date.now() / 1000).toString();
pm.globals.set("timestamp", timestamp);
pm.globals.set("sign", CryptoJS.MD5("timestamp=" + timestamp + "&key=" + pm.environment.get("apiKey")).toString());

这里用 pm.environment.get("apiKey") 读取当前环境变量里的密钥，好处是切换环境时密钥自动跟随变化，签名也能跟着正确计算。

4.2 Collection 级脚本比单请求脚本好在哪

说实话，单请求脚本和 Collection 级脚本在功能上没有本质差别，都能生成时间戳。但工程化思维下，Collection 级脚本有压倒性优势。

第一，集中维护。签名算法更新了，你只需要改一个地方的脚本，全 Collection 的请求都自动生效。如果每个请求单独配脚本，更新时要改几十个地方，而且容易漏。

第二，保证一致的行为。在一个 Collection 里，有些接口可能需要毫秒时间戳，有些需要秒级时间戳。你可以通过读取环境变量里的配置来切换，但前提是所有请求都走同一个脚本，而不是各自为政。

第三，最容易忽略的一点：Collection 的 Pre-request Script 会先于该 Collection 内所有请求执行，包括文件夹级的请求。这意味着你可以在 Collection 里定义公共函数，然后在具体请求的脚本中调用。Postman 的脚本执行顺序是：Collection 级脚本 → 文件夹级脚本 → 请求级脚本。利用这个顺序，我可以把公共的时间戳生成函数写在 Collection 级，请求级脚本里直接调用，避免重复代码。

4.3 一个可以直接抄的团队级时间戳模板

下面是我目前团队里用的一套模板，供参考。这套模板做了三件事：生成时间戳、计算签名、日志输出。

javascript复制// ========== 公共时间戳与签名生成 ==========
function getTimestamp() {
    return Math.floor(Date.now() / 1000).toString();
}

function buildSign(params, secret) {
    // 示例：将 params 对象按 key 排序后拼接，再加上 secret
    var keys = Object.keys(params).sort();
    var str = "";
    for (var i = 0; i < keys.length; i++) {
        str += keys[i] + "=" + params[keys[i]] + "&";
    }
    str += "key=" + secret;
    return CryptoJS.MD5(str).toString();
}

var ts = getTimestamp();

// 把需要参与签名的业务参数统一放进来，实际按接口文档调整
var signParams = {
    timestamp: ts,
    productId: pm.variables.get("productId") || "p_1001"
};

var apiKey = pm.environment.get("apiKey") || "test_key";
var sign = buildSign(signParams, apiKey);

// 设置变量供请求使用
pm.variables.set("timestamp", ts);
pm.variables.set("sign", sign);

// 调试日志，便于排查
console.log("Generated timestamp:", ts);
console.log("Generated sign:", sign);

使用这套模板时，你在请求里只需要引用 {{timestamp}} 和 {{sign}}，完全不需要关心它们怎么来的。如果签名规则变动，改这一处脚本就行。

console.log 是我强烈建议保留的。在 Postman 里，点击左下角“Console”可以打开调试控制台，脚本中的日志会显示在 Console 中。我踩过的一个坑就是：脚本里时间戳生成正确，但请求里引用了另一个同名变量，导致实际发送的值是旧的。后来全靠 console.log 打印出当前变量值，才定位到是变量覆盖问题。

4.4 新增请求时如何避免时间戳变量污染

团队协作时还有一个隐患：某个请求的脚本里直接调用了 pm.globals.set("timestamp", ...)，把全局变量里的时间戳覆盖成了自己的值。如果这时另一个请求也引用了同一个全局变量，就会出现“A 请求改动了 B 请求的时间戳”这种互相污染的情况。

我的规避方法是：只允许在 Collection 级脚本中设置时间戳相关变量，请求级脚本如需特殊处理，用 pm.variables.set 设置局部变量，不要动全局变量。局部变量的优先级最高，它只影响当前请求，不会污染其他请求。这一点几乎是我在团队规范里明文规定的第一条。

如果你发现自己的变量值总是不对，先检查三件事：请求级脚本是否覆盖了变量、环境变量里是否有同名变量并处于激活状态、全局变量里是否有残留旧值。Postman 的变量查找优先级依次是：局部变量（pm.variables）→ 数据变量 → 环境变量 → 全局变量。所以如果你在环境变量里设了一个固定 timestamp，又在脚本里设置了一个新值，请求里引用时取的是脚本设置的局部变量，而不是环境变量。听上去合理，但第一次遇到时，很容易因为“环境变量面板里明明看到了一个值，请求里却是另一个值”而发懵。

5. 常见问题与排查技巧实录

5.1 时间戳对不上导致签名总是 401

这是我在支持其他团队时遇到最多的问题。现象很典型：接口返回 401 或者“验签失败”，但 Postman 里看着所有参数都是对的。排查步骤我总结为四步。

第一步，先看请求实际发出的参数。在 Postman 的 Console（控制台）里，你能看到请求的完整信息，包括最终替换后的 URL、Headers 和 Body。确认这里的 timestamp 是不是新生成的当前时间。

第二步，看时间差。如果替换后的时间戳与你本机当前时间差了超过接口允许的窗口，那就是时间戳生成有问题。常见原因包括：脚本写错、变量被覆盖、或者你用的动态变量 {{$timestamp}} 在请求前就已经被缓存了。

第三步，确认前后端时间是否同步。很多时候本地测试没问题，部署到服务器后签名失败，原因是服务器系统时间不准。你可以让后端先打印一下服务器当前时间和收到的时间戳对比。如果两者差了几分钟，不是你的代码问题，而是系统时钟问题。

第四步，确认签名拼接规则。尤其是当签名规则里要求“时间戳参与计算”时，一定要保证你计算 sign 用的 timestamp 与请求里实际传输的 timestamp 是同一个字符串。否则签名必然失败。我教大家一个最笨但最有效的方法：先把请求里的 timestamp 固定成一个值（比如 1742567890），签名也用这个固定值去算。如果这样能通过，说明算法对；然后把时间戳改成动态生成的，如果失败，就是时间戳在生成和引用之间不统一。

5.2 10 位还是 13 位？单位含糊导致的坑

接口文档里经常只写一个 timestamp 字段，不写单位。用户看到后端代码里写 System.currentTimeMillis()，就以为要传 13 位毫秒时间戳；但实际对接后发现，后端又把它除以 1000 转成了秒。这种问题在联调阶段特别消耗时间。

我的建议是：在团队内部建立默认约定，接口文档里必须明确写清“单位：秒，10 位整数”或者“单位：毫秒，13 位整数”。如果是外部平台接口，文档没写清，就先抓包看他们官方示例里的值是多少位。10 位值的典型特征是数字以“17”开头（2033 年之前约 10 位），13 位值一般以“17”开头后面还跟着三位数字。肉眼判断最快。

如果项目里同时存在两类接口，我建议把生成逻辑做成两个函数：

javascript复制function timestampSec() {
    return Math.floor(Date.now() / 1000).toString();
}

function timestampMs() {
    return Date.now().toString();
}

在具体请求的 Pre-request Script 里按需调用，避免“一刀切”。

5.3 变量没有刷新，一直用的上一次的值

有时候你会遇到这样的情况：脚本明明写了 pm.variables.set("timestamp", ...)，但连续点了几次 Send，后端收到的 timestamp 一直没变。排查了半天，发现是因为请求里的参数写的是环境变量 {{timestamp}}，而环境变量面板里有人手动设定过这个值，脚本里的 pm.variables.set 设置的是局部变量，优先于环境变量，所以理论上应该能覆盖。但如果你点到的是“环境变量面板”里的那个 timestamp，而且脚本里恰好用的是 pm.environment.set，这时就要检查当前环境是否激活。Postman 的环境变量必须保证当前选中的环境是你写脚本时操作的那个环境，否则 pm.environment.set 会把值写到环境变量里，但当前请求激活的是另一个环境，自然不会生效。

还有一个更隐蔽的缓存点：Postman 的 Collection Runner 在迭代执行时，变量的刷新时机可能跟你预期的不一样。如果你在 Runner 里一次性跑 100 次请求，脚本会在每次请求前执行，但如果你引用了 {{$timestamp}} 这种动态变量，Postman 的文档里说明它在每次迭代时都会重新生成。实测下来，大多数版本是符合预期的。但如果你在脚本里用了 pm.environment.set("timestamp", ...)，Runner 的迭代间隔很短，新增的值可能在下一次脚本执行前还没有被完全刷新。稳妥的方案是：在脚本里使用局部变量 pm.variables.set，同时确保下游读取不经过环境变量的缓存层。

5.4 时区不一致导致的可读时间戳偏差

这一条主要针对生成 Y-m-d H:i:s 字符串的场景。很多后端为了计算方便，会要求前端传 UTC 时间，或者要求传“零时区”时间，但前端开发者本机在东八区，直接用 getHours() 生成的就是本地时间。等到后端一比对，发现提交时间和服务器时间差了 8 小时，就会判定为无效请求。

解决办法有两个。如果你要生成 UTC 时间，用：

javascript复制function formatUTCTimestamp(date) {
    return date.getUTCFullYear() + '-' +
        String(date.getUTCMonth() + 1).padStart(2, '0') + '-' +
        String(date.getUTCDate()).padStart(2, '0') + ' ' +
        String(date.getUTCHours()).padStart(2, '0') + ':' +
        String(date.getUTCMinutes()).padStart(2, '0') + ':' +
        String(date.getUTCSeconds()).padStart(2, '0');
}

如果接口类型是 Unix 时间戳，就不存在时区问题，因为 Unix 时间戳本身是一个绝对时刻，与时区无关。所以我在团队里更推荐用 Unix 时间戳传递时间，可读时间字符串只用于展示层。

5.5 压测、自动化跑批时时间戳反复跳变怎么办

做接口自动化时，有时需要断言某响应里的时间戳与请求时间戳一致。但如果你在请求前生成了一次时间戳，等到断言时 pm.environment.get("timestamp") 可能已经因为请求之间的时间间隔变化而变了。

解决思路是：在脚本里把请求前生成的时间戳保存到一个专门的变量，并且在整个断言过程中不要覆盖它。我建议用两个变量：请求用的 timestamp 和记录用的 requestTimestamp。或者干脆用 pm.variables.set("snapshotTimestamp", ...)，然后在 Tests 里读取这个快照值。

我在跑批时还遇到过一个问题：批量执行多个请求时，每个请求的时间戳都不同。如果接口有防重放机制，时间窗口较窄，就会出现一部分请求成功、一部分失败的现象。这种情况不是脚本的问题，而是并发或时序导致的。如果测试目标不是“验证防重放”，可以手动把时间戳设成一个固定值，比如 1742567890，并同步修改签名里的时间戳，让请求稳定通过。

5.6 用脚本日志定位问题

最后分享一个我每天都在用的排查习惯。凡是涉及时间戳的脚本，我一定会加上日志输出：

javascript复制console.log("Timestamp before request:", timestamp);
console.log("Sign:", sign);

需要看的时候，打开 Postman 左下角的 Console 面板，就能看到每次请求的脚本执行日志和最终请求报文。有一次我帮同事排查，发现他脚本里生成的时间戳是 10 位，但接口要求 13 位，请求却一直报签名错。他看了好半天没发现位数不对，最后就是在 Console 面板里一眼看到实际发出的值，才瞬间明白问题出在哪里。这个习惯成本极低，却能在每次排查时帮你省下至少半小时。

6. 我的收尾建议与个人经验

讲到这里，Postman 请求参数自动使用当前时间戳的几种主流做法都过了一遍。我个人的最终建议很简单：日常临时调试优先用内置动态变量 {{$timestamp}}；需要稳定复用、签名计算、毫秒格式或者时间偏移的，一定要走 Pre-request Script；多接口协作时把脚本提升到 Collection 级别统一维护。

再说一个我最近踩到的小坑，也当给大家提个醒。我在某个接口的 Pre-request Script 里写了这么一行：

javascript复制pm.globals.set("timestamp", Math.floor(Date.now() / 1000));

结果另一个完全不相关的 Collection 请求里也引用了 {{timestamp}}，它的值莫名其妙跟着变了。那一次我才真正意识到“全局变量污染”在协作团队里有多坑。后来我把所有跟业务相关的临时变量都收敛到局部变量或环境变量里，全局变量只保留诸如基础域名、公共密钥这类几乎不变的信息。

最后再送一个小技巧：Postman 里其实可以把脚本保存为片段，在新建 Collection 时一键插入。配置位置在设置里的“Snippets”部分。我把自己常用的时间戳生成脚本、MD5 签名脚本、HMAC 签名脚本都存过片段。新建项目时直接插入，改改密钥和参数名就能用。这个习惯让我在多个项目之间切换时省下了大量重复配置时间。你的团队如果还没有统一这套模板，强烈建议从今天开始搭一套。