pm.expect(...).to.not.exist 是判断 JSON 字段完全缺失的最可靠方式，它仅确认字段未定义或根本不存在，不适用于检测 null 或空字符串；必须先校验父级对象存在，深层路径推荐用 _.get() 安全取值。
用 pm.expect(...).to.not.exist 判断字段不存在
Postman 的断言基于 Chai 断言库，to.not.exist 是最直接、最可靠的方式判断某个 JSON 字段是否完全缺失（即 undefined 或根本没出现在响应中）。它不关心字段值是 null 还是 ""，只确认该属性压根没被返回。
常见错误是误用 to.be.null 或 to.eql(null) —— 这些只能检测字段存在但值为 null，而字段缺失时会直接抛 TypeError: Cannot read property 'xxx' of undefined，导致整个断言失败甚至中断执行。
正确写法示例：
pm.test("data.items 字段不应存在", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.data).to.exist; // 先确保 data 存在（避免后续报错）
pm.expect(jsonData.data.items).to.not.exist; // 再断言 items 缺失
});
- 必须先检查父级对象是否存在，否则访问
jsonData.data.items会因jsonData.data为undefined而崩溃 - 不要写成
pm.expect(jsonData.data.items).to.be.undefined——undefined在 Chai 中不是“可断言值”，行为不稳定 - 如果字段可能为
null或""，但你只要求“不能出现”，仍用to.not.exist；若需区分“缺失”和“显式 null”，得额外加一层pm.response.json()解析后手动判断
处理嵌套路径字段缺失：用 _.get 避免层层判空
当要断言的字段路径很深（比如 response.data.user.profile.avatar.url），手动逐级判断 .data → .user → .profile → .avatar → .url 很啰嗦且易漏。Postman 内置了 Lodash 的 _.get 方法，能安全取值并默认返回 undefined（不会报错）。
示例：断言深层字段 meta.trace_id 不存在
pm.test("meta.trace_id 不应返回", function () {
var jsonData = pm.response.json();
var traceId = _.get(jsonData, "meta.trace_id");
pm.expect(traceId).to.not.exist;
});
-
_.get(jsonData, "meta.trace_id")在任意一级为undefined或null时都返回undefined，不会中断脚本 - 不要依赖
jsonData.meta?.trace_id—— Postman 的 JS 执行环境（V8 旧版本）不支持可选链操作符（?.），会语法报错 - 路径字符串必须用点号分隔，不能用方括号（如
"meta['trace_id']"不生效）
字段缺失但响应含 null 值？小心 JSON 解析后的行为差异
JSON 规范允许字段显式设为 null，比如 {"user": null} 和 {} 表面相似，但语义不同：user 字段在前者中“存在但为空”，后者中“根本不存在”。Postman 的 pm.response.json() 会如实还原这种区别。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
这意味着：
-
pm.expect(jsonData.user).to.not.exist→ 只通过{}，不通过{"user": null} -
pm.expect(jsonData.user).to.be.null→ 只通过{"user": null}，不通过{} - 若需求是“字段不得出现，也不得为 null”，得组合断言：
pm.expect(jsonData.user).to.not.exist+pm.expect(jsonData).to.not.have.property("user")（后者更严格，但效果等价）
实际接口中，后端有时会统一补 null 字段（尤其用 ORM 自动生成响应时），这时你以为的“缺失”其实是“显式 null”，务必先看 Raw 响应体确认真实结构。
为什么不用 tests["xxx"] = !jsonData.field 这类老写法
早期 Postman 支持 tests["msg"] = responseBody.has("error") 这类简写，但对字段缺失判断极脆弱：
-
tests["field missing"] = !jsonData.missingField在字段缺失时返回true，看似可行，但若字段值是0、false、""，也会被判为“缺失”，逻辑错误 - 该写法不抛错、不提供上下文，失败时只显示 “test failed”，无法定位是字段真缺失，还是值恰好为假值
- 新版 Postman 已逐步弃用
tests[xxx]形式，推荐统一用pm.test()+pm.expect()链式断言，结果可读性强、调试信息完整
真正容易被忽略的点：字段缺失断言不是“越简单越好”，而是要明确区分「未定义」「空值」「假值」。一次没看清响应结构就写错，后续所有用到该字段的断言都会连锁失效。
