★ FEATURED ARTICLE 如果你现在打开公司里任何一个有点年头的后台管理系统十有八九能在某个角落找到 jQuery 的$.ajax调用。就算新项目已经全面转向fetch或者 axios底层那套“页面不刷新、数据在后台悄悄往返”的机制仍然把 AJAX 这个名字焊死在每个前端工程师的知识栈里。AJAX 全称 Asynchronous JavaScript And XML听着像新技术其实是浏览器早就存在的 DOM、JavaScript、XMLHttpRequest 等能力组合出来的开发模式——名字里的 XML 现在已经很少见多数场景返回的是 JSON。它的核心价值一句话就能讲明白在用户继续操作页面的同时浏览器在后台替你发请求、收响应然后用新数据局部更新页面而不是把整页重刷一遍。这篇文章我打算把 AJAX 从原理到实操拆开来讲顺带把平时调试接口时踩过的坑、总结出的判断流程一并写出来。不管你是刚接手一个满是$.ajax的老项目还是准备用原生 JS 写一个上传功能这篇文章都能给你一套可以直接用的思路。1. 页面不刷新也能拿数据AJAX 解决的问题与那套组合拳1.1 没有 AJAX 的年代表单一提交填的东西全没了早几年做后台管理系统时最常见的交互是这种一个编辑页面用户填了十几个字段点“保存”浏览器直接跳到一个提交成功页或者把整页刷新一遍。最让人崩溃的是校验失败的情况——服务器返回一个带有错误提示的 HTML 页面上面是个表单但用户刚才辛辛苦苦填的内容浏览器不会帮你回填只能重新手敲一遍。那时候大家还不太敢用 AJAX总觉得异步请求很玄、代码难调试。但表单提交这种体验确实折磨人尤其是那种字段特别多的“客户信息编辑页”用户填到一半接个电话回来再点保存页面一刷新刚才那 20 个字段全没了。这种场景就是 AJAX 最初要解决的问题不要让每次数据交互都成为一次“整页旅行”。用 AJAX 改过之后点保存时请求在后台发出去服务器返回一小段 JSON前端判断成功后在页面上弹一个轻提示表单数据保留不动用户还能继续编辑。体验上的改善是实打实的这也是它能从 2005 年左右一直火到今天的根本原因。1.2 用订餐电话理解同步与异步“异步”这个词很劝退新手我用点外卖来类比。同步请求就像打电话订餐拨通后一直握着听筒跟老板说“我要一份红烧肉”老板说“稍等厨房正在做”然后你就举着电话干等米饭煮好了但菜没出你什么事也干不了直到老板说“菜好了”你挂电话才继续做别的。异步请求则是用外卖 App 下单你选好菜、确认订单App 把请求发给商家后你该干嘛干嘛刷视频、回消息、切到别的页面都行平台有进度更新后通知你。AJAX 默认就是这种模式——浏览器把XMLHttpRequest发出去之后并不会让页面卡住JavaScript 还能继续执行用户也还能继续操作页面直到响应回来浏览器才把消息推给事先注册好的回调函数。理解了这一点你就能明白为什么很多新手写的 AJAX 代码拿不到返回值他们用同步的思路写代码发完请求下一行立刻去读一个变量但数据还在路上当然读不到。这不是代码语法错了是异步时序没搞明白。1.3 名字里的 XML 早就退场了AJAX 其实是组合出来的模式单独看 AJAX 这个名字会以为它是某种必须下载的库或者框架。实际上它从来没发布过官方 SDK也不是某个组织制定的标准。所谓“AJAX”只是 Jesse James Garrett 在 2005 年给一种既有实践方式起的名字。组成它的零件都很普通XMLHttpRequest浏览器自带的网络请求对象、DOM 操作、JavaScript 逻辑最多再加一个 JSON 数据格式。你完全可以不引入任何第三方库用原生 JS 写出一个完整的 AJAX 请求。jQuery 的$.ajax、axios本质上都是对XMLHttpRequest或fetch的封装帮你处理了默认参数、错误提示、JSON 转换这些琐碎事。所以代码库里有没有框架都不是重点重点是当你看到请求一直 404、返回数据解析不出来时能不能直接回到最底层去排查。很多从框架入门的人遇到诡异问题就懵就是因为没看过底层的 XHR 对象到底长什么样。2. 把 XMLHttpRequest 完整走一遍请求-响应生命周期2.1 最小可用的四行代码每一行在干什么先看一段最朴素的原生 AJAX 请求var xhr new XMLHttpRequest(); xhr.open(GET, /api/user, true); xhr.send(); xhr.onreadystatechange function () { if (xhr.readyState 4 xhr.status 200) { console.log(xhr.responseText); } };就四行但每一行都有自己的职责。new XMLHttpRequest()是创建一个通信对象此时它还没有跟任何地址发生关系。接下来open()只是做配置告诉浏览器“我要往这个地址发一个 GET 请求采用异步模式”注意这个阶段并不会真正建立网络连接。第三行send()才是真正把请求发出去、同时把请求体内容塞给浏览器去传输。第四行注册回调是为了让浏览器在处理完响应后回头通知 JavaScript。很多刚接触的人会把open和send当成同一步在调试时只检查open里的 URL却发现请求根本没发出去。记住这个顺序对后面看readyState帮助很大——状态从 1 跳到 2就是从“配置完成”进入“正在发送/等待响应”的阶段。2.2 readyState 和 status最容易被搞混的两个数字readyState描述的是请求对象自己的生命周期有 5 个取值0 代表请求还没初始化1 代表已经调用open2 代表已经调用send并且响应头也收到了3 代表正在下载响应体4 代表整个请求彻底完成。而status是 HTTP 状态码比如 200 表示成功404 表示地址不存在500 表示服务器内部出错。这两个数字各管各的但经典代码总是把它们写在一起if (xhr.readyState 4 xhr.status 200) { // 正确请求完整结束且服务器明确返回成功 }我见过不少新人把readyState 4当成“成功条件”结果接口明明返回了 500代码却照样进到成功分支里处理。原因就是没搞懂readyState 4只说明响应已经回来了就像快递已经送到门口不代表包裹里装的是你买的东西。要判断成功必须同时检查 HTTP 状态码。实际开发里还可以用更顺手的事件写法xhr.onload function () { if (xhr.status 200) { console.log(xhr.responseText); } }; xhr.onerror function () { console.error(网络异常); };onload在readyState变成 4 时触发代码更简洁也少了一个嵌套判断。2.3 响应数据格式JSON、字符串还是 BOM 惹的祸请求发出后服务器返回的数据最终都会落到xhr.responseText里它本质上是字符串。如果你请求的是 JSON 接口想拿到对象就必须自己解析try { var data JSON.parse(xhr.responseText); console.log(data.name); } catch (e) { console.error(JSON 解析失败原始响应, xhr.responseText); }这个try/catch不是可有可无。一个高频翻车场景是后端接口报错时PHP 或者 Java 的服务端没有返回 JSON而是返回了一整段 HTML 错误页然后前端傻乎乎地执行JSON.parse直接抛异常你看到的就是一个“白屏 控制台红色报错”。加了try/catch并且把原始响应打出来再配合 Network 面板看响应体通常一眼就能定位。另外一个隐蔽坑是 UTF-8 的 BOM字节顺序标记。某些编辑器或者 Windows 环境的脚本会在返回内容最前面塞一个不可见字符JSON.parse看到字符串开头不是{就直接报错。这种问题靠肉眼很难发现最好让接口返回的数据不带 BOM或者在解析前用responseText.replace(/^\uFEFF/, )做一次兜底清洗。3. async: false、超时与中断异步边界上的三个真实场景3.1 async: false能用但代价比想象的大open()的第三个参数叫async如果写成false请求会变成同步模式浏览器发完请求后JavaScript 线程就停在那等响应直到数据返回才继续往下执行。表面上代码变好写了比如xhr.open(GET, /api/config, false); xhr.send(); console.log(xhr.responseText); // 这样能直接拿到结果但代价非常具体请求期间页面是冻结的用户点击按钮没反应滚动条拖不动如果接口响应要两三秒浏览器可能直接弹“脚本运行时间过长”的提示。移动端对这种卡顿更敏感网络稍有波动整页就像死机。现代浏览器规范里主线程上的同步 XHR 已经被明确标记为不推荐使用部分场景甚至直接移除支持。我自己的原则是老项目里如果没有条件大改碰到同步请求会先加超时控制新写的代码一律不用async: false宁可把逻辑挪进回调或者 Promise 里。你现在觉得回调麻烦只是因为还没养成异步思维习惯以后反而比同步写法更顺手。3.2 超时与 abort用户取消请求时回调还在跑异步请求不等于“永远不会出问题”。接口可能很慢用户可能等不及点了个“取消”或者已经跳转到别的页面。这种情况下你依然要处理请求的终态。XHR 提供了timeout、ontimeout、onabort等事件var xhr new XMLHttpRequest(); xhr.open(GET, /api/report, true); xhr.timeout 5000; // 5 秒超时 xhr.ontimeout function () { console.error(请求超时请稍后重试); }; xhr.onabort function () { console.log(请求已被取消); }; xhr.send(); // 用户点击取消按钮时 function cancelRequest() { xhr.abort(); }一个很典型的应用是搜索框的“防抖 取消旧请求”组合。用户每敲一个字符就发一次请求如果不取消上一次仍在路上的请求就会出现“先发的请求后返回把后发的正确结果覆盖掉”的乱象。我在项目里的处理方式很朴素在发新请求前先abort()掉旧的 XHR 实例并记录当前请求的标识回调里只认最新那一次的结果。3.3 并发请求的竞态后返回的旧数据覆盖了新结果竞态问题比超时更隐蔽因为它的代码不报错只是显示内容跟用户操作对不上。还是搜索场景用户先输入“北”发出请求 A再输入“北京”发出请求 B。正常情况下 B 后发后回页面显示“北京”的结果。但如果 A 响应特别慢B 反而先返回页面先显示“北京”紧接着 A 返回又把页面覆盖成了“北”的旧结果。对付竞态有两条思路。简单粗暴的是“只保留最后一个请求”发新请求前abort旧的和上面搜索框的做法一样。另一种是用请求序号做守卫var requestSeq 0; input.addEventListener(input, function () { var current requestSeq; xhr.onload function () { if (current ! requestSeq) return; // 已经有更新的请求丢弃本次结果 renderResult(xhr.responseText); }; });这种方式在没办法abort旧请求的场景比如同时要展示两个请求结果特别有用。除此之外我还习惯给“保存”“提交”这类按钮加请求锁提交期间把按钮设为disabled防止用户连点触发两次下单这也是重复提交问题的根源解法。4. 参数赋值、Content-Type 与中文编码请求数据格式实操4.1 GET 和 POST 的参数到底应该怎么拼GET 请求的参数要拼在 URL 查询串上POST 请求的参数要放在send()里。看起来简单但拼参数的姿势很有讲究。最容易踩的坑是用手写字符串拼接// 这样拼很容易出问题 xhr.open(GET, /api/user?name name age age);如果name里含有、、空格或者中文URL 格式会被破坏。正确做法是用encodeURIComponent对每个键值对单独编码function buildQuery(params) { return Object.keys(params) .map(function (key) { return encodeURIComponent(key) encodeURIComponent(params[key]); }) .join(); } xhr.open(GET, /api/user? buildQuery({ name: 张三, age: 18 }));POST 请求同理不要直接往send()里塞一个原始对象var data new URLSearchParams(); data.append(name, 张三); data.append(age, 18); xhr.send(data.toString());URLSearchParams会把键值对按 URL 编码规则处理好中文、特殊符号都不用手动转。这也是我后来统一推荐给团队的方式避免每个人各写一套转义逻辑。4.2 Content-Type 三选一表单、文件、JSON 各自的门道请求体内容的“格式声明”就是Content-Type请求头。前后端能不能正确拿到数据往往就取决于这个头有没有配对。场景Content-Type请求体示例后端典型接收方式普通表单字段application/x-www-form-urlencodedname张三age18PHP 的$_POST文件上传multipart/form-data由浏览器自动生成带 boundaryPHP 的$_FILES结构复杂的数据application/json{name:张三,age:18}php://input读原始流新手最常见的错误是后端接口约定要 JSON 数据前端却在send()里传了一个 URL 编码格式的字符串也没设置请求头结果后端$_POST拿不到任何值。反过来也有后端代码按$_POST解析前端却发 JSON 字符串同样拿不到。设置请求头的方式是xhr.open(POST, /api/user/save, true); xhr.setRequestHeader(Content-Type, application/json;charsetUTF-8); xhr.send(JSON.stringify({ name: 张三, age: 18 }));这里JSON.stringify也是必需的因为send()的入参必须是字符串或二进制对象不能直接塞一个 JSON 对象。4.3 中文乱码的排查链路先从哪一头查起中文乱码问题在 AJAX 请求里有三个常见层级我按排查顺序写出来。第一层是请求阶段的乱码。POST 数据如果没做 URL 编码或者页面编码、接口声明的字符集跟后端不一致服务端收到的可能是一堆%E5%BC%A0%E4%B8%89或者问号。排查方法是先用Network面板看请求的Payload确认发出的时候是什么样再让后端把接收到的原始字节打出来对比是传输过程出问题还是前端一开始就没编码对。第二层是响应阶段的乱码。服务器返回的 JSON 里中文变成乱码多半是响应头Content-Type没带charsetutf-8或者数据库连接字符集不是 UTF-8。前者可以在 PHP 里明确设置header(Content-Type: application/json; charsetutf-8);后者属于后端问题前端再怎么改也没用。第三层是数据源本身坏了。比如数据库表用的字符集是latin1库里存的中文已经不可逆这种情况下响应头、页面声明全对前端拿到的仍然是一串乱码。遇到这种情况不要在前端浪费时间直接让后端同事查数据库建表语句和连接配置。我自己处理乱码问题时的最大体会是先确定乱码发生在“传输前”还是“传输后”能少做一半无用功。5. PHP 后端对接识别 AJAX、返回 JSON、接收 FormData5.1 PHP 怎么知道这次请求是 AJAX 发来的很多时候后端需要区分“普通表单提交”和“AJAX 请求”以便返回不同的响应格式。PHP 里没有专门区分 AJAX 的内置变量但大多数前端框架会默认带上一个请求头X-Requested-With: XMLHttpRequestPHP 端可以这样判断$isAjax isset($_SERVER[HTTP_X_REQUESTED_WITH]) strtolower($_SERVER[HTTP_X_REQUESTED_WITH]) xmlhttprequest;注意一个细节原生 XHR 默认不会带这个请求头是 jQuery、axios 这类库自动帮你加的。如果你用原生 XHR 请求 PHP 接口又想走“是 AJAX 就返回 JSON”的分支要么手动加这个头xhr.setRequestHeader(X-Requested-With, XMLHttpRequest);要么干脆让后端不依赖这个头而是根据Content-Type或者某个自定义参数来判断。否则你会遇到一种很困惑的情况同一个接口用 jQuery 调没事换成原生 JS 调就变成了整页 HTML 返回。5.2 返回 JSON 的三件事少一件前端都会很难受PHP 后端返回 JSON看起来就一行echo json_encode($data)但要让前端稳定解析必须同时做好三件事。第一件事是设置响应头header(Content-Type: application/json; charsetutf-8);不设置的话浏览器可能把返回内容当成 HTML 文本显示上没问题但审计请求时容易一头雾水。第二件事是正确编码echo json_encode($data, JSON_UNESCAPED_UNICODE);JSON_UNESCAPED_UNICODE可以让中文以原样输出而不是转成\u5f20\u4e09这种 ASCII 转义形式。两者都能被前端解析但前者在 Network 面板里检查数据更直观。第三件事也是我踩坑最深的一件不要在 JSON 输出前后夹带任何多余内容。PHP 文件如果开头有空格、结束标签?后面多了个空行或者执行过程中有一个warning输出这些都会混进响应体导致前端JSON.parse报错。调试时看到“Unexpected token in JSON”这类报错十有八九就是响应体开头被 HTML 或空白污染了。我的建议是接口文件里不要写结束标签业务代码别用echo输出调试信息调试信息一律写日志文件。5.3 FormData 文件上传真正容易翻车的细节用 AJAX 做文件上传FormData是最省事的方案var fd new FormData(); fd.append(file, fileInput.files[0]); fd.append(title, 我的照片); var xhr new XMLHttpRequest(); xhr.open(POST, /upload.php, true); // 重点这里不要手动 setRequestHeader(Content-Type, multipart/form-data) xhr.send(fd);很多人在这一步栽跟头看到请求要带文件就习惯性地手动设置Content-Type为multipart/form-data。问题在于multipart/form-data的请求体需要一个随机生成的boundary分隔符如果你手动设置请求头就等于把这个分隔符信息覆盖掉了后端 PHP 拿到文件字段时常常解析不完整$_FILES[file]直接为空。正确做法是把FormData对象直接传给send()浏览器会自动生成带boundary的完整Content-Type。PHP 端接收仍然很常规$fileInfo $_FILES[file] ?? null; $title $_POST[title] ?? ;如果还想给用户显示上传进度XHR 也支持xhr.upload.onprogress function (event) { if (event.lengthComputable) { var percent Math.round((event.loaded / event.total) * 100); document.getElementById(bar).style.width percent %; } };这个能力在fetch里反而不太方便是我在老项目里继续依赖 XHR 的重要原因之一。6. 调试三板斧与高频避坑Network、缓存与重复提交6.1 打开 Network 面板按这个顺序看信息很多人调试 AJAX 只会看console里的报错但前端报错信息往往是被包装后的真正的问题要打开开发者工具的Network面板才看得清。我自己的排查顺序固定如下先看请求是否真的发出Network 里有没有这一条记录再看请求头和方法是否跟接口文档一致接着看响应状态码最后才是看响应体内容。如果请求状态是 404优先检查 URL 地址有没有拼错大概率是路径问题如果是 500那就是服务器代码运行到一半出错了需要看后端日志如果是 200 但前端拿不到数据才轮到 JSON 解析问题。这个优先级能砍掉大量无效排查时间。日常开发时我还会用 PHP 内置服务器起一个临时接口来配合调试php -S 127.0.0.1:8080只要在项目根目录写一个简单的index.php返回一段 JSON前端就能拿它做联调。很多接口问题其实不需要完整项目环境自己动手搭一个最小复现场景比在庞大的老系统里翻来翻去高效得多。6.2 缓存、重复提交、返回值错位三个高频线上问题第一个高频问题是 GET 请求被浏览器缓存。同一时刻请求同一个 URL第二次可能直接命中浏览器缓存服务器根本没收到请求于是页面上显示的是旧数据。破解手段很常见给 URL 加一个随机参数xhr.open(GET, /api/list?t Date.now(), true);这个t参数不参与业务逻辑只是为了打破缓存。更规范的做法是后端在响应头里加上Cache-Control: no-store但在临时接口或者没法改后端的情况下时间戳方案永远有效。第二个问题是重复提交。用户快速双击“保存”前端发了两个一模一样的 POST数据库里就多了两条同内容记录。解决思路有两层一是 UI 层在请求期间把保存按钮置灰二是后端做幂等校验根据某个业务唯一键判断是否已经保存过。前端的那层锁虽然基础但确实能挡住绝大多数误操作我强烈建议每个表单页都加上。第三个问题是返回值错位表现是请求状态码是 200但responseText里是一段 HTML。原因通常是后端在处理 AJAX 请求时发生了跳转或异常最终返回了登录页或 404 页面。碰到这种问题一定要先在 Network 面板里看响应体本身而不是盯着控制台的报错。很多前端同学会陷入“为什么 JSON.parse 老报错”的死循环其实只要看一眼响应体答案马上就出来了。6.3 Fetch 会取代 AJAX 吗我的选型判断前面讲的都是 XHR该说说它的现代替代品fetch了。fetch基于 Promise写起来更简洁fetch(/api/user) .then(function (res) { if (!res.ok) throw new Error(HTTP res.status); return res.json(); }) .then(function (data) { console.log(data); }) .catch(function (err) { console.error(err); });但它和 XHR 有几个关键差异选型时必须搞清楚。第一fetch默认不把跨域请求的 Cookie 带上需要显式加credentials: include第二HTTP 404、500 并不会让 Promisereject必须自己检查response.ok第三上传进度事件没有原生方案想显示进度条反而要另想办法。相比之下XHR 事件体系虽然旧但功能相当完整连取消请求都有原生abort在文件上传、轮询这类场景里反而更顺手。所以我的建议不是“无脑拥抱 fetch”而是看场景。新项目简单接口用fetch会很清爽老项目里已经成熟使用的 XHR 封装没必要为了新技术重写一遍。无论用哪种前面提到的异步时序、参数编码、响应格式判断这些底层认知完全通用。做前端这几年我自己最大的感受是AJAX 的门槛从来不在 API 调用而在“异步思考”。当你真正理解了请求发出去之后代码还会继续跑、结果会在某个未知时刻回来这个节奏再学 Promise、async/await、axios 拦截器全都是顺理成章的事。遇到接口问题也先别急着怀疑框架回到 XMLHttpRequest 的请求链路上把每一步看一遍答案往往就在那里。
阅读完成 · 觉得有帮助？
