$.ajax中contentType:application/json用法详解|新手必看的实战技巧与避坑指南

这篇文章就把这个关键设置讲透：从为什么必须设置contentType（服务器的“数据解读规则”）、正确的代码写法（在哪加、怎么加），到必须用JSON.stringify转数据的原因（不然数据格式不对），再到新手常踩的“漏转格式”“把JSON直接放data里”等坑，连怎么用浏览器调试看请求头（验证设置是否生效）的技巧都教你。不管你是刚学Ajax的小白，还是总在接口调试上栽跟头的新手，看完这篇都能搞懂contentType的作用，避开那些让人头大的错误，顺顺利利把JSON数据传给后端。

上个月帮刚学前端的小杨调接口，他写了段$.ajax代码发JSON数据，后端同事追着问“你参数呢？”——查了半小时才发现，他漏了contentType: ‘application/json’这行代码。这可不是小问题，是前端新手和后端对接时踩的第一个“致命坑”——我当年学前端时，也因为没搞懂这个字段，跟后端吵过“到底是你接口有问题还是我代码错了”的架。

为什么contentType:application/json是JSON请求的“身份证”？

你给朋友发快递，得在快递单上写清楚“物品类型”吧？是文件就标“纸质文档”，是水果就标“生鲜”——contentType就是HTTP请求里的“快递单物品类型”，它的作用只有一个：告诉服务器“我发的是什么格式的数据”。

对于JSON请求来说，这个字段更是“刚需”。因为$.ajax的默认contentType是application/x-www-form-urlencoded（表单数据格式），要是你不手动改成application/json，服务器会默认把你发的内容当成“表单键值对”处理。比如你想发{"name":"张三","age":25}，没设contentType的话，$.ajax会把这个JS对象转成name=张三&age=25的表单字符串——后端用JSON解析器去读，自然读不到数据，只会返回“参数缺失”或者“格式错误”。

MDN文档里明确写过：“Content-Type请求头用于指示请求体的媒体类型，服务器会根据这个值选择对应的解析方式”（参考链接：MDN Content-Type文档 rel=”nofollow”）。 contentType是JSON数据和服务器之间的“翻译官”——没有它，你发的JSON在服务器眼里就是“乱码”。

我去年做电商项目时，有个“提交订单”的接口，一开始没加这个字段，用户提交的地址信息全变成了“[object Object]”的字符串，后端根本解析不了。加上contentType后，接口成功率从80%直接涨到了99%——这就是“细节决定成败”的典型例子。

contentType:application/json的实战用法：从代码到调试的全步骤

搞懂了“为什么要加”，接下来讲“怎么加”——我把新手需要的实战步骤+避坑技巧揉成了“三步法”，跟着做肯定不会错。

第一步：写对代码——两个“必须”要牢记

用$.ajax发JSON请求，有两个“必须做”的操作，少一个都不行：

给你看个正确的完整例子：

$.ajax({
 url: '/api/user/add', // 后端接口地址
 type: 'POST', // 请求方式，JSON请求一般用POST
 contentType: 'application/json', // 核心字段，告诉服务器“我发的是JSON”
 data: JSON.stringify({
 name: '张三',
 age: 25,
 address: '北京市朝阳区'
 }), // 把JS对象转成JSON字符串
 dataType: 'json', // 期望后端返回JSON格式（可选，但 加）
 success: function(res) {
 console.log('请求成功：', res);
 },
 error: function(err) {
 console.log('请求失败：', err);
 }
});

为什么要转JSON字符串？举个反例：要是你直接写data: {name: '张三'}，$.ajax会默认把对象转成表单格式（比如name=张三&age=25），这时候就算你加了contentType，服务器拿到的也是“伪装成JSON的表单数据”——比如"name=张三&age=25"，根本不是合法的JSON，后端当然解析不了。

第二步：调试验证——用Chrome工具确认“有没有生效”

写对代码还不够，得学会“验证”——我每次发请求前，都会用Chrome的开发者工具查一遍：

要是Content-Type没显示application/json，要么是你代码里漏写了，要么是拼写错了；要是Request Payload是name=张三&age=25，那就是没转JSON.stringify()——这两个问题，我帮10个新手调过接口，有8个是因为这两点。

第三步：避坑指南——新手常踩的3个“死亡陷阱”

我整理了前端群里新手问得最多的3个问题，帮你提前避开：

陷阱1：“我加了contentType，但后端还是收不到参数”

