jQuery的ajax，说白了就是一个封装好的XMLHttpRequest。但你真以为它只是省了几行代码？那就太小看它了。

2012年我接了个外包项目，客户要求做一个实时搜索功能。那时候我刚接触前端，用原生XHR写，光处理浏览器兼容就写了三十多行。IE6的ActiveXObject、IE7+的XMLHttpRequest、还有各种状态码判断——代码丑得我自己都不想看第二遍。后来换成$.ajax()，整个请求逻辑压缩到十行以内。那种感觉，就像从手动挡换成了自动挡。

真正让jQuery ajax封神的，是它对JSONP和跨域的处理。那时候CORS还没普及，前端想调第三方接口，只能靠动态插入<script>标签。jQuery把这个过程包装成了$.ajax({ dataType:'jsonp'})，你只需要写一个回调函数名，剩下的事它全包了。我记得当时调百度地图API，一行$.getJSON就能拿到数据，简直像变魔术。

但别急着吹它。jQuery ajax有个臭名昭著的坑——回调地狱。嵌套三层以上的success，代码基本就没法维护了。我在一个后台管理系统里见过七层嵌套的ajax，缩进像盘山公路。那时候还没有Promise，更别提async/await。你只能靠deferred对象硬撑，但写起来还是别扭。

还有个细节，jQuery ajax默认会把data自动转成查询字符串。这本身没问题，但如果你传的是嵌套对象，比如{ user:{ name:'张三'}}，它序列化出来是user[name]=张三，后端用Spring MVC接的时候直接懵了——字段名带中括号，解析规则全乱套。我为此加了无数个traditional:true，才把数组序列化成user[]=1&user[]=2这种老派格式。

性能上它也不算最优。每次请求都会重新创建XHR对象，如果页面里有几十个并发请求，内存占用肉眼可见地涨。后来用fetch对比过，同样请求量，fetch的内存曲线平稳得多。但fetch也有自己的毛病——默认不带cookie，要手动加credentials:'include'。这反而说明jQuery ajax对老浏览器的兼容性处理，确实做到了极致。

现在项目里已经很少直接写$.ajax了。axios成了新宠，拦截器、取消请求、自动转换JSON，这些功能jQuery都没跟上。但你不能否认，正是jQuery ajax把“异步请求”这个概念普及给了中国第一批前端开发者。那时候网上教程清一色是$.post(url, data, function(res){ ...})，多少人的第一个接口就是靠它调通的。

换个角度想，jQuery ajax其实是个历史产物。它解决的问题——浏览器差异、跨域、序列化——在今天看来大部分已经被原生API或新框架解决了。但它的设计思路影响了后来所有HTTP库：统一入口、链式调用、回调约定。哪怕现在你用axios，本质上还是在跟同一个抽象层打交道。

所以别纠结要不要再用它。如果项目是维护老系统，继续用没问题，稳定压倒一切。如果新项目，直接上fetch或axios，少背点历史包袱。工具会过时，但解决问题的思路不会——这才是jQuery ajax留给我们的真正遗产。