Postman判断响应体是否为合法JSON需用try...catch捕获pm.response.json()异常；优先使用该方法而非JSON.parse()；取值时用可选链?.防崩溃；复杂结构推荐tv4 JSON Schema校验。
Postman怎么判断响应体是合法JSON
Postman不会自动校验响应体是否为合法JSON，遇到 Unexpected token 或 JSON.parse: unexpected character 错误时，说明 pm.response.json() 执行失败——这本身就是最直接的“非法JSON”信号。
正确做法不是依赖解析结果，而是先捕获异常：
- 用
try...catch包裹pm.response.json()，在catch块里断言失败 - 不要用
pm.expect(...).to.be.a('object')反推——如果解析已崩溃，这行根本不会执行 - 某些服务返回空响应体（
204 No Content）或纯文本错误页（如 Nginx 502），也会导致json()报错
示例脚本：
pm.test("Response is valid JSON", function () {
try {
pm.response.json();
// 解析成功，无异常
} catch (e) {
throw new Error("Invalid JSON: " + e.message);
}
});
pm.response.json() 和 JSON.parse(pm.response.text()) 的区别
两者都用于解析响应体，但行为差异明显：
-
pm.response.json()是 Postman 封装方法，内部调用JSON.parse()，但会自动跳过 BOM 头、处理 UTF-8 编码异常，并在解析失败时抛出带上下文的错误 -
JSON.parse(pm.response.text())是原生 JS 方法，对 BOM、不可见控制字符、尾部逗号更敏感，错误信息更简陋（如Unexpected token后不带位置） - 当响应头
Content-Type不含application/json时，pm.response.json()仍可尝试解析；而部分老版本 Postman 会直接拒绝调用（报TypeError: Cannot read property 'json' of undefined）
建议始终优先用 pm.response.json()，仅在需兼容极旧环境或调试编码问题时才退回到 JSON.parse()。
嵌套结构深、字段动态时怎么安全取值断言
直接链式访问如 jsonData.data.list[0].id 极易因某层为 null 或 undefined 导致断言脚本中断（整个 Tests 停止执行），后续断言全跳过。
必须做防御性取值：
- 用可选链操作符
?.（Postman v9.15+ 支持）：jsonData?.data?.list?.[0]?.id - 老版本用逻辑判断：
jsonData && jsonData.data && jsonData.data.list && jsonData.data.list[0] && jsonData.data.list[0].id - 或封装工具函数：
_.get(jsonData, 'data.list[0].id', null)（需提前引入 Lodash CDN，不推荐） - 更稳妥的是先断言路径存在性，再取值：
pm.expect(jsonData).to.have.property('data').and.to.have.property('list')
错误示范：pm.expect(jsonData.data.list[0].id).to.eql(123) —— 一旦 jsonData.data 不存在，整段脚本崩掉，你根本看不到其他断言结果。
为什么 JSON Schema 校验比字段级断言更值得投入
当接口返回结构复杂、字段多、存在可选/条件字段时，逐个写 pm.expect(jsonData.xxx).to.exist 易遗漏、难维护、覆盖不全。
用 tv4（Postman 内置）做 Schema 校验，一次定义结构约束，自动覆盖类型、必填、嵌套、数组项规则：
- Schema 定义在
Tests中只需一段 JSON 描述，比 10 行字段断言更清晰 - 能发现“字段存在但类型错”（如
"id": "123"应为 number）、“少传了 required 字段”等手工断言难覆盖的问题 - 变更接口时，只需更新 Schema，无需重写全部断言逻辑
- 注意：tv4 不校验字段值内容（如枚举值），只校验结构和类型，需配合字段断言使用
真正容易被忽略的是：很多人把 Schema 写死在每个请求的 Tests 里，导致重复维护。应该抽成集合级预脚本或用 pm.collectionVariables.set() 统一管理 Schema 字符串。
