Postman 发送嵌套 JSON 时必须手动设置 Content-Type: application/json，否则 Flask、Spring Boot、C# MVC 均解析失败；还需校验 JSON 语法正确性、避免深层嵌套空值异常，并注意数组与对象类型匹配。
Postman 发送嵌套 JSON 时 Content-Type 必须显式设置为 application/json
不设这个头，request.get_json() 在 Flask 中会返回 None，@RequestBody 在 Spring Boot 中会报 400，C# MVC 的模型绑定也会静默失败。Postman 虽然在选了 raw + JSON 后「自动添加」该 header，但这个行为不可靠——比如你切回 form-data 再切回来、或从历史请求复制过来时，header 可能被清空。
实操建议：
- 永远手动检查
Headers选项卡里是否存在Content-Type: application/json - 不要依赖下拉菜单“自动添加”，尤其在团队协作共享集合时，header 状态不继承
- 如果后端用的是
request.form或request.values（Flask），它根本不会解析 JSON，必须用request.get_json()
Body 选 raw + JSON 后，JSON 语法错误会导致 400 且无具体提示
Postman 不校验 JSON 合法性，只原样发出去。服务器收到非法 JSON（如末尾多逗号、单引号代替双引号、中文冒号）时，多数框架直接拒绝解析，返回 400 Bad Request，但错误信息常是空的或笼统的 “invalid JSON”。
常见问题现象：
- Flask 报
AttributeError: 'NoneType' object has no attribute 'get'—— 其实是request.get_json()返回了None - Spring Boot 报
HttpMessageNotReadableException，堆栈里带JsonParseException - Postman 响应体为空，状态码是 400，Header 里也看不出问题
实操建议：
- 粘贴 JSON 后，先点右上角
Preview查看是否渲染成树形结构；若显示“Invalid JSON”，说明语法有误 - 用在线工具（如 jsonlint.com）或 VS Code 打开校验，注意隐藏的 BOM、不可见 Unicode 字符
- 嵌套对象中避免使用 JavaScript 风格写法：
{name: "Alice"}❌，必须是{"name": "Alice"}✅
嵌套字段在后端取值时容易触发 KeyError 或 NullReferenceException
前端传了 {"user": {"name": "Alice"}}，后端直接写 data['user']['name'] 很危险：只要任意一层缺失（比如 user 字段没传），就会崩。
不同语言典型处理差异：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- Flask 推荐用
data.get('user', {}).get('name', 'default')，避免KeyError - Spring Boot 的
@RequestBody默认要求字段全量存在，可加@Nullable或用Optional包装，但更推荐 DTO +@Valid校验 - C# MVC 模型绑定对 null 嵌套属性容忍度低，
Address.PostCode若Address为 null，直接抛NullReferenceException，需前置判空或用可空引用类型（Address?）
实操建议：
- Postman 测试时，故意少传某层字段（如去掉
address对象），验证后端是否健壮 - 别在日志里直接
print(data['user']['address']['city'])，先确认路径存在 - 复杂嵌套建议用 Pydantic（Python）、Jackson JsonNode（Java）或 System.Text.Json.Nodes（C#）做动态解析
数组+对象混合嵌套时，注意后端反序列化目标类型是否匹配
比如 Postman 发送：
{
"items": [
{"id": 1, "quantity": 2},
{"id": 3, "quantity": 1}
]
}后端若声明接收为 List<item></item>（Java）或 list[dict]（Python），没问题；但若写成 Item[] 却没加 @RequestBody 注解，或 Python 里用了 request.json['items'][0]['id'] 却没检查 items 是否为 list 类型，就容易出错。
性能与兼容性影响：
- 超大数组（>5000 项）可能触发 Spring Boot 的
max-http-header-size或 Flask 的MAX_CONTENT_LENGTH限制，默认通常只有 16MB，但 JSON 解析本身也吃 CPU - Postman 的
raw模式对超长 JSON 渲染慢，可改用binary+ 文件上传方式绕过（适合含 base64 图片的嵌套结构）
实操建议：
- 数组字段名别用复数但内容是单对象（如
"users": {"id": 1}），这会让后端解析逻辑混乱 - 测试边界值：空数组
"items": []、null数组"items": null、非数组类型（如"items": "abc"） - 如果嵌套太深（>5 层）或结构动态，考虑改用 GraphQL 或分拆成多个接口，别硬扛
真正麻烦的不是怎么写 JSON，而是当嵌套字段名拼错一个字母、或者某层对象意外为 null 时，错误表现往往藏在下游逻辑里，而不是第一行日志中。
