Postman form-data中传JSON字符串需将字段类型设为text/plain而非application/json，Key填后端约定名（如payload），Value粘贴合法JSON，并确保Headers不手动设置Content-Type；否则因multipart解析器忽略字段级子头，导致400/415错误或字段为空。
Postman form-data 中怎么传 JSON 字符串
不能直接把 {"key":"value"} 当作 text 类型字段的值塞进 form-data，否则后端收到的是未解析的字符串，且可能因引号转义、编码问题导致解析失败。必须明确告诉 Postman：这是纯文本内容，不是要参与 multipart 边界解析的结构化字段。
正确做法是：
- 在 Body → form-data 中新增一项，
Key填后端约定的字段名（如payload或data） -
Value区域粘贴合法 JSON 字符串，例如{"order_id":"ORD-123","items":[{"sku":"A001","qty":2}]} - 点击该行右侧的下拉箭头，把类型从默认的
text改为text/plain（不是application/json） - 确保 Headers 里没有手动加
Content-Type: application/json—— form-data 请求的顶层Content-Type必须是multipart/form-data; boundary=...，加错会触发 400 或 415
为什么 form-data 里选 application/json 会失败
Postman 在 form-data 模式下，若对某个字段手动设 Content-Type: application/json，它会在该字段的 MIME 头里插入额外的 Content-Type 子头。但标准 multipart 解析器（如 Spring 的 @RequestParam、Express 的 multer）只认顶层 multipart/form-data，不处理字段级子头。结果就是：JSON 字段被当成二进制 blob 或直接丢弃。
典型错误现象：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 后端日志显示字段为空或
null - 收到的 JSON 字符串开头多出类似
------WebKitFormBoundary...的边界标识 - Spring 报错
Required request parameter 'xxx' is not present，尽管字段名已存在
上传文件 + JSON 共存时的字段命名与顺序
form-data 是键值对列表，顺序不影响解析，但字段名必须和后端控制器参数严格匹配。常见组合场景有两类：
- 单文件 + 单 JSON 字符串：用
file和payload两个 key，前者类型设为File，后者设为text/plain - 多文件 + JSON 元数据：所有文件字段都用相同 key（如
files），JSON 字段单独命名（如metadata），后端需用数组接收文件、字符串接收 metadata - 避免用
json作 key 名——某些框架（如旧版 Flask-WTF）会自动尝试解析该字段，反而报错
curl 对应写法可验证逻辑：curl -F "file=@/path/to.jpg" -F "payload={\"user_id\":123}" https://api.example.com/upload
JSON 字符串本身容易出错的细节
即使格式选对了，JSON 字符串内容不合法也会让后端解析失败，而 Postman 不校验 raw text 字段里的 JSON 语法。
- 中文引号、全角冒号、结尾多余逗号：全部会导致
JSON.parse()报错 - 双引号没转义：比如值里含
"name":"O'Reilly"必须写成"O\'Reilly"或改用单引号包裹整个字符串再传（不推荐） - 建议用 json.cn 粘贴校验，或 VS Code 打开 .json 后缀文件，语法高亮会立刻标红错误位置
- 如果 JSON 里含换行或缩进，没问题 —— form-data 接收的是完整字符串，后端自行
JSON.parse()
最常被忽略的一点：后端是否真的期望 JSON 字符串？有些接口文档写“传 JSON”，实际要的是 form-data 里的多个扁平字段（如 user_name、user_email），而非一个叫 data 的 JSON 字符串字段。务必确认接口契约。
