东予薏米最近一个做后端的小伙伴跑过来问我：“为什么我用 AJAX 请求，服务端收到的中文永远是一堆乱码？”我一看代码就明白了，他把数据放在 URL 后面直接拼，然后提交编码也没设置，服务端那边又是默认按 ISO-8859-1 解。这个问题看起来很小，但牵扯到 AJAX 请求的编码格式、参数赋值方式、Content-Type 设置，实际上是一整块知识。类似的疑问我几乎每年都能遇到几回，所以决定系统整理一篇以“AJAX 实例”为主线的内容，把从底层原理到真实项目里最常见的写法、问题和排查技巧都摊开来聊一遍。
这篇文章适合刚接触前后端交互的前端新人，也适合后端工程师想快速搞懂 AJAX 请求什么时候该用什么格式传参，还适合团队里维护老项目、需要处理拖了很久的 ajax 兼容问题的同学。我会从 XMLHttpRequest 讲到 fetch，从 GET 讲到 POST，从表单编码讲到 application/json，再到 Layui 这类框架里的封装怎么用，最后把编码、参数丢失、状态码、乱码这些“高频翻车现场”逐个拆开。
1. AJAX到底在做什么：一次请求的完整“旅行”
1.1 没有AJAX的年代，网页是怎么运作的
要理解 AJAX 到底解决了什么问题，可以先把时间往回拨一下。在 AJAX 这个概念还没普及的年代，网页要往服务器提交数据，最常见的方式就是提交一个表单。浏览器拿到表单数据以后，会发起一次完整的页面请求，服务器处理完再返回一个新的 HTML 页面，然后整个浏览器窗口从头刷新一遍。哪怕你只是想给文章点一个赞、更新一下购物车里的数量，页面也要整个跳转一次，体验上又慢又不连贯。
AJAX 的全称是 Asynchronous JavaScript And XML，翻译过来就是“异步 JavaScript 和 XML”。它的核心思路是让浏览器在后台偷偷发一个请求到服务器，服务器返回的数据到了以后，JavaScript 再把页面上的某一块内容动态更新掉。整个过程中页面不刷新，用户不需要等白屏，体验是连续的。现在几乎所有网站都在用这套交互方式，尤其是 SPA 应用，整个站点可能只有一份 HTML，剩下的内容全部靠 AJAX 请求数据然后通过 DOM 操作渲染出来。
很多同学会把 AJAX 当作一个具体的库或者某种框架，实际上它只是“浏览器提供的一整套异步网络请求能力”的总称。真正干活的对象，是浏览器环境里的 XMLHttpRequest 对象，或者后来出现的 fetch API。你用 jQuery 的 $.ajax、axios、Layui 的 $.get，底层走的还是浏览器这些原生能力，只是有些人帮你把代码封装得更简短了。
1.2 数据流转链路：请求、响应、DOM 与数据格式
我们在页面上最常见的 AJAX 流程可以拆成五个环节。第一步，JavaScript 代码里创建一个请求对象。第二步，通过请求对象把请求发到指定的 URL 地址，同时可以带上一些参数，参数会被放进 URL 查询字符串里，也可以放到请求体里。第三步，服务器收到请求以后，根据自己的业务逻辑去查数据库、调接口或者做计算，然后返回一段响应内容。第四步，浏览器收到这段响应内容，把它交给 JavaScript 代码处理。第五步，JavaScript 将处理后的数据通过 DOM API 插入到页面上。
在整个闭环里，数据的格式非常关键。最常见的返回数据是 JSON 字符串，形式长得像 JavaScript 对象，但它本质上是一段纯文本，需要用 JSON.parse 转成真正的对象才能用。早期 XML 也曾是 AJAX 返回数据的流行格式，所以 AJAX 这个名称里才会带上 XML 这个单词。直到今天，仍然有一些老系统的接口返回的是 XML 片段，这种场景下前端就需要用 DOMParser 去解析 XML，把里面的节点内容提取出来再使用。同时返回数据也有可能是纯文本、HTML 片段甚至二进制文件流，不同 Content-Type 决定了解析方式的不同。
可以把整条链路想象成一个外卖流程。你（JavaScript）在手机 App 上点了餐，这个动作类似于创建 XMLHttpRequest 对象并发起请求；餐厅（服务器）收到订单后开始做菜，这就是服务端处理业务；骑手把餐送到你手上，类似于响应内容通过网络回到浏览器。外卖盒里的饭菜是 JSON、XML 还是 HTML，直接决定你要用筷子还是勺子把它夹出来，前端代码到底该用哪种方式解析，也得看服务器返回的 Content-Type 是什么。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. AJAX工具选型解析：自己写还是用封装好的轮子
2.1 原生XMLHttpRequest：最底层的“老熟人”
讲 AJAX 实例，绕不开最底层的 XMLHttpRequest 对象。固然现在有了 fetch，写法上更简洁了，但大量历史项目、各种框架的底层封装，都直接建立在 XMLHttpRequest 之上。老规矩先看一段最原始的 GET 请求长什么样。
javascript复制var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.example.com/users?page=1', true);
xhr.onreadystatechange = function () {
if (xhr.readyState === 4 && xhr.status === 200) {
var data = JSON.parse(xhr.responseText);
console.log(data);
}
};
xhr.send();
这段代码里有几个关键点必须说清楚。xhr.open 的第三个参数是 async，表示是否异步执行。当这个参数为 true 时，代码不会卡在 send 这一行等服务器返回数据，而是通过事件回调来处理结果。这里还要理解 readyState 这个状态值，它一共有 5 个状态：0 表示请求未初始化，open 还没调用；1 表示服务器连接已建立，open 已调用；2 表示请求已接收，send 已调用且头信息可用；3 表示请求处理中，响应体正在下载；4 表示请求已完成，响应内容已经可以使用了。
很多初学者容易犯的错误，是在 xhr.send() 之后立刻去读 responseText，结果取到的是空值。因为请求是异步的，代码发送请求后不会乖乖等在那，浏览器会在后台继续执行网络请求，当服务器把完整响应返回以后，才通过 onreadystatechange 回调通知你的代码。判断请求成功的标准是两个条件同时满足：readyState 等于 4，同时 status 等于 200。status 对应 HTTP 状态码，200 代表 OK，404 代表资源找不到，500 代表服务端内部错误，只有当状态码是 2xx 范围时，才真正适合继续往下处理数据。
2.2 fetch：原生API的新选择
fetch 是 ES6 时期开始普及的原生 API，它和 XMLHttpRequest 最大的区别在于，fetch 基于 Promise，写起来更像是“先请求、再处理、再渲染”的顺序结构，没有那么多事件回调，代码更清爽。一个 fetch GET 请求长这样。
javascript复制fetch('https://api.example.com/users?page=1')
.then(function (response) {
return response.json();
})
.then(function (result) {
console.log(result);
})
.catch(function (err) {
console.error('请求出错', err);
});
有人看到这里会说，那以后统一用 fetch 不就好了，为什么老项目还在用 XMLHttpRequest？因为 fetch 有两个实际问题需要特判。第一个，fetch 只有在网络连接真正出现错误时，比如断网、域名解析失败，Promise 才会被 reject；如果服务器返回一个 404 或者 500，fetch 仍然会正常走 then，此时需要手动判断 response.ok 或者 response.status 是不是 2xx，然后再决定要不要报错。第二个，fetch 默认情况下不会携带 Cookie 跨域，如果需要把 Cookie 一起带过去，必须显式指定 credentials: 'include'，而 XMLHttpRequest 的同源请求默认会携带 Cookie。
所以我个人的习惯是，新项目里能用 fetch 就用 fetch，代码体量小、语义清晰；但是遇到需要上传文件并且要监听上传进度这种场景，XMLHttpRequest 的 upload.onprogress 事件仍然比 fetch 的实现要顺畅得多，fetch 在上传进度的支持上目前仍然不如 XHR 完善。做技术选型时，不是越新越好，而是看当前场景里哪一个更顺手。
2.3 jQuery、axios与Layui封装：到底该怎么选
真实项目里，很多情况下你又不需要直接面对原生 XHR 或者 fetch，而是会用第三方的封装库。jQuery 的 $.ajax、$.get、$.post 是老项目的重灾区，也是老前端最熟悉的 API。axios 是现在 Vue 和 React 项目里非常流行的请求库，它的特点是同时支持浏览器和 Node.js，拦截器机制也很强大，可以统一在请求发出前或者响应回来后做二次处理，比如自动加上 Token，或者统一把业务错误码弹出来。
Layui 是一个国产 UI 组件库，它在很多后台管理系统中用得很多，特点是自带一套模块化机制，内置的常用模块里也包含网络请求的封装。如果你用的是 Layui 2.x，那么请求可以这样发。
javascript复制layui.use(['jquery', 'layer'], function () {
var $ = layui.jquery;
var layer = layui.layer;
$.get('/api/user/detail', { id: 1001 }, function (res) {
if (res.code === 0) {
layer.msg(res.data.name);
}
}, 'json');
});
这里要特别提醒一下，Layui 内部自带了一个精简版的 jQuery，如果你在页面里另外引入了一个独立 jQuery，两者混用会导致事件绑定或者全局变量互相干扰。这就是为什么代码里要写成 var $ = layui.jquery，而不是在外面直接用 $，因为 Layui 模块内的 $ 才是它自己管理的那一份。很多人看到“layui ajax get”的例子，觉得无非就是把 $.get 套了一层，实际上真正容易踩坑的点在于它的 data 类型和回调数据格式约定，同一个后端接口一边返回 {code: 0, data: ...}，一边返回 {status: true, result: ...}，处理逻辑就完全不一样，这跟封装库本身没关系，而是前后端人员接口约定不清导致的。
3. 实例一：GET请求怎么写、参数怎么传
3.1 从一次点赞功能看URL参数的本质
假设页面里有一个“给文章点赞”的按钮，点击以后需要把文章 ID 告诉服务器，服务器记录完以后返回最新点赞数。这个场景因为只是查询量少、没有敏感信息，适合用 GET 请求。最直接的方式，是把参数拼在 URL 的后面，用问号分隔，多个参数之间用 & 连接。
javascript复制var articleId = 123;
var url = '/api/article/like?articleId=' + articleId;
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send();
这里有一个细节值得思考：为什么 GET 请求的参数要放在 URL 上，而且还要设置一下 Content-Type？实际上，GET 请求本身没有请求体，send 方法里可以是空的，参数全部要通过 URL 的查询字符串传给服务器。Content-Type 在 GET 场景下更多是给服务器一个提示，告诉它这个请求如果带表单格式参数时该怎么解析，但真正的参数传递位置还是 URL。服务端在接参数时，取的是 query string 或者 query param 里的值，和请求头不一定有直接关系。
所以“给 ajax 请求参数赋值”这句话，在 GET 场景下最直白的解释，就是拼一个字符串。把变量值插到 URL 里，可以是加号拼接，也可以用 ES6 模板字符串让代码可读性更好。我常用的写法是这样：
javascript复制var apiBase = 'https://api.example.com';
var page = 2;
var size = 20;
var url = apiBase + '/api/list?page=' + page + '&pageSize=' + size;
3.2 参数赋值的几种常见姿势和潜在风险
GET 请求的参数值，本质上最后都会变成 URL 上的一部分。但 URL 是一个有严格格式要求的字符串，比如空格不能直接出现，中文也不能直接放上去，包括 &、=、? 这些字符都有特殊含义。如果你把一个用户输入的搜索关键词直接拼进 URL，里面刚好包含一个 & 符号，服务器在解析参数时会把这个 & 当成新参数的开始，导致整条参数被截断。
所以规范的写法应该是使用 encodeURIComponent 对参数值做编码，把特殊字符转成百分号编码的形式。如果拿到一个对象，要给里面每个参数赋值，可以自己写一个简单的序列化函数，或者直接使用 URLSearchParams。
javascript复制function objectToQueryString(params) {
var arr = [];
for (var key in params) {
if (params.hasOwnProperty(key)) {
arr.push(encodeURIComponent(key) + '=' + encodeURIComponent(params[key]));
}
}
return arr.join('&');
}
var query = objectToQueryString({ keyword: 'AJAX 入门', page: 1 });
var url = '/api/search?' + query;
console.log(url);
用 URLSearchParams 还可以简化掉手动拼接的递归逻辑，现代浏览器对它的支持已经非常成熟了。如果服务端需要接收数组参数，比如批量删除用户时要传 id 数组，有些后端期望的格式是 id=1&id=2&id=3，有些 Go 语言框架或者 Java 框架则更常见 id=1,2,3 然后用逗号分隔。写代码前应该先问清楚后端的约定，而不是自己随便选一种，否则很容易出现“传了半天，一个参数都没收到”的尴尬。
3.3 Layui里用AJAX GET请求时容易忽略的返回处理
回到 Layui 场景，做一个后台用户列表查询，一般会用 $.get 去拿数据。很多人照猫画虎写出来的代码是能发请求，也能看到 Network 面板里有响应，但回调函数里拿不到预期的 data。原因往往在于 Layui 回调的第一个参数 res，取决于响应体的格式以及指定 dataType。如果接口返回的字符串确实是一段 JSON，但是请求里没有写最后一个参数 'json'，Layui 内部默认可能是把响应当纯文本处理，此时 res 只是一个字符串，访问 res.code 自然是 undefined。
javascript复制$.get('/api/user/list', { page: 1, limit: 10 }, function (res) {
console.log(res); // 如果这里打印出来是字符串，说明 dataType 没有匹配上
}, 'json');
还有一种情况，接口返回的 JSON 结构是 {code: 200, data: [{...}]}，但你的代码想直接 res.list，那也一定取不到。这里是接口字段约定问题，不是 AJAX 库的问题。建议前端同学在后端同学联调的时候，一起先定一份简单的接口文档，至少把外层结构、状态码字段和数据列表字段统一下来。否则每个接口一个结构，前端每请求一个接口就要写一种解析逻辑，维护成本会瞬间失控。
4. 实例二：POST请求、编码格式与JSON数据的前后端配合
4.1 POST请求里编码格式为什么重要，“乱码”的根源
POST 请求和 GET 最大的区别，在于参数可以放在请求体里，而不是全堆在 URL 上。请求体是一段相对独立的数据，它最终怎么被服务器解析，取决于请求头里的 Content-Type。很多后端新手为什么做接口时总是遇到中文乱码？因为他们压根没弄清楚自己发出去的请求，到底用的是哪一种编码格式。
最常见的两种 POST 编码格式，一种是 application/x-www-form-urlencoded，这种格式看起来就像是把 GET 的查询字符串原封不动搬到了请求体里，参数之间用 & 连接，参数值同样要做 URL 编码。如果不主动做编码，推荐给 AJAX 请求设置编码格式时用 URLSearchParams 或者工具函数生成这个字符串。另一种是 application/json，请求体里直接放一段 JSON 文本，整个结构是一个嵌套对象打底、可以包含深层级数据的字符串。
这两种格式不能随便混用。如果我设置 Content-Type 为 application/json，但请求体却放了一个 query=test&page=1 这样格式的字符串，大部分后端框架会直接解析失败，报参数格式异常。反过来也一样，我声明了 application/x-www-form-urlencoded，请求体却放了一段 JSON 字符串，服务端拿到的就是一个 key 等于整串 JSON 的值，解析结果同样乱套。所以“ajax 请求设置编码格式”这个动作，不只是在代码里写一个请求头那么简单，而是你要先想清楚服务端期望接收哪一种格式，然后前后端保持一致的约定。
4.2 给ajax请求参数赋值：FormData、URLSearchParams与JSON三种出路
下面这段代码演示了一个比较标准的 POST JSON 请求，它通过 XMLHttpRequest 把 JavaScript 对象转成 JSON 字符串发送给服务器。
javascript复制var params = {
username: '张三',
age: 18,
tags: ['frontend', 'ajax']
};
var xhr = new XMLHttpRequest();
xhr.open('POST', '/api/user/save', true);
xhr.setRequestHeader('Content-Type', 'application/json;charset=UTF-8');
xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
if (xhr.status === 200) {
var result = JSON.parse(xhr.responseText);
console.log(result);
} else {
console.error('请求失败', xhr.status);
}
}
};
xhr.send(JSON.stringify(params));
当需要提交文件或者直接模拟表单提交时，FormData 是更好用的选择。它的特点是不需要手动设置 Content-Type，因为浏览器在调用 send(formData) 时，会自动生成一个包含 boundary 分隔符的 multipart/form-data 请求头，把整个请求体包装成一个符合文件上传规范的数据块。手动去设置 Content-Type 反而容易出问题，因为你会漏掉后面的 boundary 参数。
另一种场景是提交一个完整页面表单，用 FormData 构造起来非常快：
javascript复制var form = document.getElementById('userForm');
var formData = new FormData(form);
formData.append('remark', '这是额外的字段');
var xhr = new XMLHttpRequest();
xhr.open('POST', '/api/user/save', true);
xhr.onload = function () {
if (xhr.status === 200) {
console.log('保存成功');
}
};
xhr.send(formData);
这里的核心选择逻辑是：如果数据是结构简单的键值对，且没有文件字段，优先考虑 x-www-form-urlencoded，服务端解析最简单，PHP、Java、Node.js 都能直接取到字段；如果数据结构复杂，包含数组、嵌套对象，强烈推荐 JSON 格式，它能表达的信息层级远高于扁平键值对；如果涉及文件上传，则必须用 FormData，这是浏览器接口层面的限制，ajax 请求传参选哪种方式，不是看前端心情，而是看后端接口怎么定义的。
4.3 返回的数据到底是什么形状：从JSON到XML再到HTML片段
请求发出去以后，最常接到的是 JSON 响应。很多同学会直接写 res.code，但没注意到此时 res 其实还是一个字符串，需要先用 JSON.parse 处理。用原生 XHR 时，可以通过 responseType 来让浏览器帮你自动解析。把 xhr.responseType 设置为 'json'，那么 xhr.response 就会自动成为一个对象，不需要再手动 JSON.parse。不过这里要留意兼容性，老版本浏览器的 responseType 支持并不完整。
JSON 是当前的主流格式，但老系统中经常出现返回 XML 片段的场景。比如有些 Java 老项目，服务端用 XML 返回配置结构，前端拿到一段这样的文本：
xml复制<response>
<code>0</code>
<data>
<item id="1">张三</item>
<item id="2">李四</item>
</data>
</response>
前端的 XMLHttpRequest 对象有一个 responseXML 属性，如果请求头中的 Content-Type 是 text/xml 或 application/xml，并且浏览器正确解析了，可以通过 responseXML.documentElement 拿到根节点，然后用 getElementsByTagName 或者 childNodes 去遍历节点内容。实际开发中更稳妥的方式，是用 DOMParser 手动把响应文本解析成 XML 文档，这样就不用依赖服务器是不是真的在响应头里写了正确的 Content-Type。这和处理 JSON 时不要依赖 responseType 会不会自动帮忙的道理是一样的，先把响应当文本拿回来，再用合适工具做转换，反而是最可控的。
返回 HTML 片段的场景也隐约可见。比如点击“加载更多”以后，服务器直接返回一段已经渲染好的列表 HTML，前端只需要把它插到指定容器里即可。这种情况下不需要 JSON.parse，直接把 xhr.responseText 赋值给容器的 innerHTML 或 insertAdjacentHTML 更合适。我遇到过不少同学，习惯性地看到所有接口都想着 JSON.parse，结果拿一段 HTML 字符去 parse，必然报错，然后就开始怀疑是不是请求出了问题。说真的，先看清楚响应内容长什么样再决定解析方式，会比盲目套模板高效得多。
5. AJAX请求的编码、传参与乱码问题排查实录
5.1 “请求发出了，服务器却收不到参数”应该怎么排查
这个问题是 AJAX 实战里最高频的翻车事件之一，一天能被问十次。网络面板里明明看到请求已经发出去了，响应也正常，但后端日志里怎么也打印不出前端传的值。通常可以从三个方向依次排查。
先看参数到底放在哪里。打开浏览器开发者工具的 Network 标签，点击对应的请求，在 Payload、Request 或 Params 分类下能看到参数是否真正存在于请求里。如果你用的是 GET，参数应当出现在 Query String Parameters 区域；如果你用的是 POST 并且编码格式是表单形式，参数应当出现在 Form Data 区域；如果你用的是 POST 且 Content-Type 是 application/json，参数应当出现在 Request Payload 区域。如果三个区域里都没有参数，就要检查代码里是否真的把 data 或者 send 的参数传过去了，常见错误是只调用了 xhr.open 但忘写 xhr.send(params)。
再看参数格式是否匹配后端框架的解析规则。Java 的 Spring MVC 里，当请求的 Content-Type 为 application/json 时，通常需要 @RequestBody 来接收，表单格式则由 @RequestParam 接收，两者不能互换。Node.js 的 Express 里，解析 application/json 需要引入 body-parser 或 express.json()。如果你只设置了 POST 请求的 Content-Type 是 JSON，但后端没有对应配置，那么参数就会在进入业务逻辑前就被框架丢弃。
最后看是否遇到了跨域问题。所谓跨域，是浏览器的同源策略限制了一个源下的页面不能随便读取另一个源返回的数据。跨域请求如果“预检”阶段没有通过，甚至不会发出真正的业务请求，更谈不上服务器收到参数。跨域虽然限制的是前端读取响应，但在排查时表现出的症状也可能是“请求没发出去”或“收到了但读不到内容”。遇到这种问题时直接看 Network 里有没有一条 OPTIONS 请求，如果 OPTIONS 的状态不对，说明服务端没有正确返回 CORS 相关的响应头，需要后端在接口层配置 Access-Control-Allow-Origin 等字段。
5.2 中文乱码问题的双端排查口诀
中文乱码是围绕“ajax 请求设置编码格式”的另一个高频问题，造成乱码的原因可能在请求端，也可能在响应端，需要分情况讨论。如果你发现发送到后端的字符串在服务端日志里是一堆百分号开头的字符，那大概率是客户端对参数做了 URL 编码，而后端框架没有相应解码，或者客户端根本没有编码中文，直接把 utf-8 字符塞给了仍按其他字符集解析的服务端。
一个非常容易出错的场景，是前端手动拼 URL 时没有做 encodeURIComponent。服务端收到 URL 参数后，会按照自己配置的字符集去解析百分号编码，如果前后端字符集不一致，中文就会变成乱码。所以我的建议是前端发请求统一对参数值做 encodeURIComponent，后端则统一按 UTF-8 解析请求。
响应端乱码的表现则不一样，页面显示的中文全部变成了“锟斤拷”或者问号。这通常是服务端返回的数据本身不是 UTF-8，或者响应头里的 Content-Type 没有写明 charset。浏览器在无法从响应头确定字符集时，会按自己的默认策略猜。此时解决思路是先检查响应头，看到底写的什么编码，然后让开发人员在服务端把它改成 Content-Type: application/json; charset=utf-8 或 text/html; charset=utf-8。前端能做的事情有限，不建议在前端做字符集转换，因为响应到了浏览器之后，转码救回来的可能性低，方案乱七八糟的还容易误伤数据。
为了好记忆，可以把排查乱码当成一条线，从“发出去的请求报文”看到“服务器收到的内容”，再到“服务器返回的响应头”，再到“前端最终渲染的字符”。哪一个环节和 UTF-8 断开了，乱码就会出现。
5.3 HTTP状态码与超时异常：别把红字都当成错误
当你打开开发者工具，经常能看到网络请求列表里出现红色行，很多同学第一反应是“请求失败了”。实际上，HTTP 状态码只是服务器对这次请求的处理状态标记，不是所有非 200 都代表“前端代码写错了”。200 是成功，3xx 是重定向，4xx 说明问题多半出在客户端身上。404 是 URL 写错或者接口不存在，403 是权限不足，405 是方法不对，比如后端只允许 POST，前端却发了一个 GET。5xx 则是服务端内部出了问题，和你前端怎么发请求关系不大。
判断某个请求是好是坏，其实是把“网络是否通畅”和“业务是否成功”两层拆开看。HTTP 层返回 200，只代表请求到达了服务器并且拿到了响应，不代表业务操作就一定成功。很多项目的接口设计是 HTTP 永远返回 200，但响应体里用一个 code 字段表示业务结果，code 为 0 是成功，非 0 是各种业务异常。这种情况就不能再看 HTTP 状态码判断成功与否了，而是要解析出 body，再判断 code。也不要把所有异常都塞进同一种提示里。我见过一个后台项目，断网时弹“服务异常”，权限不足时也弹“服务异常”，用户根本分不清是真挂了还是账号问题，体验很差。正确做法是先把 HTTP 状态码拆出来，再结合业务码分别处理。
说到超时，原生 XMLHttpRequest 可以设置 timeout 属性，如果请求在指定时间内没有返回，会触发 ontimeout 事件。fetch 则相对麻烦一点，它没有内置的 timeout 超时机制，一般需要用 AbortController 来手动中断请求。如果做上传文件这种耗时操作，超时时间需要预留足够大的余量，还要给用户一个可感知的进度和取消入口，否则请求一直被挂起，界面也会一直转圈。一个顺手的处理逻辑是：先嗅探网络连接是否正常，再根据状态码分类，然后针对业务 code 提示不同文案，最后给用户一个“重试”按钮，这四种信息组合起来，才能谈得上“良好的用户反馈”。
就我自己的习惯而言，排查 AJAX 问题很少直接去翻框架源码，而是先打开开发者工具的 Network，看请求头、请求体、响应体这三样东西是否和代码里预期的一致。大量问题的答案就藏在“前端以为发的是 JSON”和“后端实际收到的是表单格式”这种信息差里。前后端协作的项目，沟通接口约定比会写十种请求封装更重要。希望这篇 AJAX 实例详解，能把你在请求发送、编码格式、传参方式和问题排查上弯弯绕绕的地方一次性梳理清楚，以后遇到类似问题，心里会更有底。