Postman 发送空 JSON 对象（{}）可行，但后端是否接受取决于服务端校验逻辑；常见 400/422 错误源于 Spring @Valid 校验、网关拦截、Content-Type 缺失或 JSON 格式错误。
Postman 发送空 JSON 对象（{}）本身完全可行，但后端是否接受、是否触发预期逻辑，取决于接口实现——不是 Postman 限制，而是服务端校验逻辑决定的。
为什么 {} 有时会报错或被拒绝
常见现象是：请求发出去了，状态码却是 400 Bad Request 或 422 Unprocessable Entity，响应体里写着 “request body is empty” 或 “required field missing”。这不是 Postman 没发成功，而是后端框架（如 Spring Boot 的 @RequestBody）默认做了非空校验，或业务代码主动判空并抛异常。
-
@RequestBody注解在 Spring 中默认允许空对象，但若加了@Valid或字段级@NotNull，且类中没有可选字段，{}就会校验失败 - 某些 API 网关或中间件（如 Kong、Nginx + lua）可能配置了 body 长度拦截，
Content-Length: 2（即{}的字节数）低于阈值时直接拦截 - 前端 SDK 或 OpenAPI 规范生成的客户端可能自动过滤空对象，但 Postman 不受此影响——它只管你填什么就发什么
Body 设置为 raw + JSON 时，{} 必须合法且无多余字符
Postman 的 raw → JSON 模式会做基础语法校验。粘贴 {} 后如果右上角出现红色波浪线或 Send 按钮变灰，说明格式不通过。最常踩的坑是：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 用了中文标点，比如
｛｝或："——必须用英文半角符号 - 末尾多了一个逗号：
{,}或{"a":1,}（虽然部分解析器容忍，但 Postman JSON 模式会报错） - 开头/结尾有不可见空格或换行符，尤其从编辑器复制过来时容易带 BOM 或
\u200b - 误选了
Text而非JSON模式：此时 Postman 不校验，但Content-Type头不会自动补全，需手动确认Headers里有Content-Type: application/json
测试空对象时，Headers 和 Content-Type 不能依赖自动补全
Postman 在选择 raw → JSON 时，**仅当 Body 标签页处于激活状态且内容非空时**，才会自动在 Headers 中添加 Content-Type: application/json。一旦你清空内容变成 {}，这个头可能被悄悄移除——导致后端按 text/plain 解析，直接报错。
- 务必手动切到
Headers标签页，检查是否存在Content-Type这一行；如果没有，手动生成：Key 填Content-Type，Value 填application/json - 如果接口要求 UTF-8 显式声明，写成
application/json; charset=utf-8（注意分号后有空格） - 某些老版本 Spring（如 5.2 之前）对
charset敏感，不带可能触发 ISO-8859-1 解码，导致中文字段乱码——即使空对象也建议带上
验证空对象是否真正到达后端的简单方法
光看 Postman 的响应状态码不够，得确认后端日志或断点是否真收到了 {}。推荐在测试时配合最小化后端逻辑：
- 写一个裸 Spring Boot 接口：
@PostMapping("/test") public String echo(@RequestBody Object body) { return body.toString(); }，发送{}，看返回是不是{}或LinkedHashMap@xxx - 用
curl交叉验证：curl -X POST http://localhost:8080/test -H "Content-Type: application/json" -d "{}"，排除 Postman UI 干扰 - 在 Postman 的
Tests标签页加一行：console.log(pm.request.body.raw);，发送前打开 Postman Console（View → Show Postman Console），确认发出的确实是{}
空 JSON 对象看似简单，但最容易被忽略的是「后端校验链路」和「Postman 自动头行为」之间的错位——发得出来，不等于后端接得住；接得住，也不等于业务逻辑能兜底。动手前先看接口文档有没有明确写“允许空 body”，比反复试错更省时间。
