Postman发送空JSON数组报400，主因是Content-Type未显式设为application/json、JSON格式非法（如写成{}或null而非[]）、或后端框架对[]解析策略不一致；需手动添加Header、确保body为{"items":[]}，并验证服务端实际接收内容。
Postman 发送空 JSON 数组本身没有特殊限制，但服务端解析失败、字段被忽略或 400 报错，几乎全是 Content-Type 缺失、JSON 格式非法或后端框架默认丢弃空数组导致的——不是 Postman 的问题，是配置或代码没对齐。
Content-Type 必须显式设置为 application/json
即使 body 选了 raw + JSON，Postman 也不会自动加 Content-Type 请求头。不加这个头，Spring Boot 默认当表单处理，FastAPI 可能拒收，Node.js body-parser 会跳过解析。
操作要点：
- 在
Headers标签页手动添加一行：Content-Type→application/json - 不要依赖 “JSON” 下拉选项自动补头——它只改界面提示，不发真实 header
- 用
Console（View → Show Postman Console）确认请求发出时是否真带了该 header
空数组必须写成合法 JSON：[]，不能留空或写 null
常见错误是 body 留白、填 null、{} 或 ""，这些都不是空数组。后端收到后要么解析失败，要么当成缺失字段。
正确写法只有这一种：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
{"items": []}
其他典型错误示例：
-
{}→ 没有items字段，后端取不到数组 -
{"items": null}→ 是 null，不是空数组；Jackson 默认不反序列化 null 为List -
{"items": ""}→ 字符串，类型不匹配，直接 400 - body 完全空白 →
Content-Length: 0，多数框架拒绝解析
后端框架对空数组的默认行为差异大
即使 Postman 发得完全正确，不同语言/框架对 [] 的处理逻辑可能截然不同：
- Spring Boot + Jackson：若字段声明为
List<string> items</string>，[]能正常绑定；但若用了@NotNull或自定义Deserializer，可能拦截 - FastAPI：默认接受
[]，但如果字段加了min_items=1校验，会返回 422 - Express +
body-parser：需确保type: 'application/json'配置生效，否则[]会被当成undefined - PHP（Laravel）：
json_decode对[]返回空 array，但若控制器参数用了array类型声明且没设默认值，可能报错
验证空数组是否真正送达服务端
光看响应状态码不够，要确认服务端日志或加断点看实际接收到的原始 body 内容：
- 用
console.log(req.body)（Node.js）或System.out.println(request.getBody())（Java）打印原始输入 - 检查是否被中间件（如 Nginx、API 网关）提前截断或重写
- 如果服务端返回 400 但没说明原因，开 Postman Console 查看完整请求体和响应 headers，重点看
Content-Type和Content-Length
空数组测试真正卡点不在 Postman 怎么点，而在于前后端对“空”的语义是否一致——[] 是有效值还是无效占位符，得看接口契约怎么定，不能只靠 Postman 猜。
