Postman请求体四类区别与Content-Type选择

脚本专家

在 Postman 调试 HTTP 接口时，Body 类型的选择会直接影响请求体编码方式和 Content-Type，也决定服务端能否正确解析参数或文件。form-data、x-www-form-urlencoded、raw、binary 是最常用的四种 Body 类型，下面按数据结构、Content-Type、适用场景和排查要点进行整理。

一、form-data：multipart/form-data
form-data 对应 HTTP 请求中的 multipart/form-data。它会把表单数据处理为一条消息，以标签为单元，用分隔符分开。由于有 boundary 隔离，multipart/form-data 既可以上传键值对，也可以上传文件，并且可以采用键值对方式上传多个文件。

当上传字段是文件时，会有 Content-Type 用来标明文件类型；Content-Disposition 用来说明字段的一些信息。form-data 适合表单字段与文件混合提交、多文件上传等场景。

2. Content-Type: multipart/form-data

复制代码

二、x-www-form-urlencoded：application/x-www-form-urlencoded
x-www-form-urlencoded 对应 application/x-www-form-urlencoded，会把表单内的数据转换为键值对，例如 name=java&age=23。它只能上传键值对，键值对之间按示例形式间隔拼接。

2. Content-Type: application/x-www-form-urlencoded
3. name=java&age=23

复制代码

这种类型适合普通表单提交、不包含文件的参数传递，以及服务端明确按 urlencoded 方式解析请求体的接口。

三、raw：任意文本内容
raw 可以上传任意格式的文本，可以上传 text、json、xml、html 等。它适合需要原样发送文本载荷的接口，例如 JSON、XML、HTML 或普通文本请求体。需要注意，raw 面向文本内容，不是文件二进制上传方式。

四、binary：application/octet-stream
binary 相当于 Content-Type: application/octet-stream，从字面意思可知，只可以上传二进制数据，通常用来上传文件。由于没有键值，所以一次只能上传一个文件。

2. Content-Type: application/octet-stream

复制代码

它适合单个文件流上传，或服务端直接读取请求体二进制的场景。

五、multipart/form-data 与 x-www-form-urlencoded 的区别
multipart/form-data 既可以上传文件等二进制数据，也可以上传表单键值对，只是最后会转化为一条信息；x-www-form-urlencoded 只能上传键值对，并且键值对都是间隔分开的。

实际调试时，可以先看接口文档要求的 Content-Type 和请求体格式，再选择 Postman 中对应的 Body 类型。如果服务端收不到参数，优先核对 Content-Type 与请求体结构是否匹配：文件上传不要用 x-www-form-urlencoded；需要 JSON、XML、HTML 等文本时选 raw；单文件二进制流选 binary；多文件或键值与文件混合提交选 form-data。binary 没有键值，不能像 form-data 那样携带多个文件或键值对，这也是选择类型时需要特别注意的兼容性细节。

热心网友4

整理得很清楚，四类 Body 和 Content-Type 的对应关系说得很明白，尤其是 form-data 靠 boundary 同时带键值和文件、binary 没有键值只能单文件这两点，确实容易混。我之前调图片上传接口，用 x-www-form-urlencoded 传文件，服务端一直说参数为空，后来换成 form-data 选 File 类型才通；还有一次 raw 里写了 JSON，结果右边格式没切到 JSON，Content-Type 没对上，接口也解析不了。按楼主最后说的排查思路，先看文档要求的 Content-Type，再决定选哪类 Body，能少走不少弯路。想再确认一下，raw 选 JSON 时 Postman 会自动加上 Content-Type: application/json 吧，这跟手动在 Headers 里写有区别吗？另外多文件场景下 binary 的限制提醒得很到位。感谢分享。

热心网友4

这篇整理得很清楚，尤其是把 Content-Type 和请求体结构对应起来这一点，平时调试接口最容易在这里出问题。 我自己比较有体会的是 raw 和 binary 的区分。以前以为 raw 什么都能放，结果传文件就出问题，后来才明白 raw 是文本载荷，文件流得上 binary。另外 binary 没有键值对，一次只能传一个文件，需要多个字段或者多文件时就得换 form-data，这个细节确实容易忽略。 还有 form-data 和 x-www-form-urlencoded 的对比也很实用：一个能混合文件和键值对，另一个只能放键值对，报错时先检查服务端是按哪种方式解析的，基本能定位大半问题。最后的排查顺序也值得记一下：先看接口文档要求的 Content-Type，再决定 Body 类型；收不到参数时优先核对两者是否匹配。感谢整理，收藏备查。

热心网友4

这篇整理得很清楚，把四种 Body 类型和 Content-Type 的对应关系一次讲透了，尤其适合调试接口时对照着选。我自己平时最容易踩的坑就是 raw 和 binary 混用：想传 JSON 文本结果选了 binary，服务端解析不到；或者单文件流上传却用了 form-data，参数结构对不上。按楼主说的先看接口文档要求的 Content-Type，再倒推 Body 类型，确实能少走很多弯路。另外 form-data 的 boundary 是 Postman 自动生成的，一般不用手动处理，但排查时留意一下请求头里有没有带 boundary 也有帮助。最后那段“服务端收不到参数优先核对 Content-Type 与请求体结构是否匹配”总结得很实用，收藏了。