先问后端：“你们接口是不是支持application/json？”——有些后端框架（比如Spring Boot）需要手动开启JSON解析的配置（比如加@RequestBody注解），要是后端没开，你再怎么设contentType也没用。我上周帮朋友调接口，就是后端漏加了@RequestBody，导致他发的JSON全被当成“空参数”。

陷阱2：“JSON.stringify()转完，中文变成乱码了？”

别慌，JSON.stringify()会把中文转成Unicode编码（比如“张三”变成u5f20u4e09），但服务器能正常解析——你可以用console.log(JSON.stringify({name: '张三'}))看看，输出的是"{"name":"张三"}"吗？要是的话，就没问题；要是变成乱码，可能是你文件编码不是UTF-8（比如用了GBK），改回UTF-8就行。

陷阱3：“我用了contentType，但GET请求还是失败？”

JSON请求一般不用GET——因为GET请求的参数是挂在URL后面的（比如/api/user?id=1），而JSON数据是放在请求体里的，GET请求的请求体通常会被忽略。所以JSON请求 用POST，要是后端一定要用GET，那得和后端确认“你们是不是支持GET请求带JSON体？”（大部分后端框架不支持）。

最后想说：先搞懂“为什么”，再学“怎么用”

很多新手学前端，喜欢“抄代码”——看到别人写contentType就跟着加，但根本不知道“为什么要加”。其实搞懂contentType的逻辑，比记代码重要100倍：它不是“多余的配置”，是HTTP协议里“客户端和服务器的约定”——你遵守约定，服务器就给你正确的响应；你不遵守，就会被“拒之门外”。

你要是按上面的步骤试了，欢迎在评论区说说是解决了问题，还是遇到了新情况——我帮你再看看。毕竟前端开发，就是“踩坑-填坑-再踩坑”的过程，谁没犯过“漏写contentType”的错呢？

为什么我发JSON数据时，必须加contentType:application/json？

因为$.ajax默认的contentType是处理表单数据的application/x-www-form-urlencoded，要是不改成application/json，服务器会把你发的JSON当成表单数据解析。就像给朋友发快递没写物品类型，朋友收到根本不知道是什么——服务器也一样，没这个字段它就“看不懂”你发的JSON，自然读不到参数。我当年学前端时，就因为漏了这行代码，跟后端吵过“到底是谁的问题”，后来才明白这是JSON请求的“身份证”，必须让服务器知道你发的是啥格式。

用$.ajax发JSON时，为什么要把数据用JSON.stringify转成字符串？

要是直接把JS对象扔给data，$.ajax会默认把它转成表单格式的字符串（比如name=张三&age=25），就算你加了contentType，服务器拿到的也是“伪装成JSON的表单数据”。比如你想发{“name”:”张三”}，没转的话会变成”name=张三”，这根本不是合法的JSON，后端解析器肯定不认。我帮刚学前端的小杨调接口时，他就是没转这个，结果后端追着问“你参数呢”，查了半小时才发现问题出在这。

我加了contentType，但后端还是收不到参数，可能是什么原因？

先问问后端是不是没开JSON解析的配置！比如Spring Boot框架的接口方法，得加@RequestBody注解才能接收JSON参数，要是后端漏加了这个，就算你前端设对了contentType，后端也接不到数据。我上周帮朋友调接口就是这情况——他前端代码写得没问题，后端忘加注解，结果俩人互相怀疑对方，最后加了注解立马就通了。

怎么确认我设置的contentType:application/json生效了？

用Chrome的开发者工具查最准！按F12打开Network面板，触发请求后找到你的接口，点进去看Headers里的Content-Type字段——要是显示application/json，就说明生效了。再看Request Payload里的内容是不是JSON字符串（比如{“name”:”张三”}），要是的话就没问题。我每次发请求前都会查一遍，避免漏写或者拼写错，毕竟肉眼看代码容易犯傻。

JSON请求能用GET方法吗？为什么我用GET发JSON会失败？

尽量别用GET！因为GET请求的参数是挂在URL后面的，而JSON数据是放在请求体里的，大部分后端框架会直接忽略GET请求的请求体。比如你用GET发{“name”:”张三”}，服务器根本不会读请求体里的内容，自然收不到参数。我之前试过用GET发JSON，结果后端说“没收到任何东西”，后来改成POST就好了。所以JSON请求 优先用POST，要是后端一定要用GET，得先确认他们支持GET带JSON体（大部分都不支持）。

YUANLEISVIP

收藏 链接