内容摘要：POST请求的Body里到底该放什么？这问题看着基础，但十个人里有八个答不完整。我见过太多人把参数一股脑塞进URL，或者把JSON和表单格式混着用，结果对接方解析不出来，调试到凌晨三点。 先说结论：P

POST请求的发送Body里到底该放什么？这问题看着基础，但十个人里有八个答不完整。请求我见过太多人把参数一股脑塞进URL，携带或者把JSON和表单格式混着用，什参数结果对接方解析不出来，发送调试到凌晨三点。请求

先说结论：POST请求的携带参数几乎都放在请求体（Body）里，但具体怎么放，什参数取决于你告诉服务器“我发的发送是什么类型的数据”。这个类型由请求头里的请求Content-Type字段决定，它就像快递单上的携带“物品类别”标签——你写“易碎品”，快递员就知道轻拿轻放；你写“液体”，什参数安检就得单独检查。发送

最常见的请求两种类型，一种是携带application/x-www-form-urlencoded。这种格式长这样：name=张三&age=25&city=北京，键值对用&连接，中文和特殊字符会被URL编码。它适合简单结构的数据，比如登录表单、筛选条件。你提交一个搜索框，浏览器默认就发这个格式。但注意，如果你要传一个嵌套的对象或者数组，这种格式就尴尬了——你得自己把结构拍平，比如hobbies[0]=篮球&hobbies[1]=吉他，服务器解析起来麻烦，你写起来也累。

另一种是application/json。这是目前前后端分离项目的绝对主流。Body里直接放一串JSON字符串：{ "name":"张三","age":25,"address":{ "city":"北京","district":"海淀"}}。它的优势很明显——结构清晰，支持任意层级的嵌套，JavaScript里一个JSON.stringify()就能搞定。我去年接手一个老系统，接口文档写着“参数格式为form”，但实际传参里有个字段是数组，前端只能把数组转成逗号分隔的字符串，后端再split拆开，中间一旦某个值本身含逗号就出bug。后来改成JSON，问题直接消失。

还有两种不太常见但你必须知道的类型。multipart/form-data专门用来传文件，它会把每个字段和文件内容用随机生成的boundary字符串分隔开。你上传头像、导入Excel，用的都是它。注意，这种格式下Content-Type会带上boundary参数，比如multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxk，服务器靠这个边界符切分数据。另一种是纯文本text/plain，基本没人主动用，但有些老系统或者特殊协议会要求原始字符串，比如某些日志上报接口直接POST一段纯文本格式的日志内容。

有个容易踩的坑：URL里的query string和Body里的参数可以同时存在。比如POST /api/orders?source=app，query里放source用来追踪请求来源，Body里放订单详情。这不算错，但你要和前端约定清楚——哪些参数走URL，哪些走Body。我见过最混乱的代码，一个接口里同样的参数既出现在URL又出现在Body，后端取值的优先级逻辑写了好几层if-else，最后没人敢改。

还有个细节：GET请求理论上也可以带Body，但HTTP规范里没定义它的语义，很多代理服务器和网关会直接丢弃GET的Body，所以别这么干。POST的Body大小也有限制，服务器默认可能只接受1MB或10MB，传大文件得用分片或者对象存储。别等到线上报413错误才想起来查配置。

最后说个实用技巧：调试POST请求时，别光看Body里的内容，先看Content-Type对不对。我自己就犯过傻——用Postman测试接口，Body选的是JSON格式，但忘了改Header里的Content-Type，默认还是text/plain，结果后端框架解析不了，返回400。这种错误特别隐蔽，因为你在Postman界面里看着JSON是漂亮的彩色高亮，但实际发出去的报文头是错的。养成习惯，每次发请求前扫一眼Header，能省下大量排查时间。