应先用pm.response.json()提取JSON响应，再分别解析startTime和endTime为Date对象并转毫秒时间戳，最后比较大小；需处理空值、格式异常、时区偏差及NaN校验，避免字符串字典序比较。
pm.test 里用 JavaScript 做时间比较，不是靠 Postman 内置断言，得自己解析、转成可比的时间戳。
怎么从响应里提取两个时间字段并转成 Date 对象
常见场景是接口返回 JSON，含 startTime 和 endTime 字段，格式可能是 ISO 字符串（如 "2026-11-04T09:30:00Z"）、时间戳数字（1762277400000），或自定义字符串（"2026-11-04 09:30:00"）。
必须先确保能安全解析：
- 用
pm.response.json()拿到响应数据，再取字段，别直接用responseBody字符串去match，容易出错 - 对非标准格式（比如带空格无 T 的），用
new Date(str)可能失败，建议加try/catch或用moment（但 Postman 不自带，得避免） - 如果字段可能为空或缺失，先做存在性判断，否则
new Date(undefined)会变成Invalid Date
endTime > startTime 断言写法及常见报错
核心逻辑是把两个时间都转成毫秒级时间戳再比较。错误往往出在类型或时区上：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 直接写
jsonData.endTime > jsonData.startTime—— 失败，字符串比较不是时间比较（"2026-11-04 10:00:00" > "2026-11-04 09:59:59"看似成立，但实际按字典序比，不可靠） - 没处理时区：ISO 字符串带
Z是 UTC，不带可能是本地时区，混用会导致比较偏差 - 没检查
isNaN(new Date(x).getTime())，导致断言抛异常，整个测试标为FAIL而不是具体失败原因
推荐写法：
pm.test("endTime after startTime", function () {
var jsonData = pm.response.json();
var start = new Date(jsonData.startTime);
var end = new Date(jsonData.endTime);
pm.expect(start.getTime()).to.be.a('number').and.not.equal(NaN);
pm.expect(end.getTime()).to.be.a('number').and.not.equal(NaN);
pm.expect(end.getTime()).to.be.greaterThan(start.getTime());
});
如何兼容不同时间格式（ISO / 时间戳 / 自定义）
不能假设后端统一格式。稳妥做法是写一个简易解析函数：
- 先尝试
new Date(x)，再用.getTime()判断是否有效 - 如果是数字类型（时间戳），直接用
Number(x)，再确认是否大于1e12（避免把 2026 当成 2026 年毫秒时间戳） - 对
"YYYY-MM-DD HH:mm:ss"这类，手动拼成"YYYY-MM-DDTHH:mm:ss"再解析，或用正则提取年月日时分秒再传给new Date(year, month-1, day, hour, minute, second) - 别依赖
moment或dayjs，Postman 浏览器环境不支持，pm.*API 也不提供时间工具
真正容易被忽略的是时区隐式转换——比如后端返回的 "2026-11-04 10:00:00" 实际是东八区时间，但 new Date() 会按当前浏览器时区解释，若你在纽约调试，就可能差 13 小时。最稳的方式是后端统一返回 ISO 8601 带时区（如 +08:00）或 UTC（Z），前端不做任何假设。
