{{$timestamp}}是Postman内置秒级Unix时间戳变量，开箱即用、自动刷新、轻量可靠；需毫秒、格式化、偏移或跨请求复用时才用Pre-request Script。
Postman 里最简单的时间戳用法就是直接写 {{$timestamp}}，它默认返回秒级 Unix 时间戳，不用写脚本、不依赖环境变量、每次发送请求自动刷新。
为什么 {{$timestamp}} 够用却常被忽略
很多人一上来就写 Pre-request Script，其实大半场景根本不需要。Postman 内置的 {{$timestamp}} 是开箱即用的动态变量，解析时机在请求构造阶段，比脚本更早、更轻量。
- 它只支持秒级（不是毫秒），但绝大多数后端接口要求的就是秒级时间戳
- 不能自定义格式或偏移，但如果你只需要“现在是什么时候”，它就是最稳的选择
- 不经过 JS 引擎，不存在
new Date()在某些时区下解析异常的问题 - 在 URL、Headers、Body（raw/json）里都能直接用，比如
GET /api/log?ts={{$timestamp}}
pm.environment.set("ts", Date.now()) 适合什么情况
当你需要毫秒级时间戳、ISO 字符串、带偏移的时间（如“30分钟前”）、或要复用同一个时间戳贯穿多个请求时，就必须用脚本。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Date.now()返回毫秒级时间戳；Math.floor(Date.now() / 1000)才是秒级，别漏除法 - 存到
pm.environment.set()是为了跨请求共享（比如登录后把时间戳传给后续接口）；用pm.globals.set()则全局生效，注意污染风险 - 如果要格式化成
2026/11/05 05:36:00这种字符串，必须手写getFullYear()+padStart(2, "0")拼接，toISOString()默认带 T 和 Z，可能不兼容老接口 - 时区陷阱：直接
new Date("2026-11-05")会按本地时区解析，建议统一用new Date("2026-11-05T00:00:00Z")显式声明 UTC
时间偏移计算容易出错的三个点
减 5 分钟、加 2 小时这类操作看似简单，但 JS 的 Date 对象处理不当会导致结果错乱，尤其跨月、跨年或夏令时切换时。
- 别用
getMinutes() - 5然后setMinutes()—— 这样不会自动进位，-5 分钟可能变成负数 - 正确做法是操作毫秒数：
const d = new Date(Date.now() - 5 * 60 * 1000)，再格式化 - 如果要“今天零点”，别写
setHours(0,0,0,0)，而应先new Date().setHours(0,0,0,0)或用new Date(new Date().toDateString()) - 测试时注意：Pre-request Script 中的
console.log()不会显示在 Postman 控制台，要用pm.test()或断点调试才能确认值是否正确
真正麻烦的从来不是“怎么生成时间”，而是“生成的时间是否被后端按预期解析”。尤其当接口文档只写“传时间戳”却不说明单位或时区时，{{$timestamp}} 的秒级 + 本地时区行为反而成了最可预期的基准。先用它跑通，再根据实际响应调整脚本，比一开始堆逻辑更可靠。
