企业官网建设流程全解析

做前端这几年，我见过太多新人一上来就抱着 axios 猛敲，问起 “AJAX 到底是什么、底层怎么跑”，半天说不出个所以然。框架确实已经把网络请求封装得很好了，但 AJAX 这个概念依然是所有前后端数据交互的地基，尤其是你在维护老项目、排查接口问题、处理中文乱码的时候，不懂底层真的会吃大亏。

这篇文章打算带着大家从零开始，把 AJAX 基础实例讲透。内容包括用原生 XMLHttpRequest 发 GET/POST 请求、设置编码格式、给请求参数赋值，再聊聊封装、调试和常见问题；顺带解答一个很多 ASP.NET 老玩家关心的热点话题：AJAX Control Toolkit 20 到底支持 VS2022 吗，在 VS2022 里怎么添加。语言尽量直白，每个环节都有可直接复制的代码，适合刚入门前端、想夯实基础的同学，也适合正在维护 WebForms 老项目、被工具集兼容性问题折磨的开发者。

1. 先搞清楚 AJAX 到底是怎么一回事

1.1 AJAX 解决的痛点，其实很简单

AJAX 全称 Asynchronous JavaScript And XML，中文叫“异步 JavaScript 和 XML”。名字里有 XML，但实际开发中我们传的更多是 JSON 字符串、普通文本或者表单数据。它要解决的核心问题，用一句话说就是：在不刷新整个页面的前提下，让页面悄悄地和服务器交换数据。

想象一个非常古老的网页，用户填完表单，点击提交，浏览器白屏一下，整个页面重新加载一遍，服务端渲染出新的 HTML 再整个返回回来。这个过程不但慢，而且体验非常断裂。AJAX 出现后，浏览器可以通过 JavaScript 在后台默默发一个网络请求，等服务端返回数据，再用这段数据局部更新页面的某块内容。打个比方，以前去餐厅想加个菜，必须把整桌菜撤回去重新做；现在相当于服务员端着小本子随时记菜单，厨房做好了单送一份过来，你原来桌上的菜完全不受影响。

这里的“异步”是重点。浏览器发出请求之后，不会停在那儿傻等，页面照常滚动、点击、渲染；等响应回来了，由 JavaScript 里的回调函数或事件处理器来接住结果。这种“下单后不用干等，到货了电话通知你”的模型，就是整个 AJAX 的心智基础。

1.2 深入浅出理解 XHR 和 Fetch

XMLHttpRequest是 AJAX 最传统的实现载体，所有现代浏览器都把它的能力暴露给了 JavaScript。后来fetchAPI 横空出世，用 Promise 重新设计了一套请求方案，写法更优雅，但它本质上也是基于同样的 HTTP 通信模型。所以不管用哪个，先理解XMLHttpRequest都没坏处。

这里我特别想纠正一个误区：很多人以为 AJAX = 某个具体函数，其实 AJAX 是一个设计模式，XHR 只是实现它的一种手段。无论以后你用 fetch、axios，还是 jQuery 的$.ajax，底层的请求本质都没有变：你要拼好请求地址、请求方法、请求头、请求体，发送出去，然后处理响应状态和数据。

初学者容易困惑的，还有 XHR 的readyState状态码。它不是 HTTP 状态码，而是描述 XHR 对象内部生命周期：

• 0：请求未初始化，open方法还没调用。
• 1：服务器连接已建立，open已经执行。
• 2：请求已接收，send已经执行，响应头已经拿到。
• 3：正在解析响应内容。
• 4：响应内容解析完成，可以读取数据了。

实际开发中我们最关注readyState === 4，因为只有到了这个阶段，responseText或responseXML才是完整的。而 HTTP 状态码（200、404、500 这些）需要通过status属性获取。两者完全不是一回事，我把这句话写在前头，能帮你避开一半的入门迷惑。

2. 第一个基础实例：用 XMLHttpRequest 发 GET 请求

2.1 最小可用的 GET 代码

先来一段最朴素的代码，发一个 GET 请求，拿到 JSON 数据后打印出来：

// 1. 创建 XHR 对象 var xhr = new XMLHttpRequest(); // 2. 初始化请求：方法、URL、是否异步 xhr.open('GET', 'https://api.example.com/users?id=123', true); // 3. 发送请求 xhr.send(); // 4. 监听状态变化 xhr.onreadystatechange = function () { if (xhr.readyState === 4) { if (xhr.status >= 200 && xhr.status < 300) { // 请求成功 var data = JSON.parse(xhr.responseText); console.log('拿到数据：', data); } else { console.error('请求失败，HTTP 状态码：', xhr.status); } } };

逐行拆解一下。open方法第三个参数传true表示异步，如果传false就是同步请求，页面会彻底卡住直到响应返回，开发中几乎没有理由用同步。send方法在 GET 请求里可以不填参数；POST 请求则把请求体作为参数传进去。

拿到响应后，我用JSON.parse把responseText转成对象。这里要注意：responseText永远是字符串，不管响应头里写的 Content-Type 是什么。很多人第一次犯的错就是直接xhr.responseText.name，结果得到undefined，因为压根还没解析。

2.2 POST 请求怎么写请求体

POST 和 GET 的核心差异在于数据放在哪里。GET 习惯把参数拼在 URL 上，POST 则把数据放进请求体。发送 POST 时，一定要在send之前设置Content-Type，告诉服务端你发的数据是什么格式，否则服务端可能解析不到参数。

var xhr = new XMLHttpRequest(); xhr.open('POST', 'https://api.example.com/users', true); // 声明发送的是普通表单格式 xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); xhr.onreadystatechange = function () { if (xhr.readyState === 4) { if (xhr.status === 200) { console.log('新增成功：', xhr.responseText); } } }; // 请求体内容 var body = 'name=' + encodeURIComponent('张三') + '&age=25'; xhr.send(body);

这里有个关键动作：setRequestHeader必须在open之后、send之前调用，并且 if 判断我用了xhr.status === 200，其实更规范的做法是判断200 <= xhr.status < 300，因为 201、204 同样代表成功。POST 请求若使用application/x-www-form-urlencoded，请求体格式就跟浏览器原生表单提交完全一样，服务端可以按表单处理；如果发的是 JSON，则需要设置application/json; charset=utf-8，后面第四部分详细讲。

2.3 回调时机和共同坑点

XHR 的响应处理有两种主流姿势，一种是上面的onreadystatechange，另一种是直接使用onload：

xhr.onload = function () { if (xhr.status >= 200 && xhr.status < 300) { console.log(xhr.responseText); } };

onload只在readyState === 4时触发一次，写法更简洁，我推荐用这个。但不管是哪种写法，都要留意几个高频坑：

• xhr.open里的 URL 如果包含中文参数，必须先encodeURIComponent编码，否则浏览器可能直接报错或把中文变成乱七八糟的字符。
• 请求完成后记得考虑xhr = null，尤其在老式 IE 环境下，以便释放资源，现代浏览器已经不强制，但在长列表循环请求中主动释放会更稳。
• onerror只能捕获网络层面错误，比如断网、域名不存在；HTTP 404 或 500 不会触发onerror，它属于“服务器成功返回了错误状态”，只能在onload里用status判断。

3. AJAX 请求设置编码格式，解决中文乱码这一篇够用

3.1 乱码的本质是两边用了不同“字典”

中文乱码问题，几乎每个用 AJAX 的人都会遇到。要理解乱码，得先知道字符编码是怎么回事。计算机存不了汉字，只能存二进制；我们需要一套映射表，把汉字映射成数字，再转成二进制存储。GBK、UTF-8、ASCII 就是不同的映射表。如果发送方用 UTF-8 编码发送，接收方却按 GBK 解码，就好比甲用新华字典把“你好”翻译成编号，乙却拿目汉字典去查这个编号，结果必然是牛头不对马嘴。

HTTP 请求的编码格式，由两部分共同决定：请求头里的Content-Type以及请求体自身的编码。浏览器默认情况下，页面本身是 UTF-8，那么 JS 里字符串发出去时也会按 UTF-8 处理；服务端收到二进制流后，需要按照同一个编码去解码参数。

3.2 实际设置编码格式的几种姿势

第一种：使用表单格式。这是最常见的浏览器原生交互格式。

xhr.open('POST', '/api/login', true); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8'); xhr.send('username=' + encodeURIComponent('张三'));

请求头里明确标注了charset=UTF-8，等于告诉服务端：“我这个请求体是用 UTF-8 编码的，请按 UTF-8 解码。”不过需要强调，这个 charset 更多是“声明性质”，真正决定字节形态的，是发送数据时内部使用的编码方案。现代浏览器页面本身是 UTF-8，它会按照 UTF-8 对字符串做百分号编码。

第二种：使用 JSON 格式。

xhr.open('POST', '/api/login', true); xhr.setRequestHeader('Content-Type', 'application/json; charset=UTF-8'); var payload = JSON.stringify({ username: '张三', password: '123456' }); xhr.send(payload);

相比表单格式，我更喜欢 JSON。原因是数据结构更清晰，能表达嵌套对象、数组，服务端解析也很方便。但前提是服务端要正确读取 JSON 请求体。比如 ASP.NET Web API 里，如果 action 参数是一个对象，框架会自动帮你反序列化 JSON；而传统 WebForms 的 code-behind 里，可能需要手动读取Request.InputStream。

第三种：直接在 URL 上带中文参数。

xhr.open('GET', '/api/search?keyword=' + encodeURIComponent('动态规划'), true); xhr.send();

这里要注意，open方法里的 URL 如果直接写中文，不同浏览器处理方式不一致，有的会帮你编码，有的直接摆烂。永远手动编码，是治本的办法。

3.3 乱码排查的标准套路

遇到乱码，先别急着改代码，按我的排查顺序走：

第一，按 F12 打开浏览器开发者工具，切到 Network 面板，找到那条请求，看一眼请求头里的Content-Type是否带了charset=UTF-8；再看响应头里的Content-Type。如果响应头是text/html; charset=gb2312，而前端页面是 UTF-8，显示出来必然乱码。

第二，检查服务端返回的数据是否做了正确编码。很多老项目默认数据库连接字符集是 GBK，页面和接口却统一成 UTF-8，数据从库里取出来就已经是乱的了，网络层面再怎么设置都没用。

第三，确认是不是前端显示容器的问题。如果页面本身 meta 标签声明的是gb2312，而请求返回 UTF-8 数据，同样会乱。这里我提供一个简单判断技巧：把服务端返回的原文存到文本文件里，用专门的文本编辑器看它是什么编码；如果文件用 UTF-8 打开正常，说明服务端没问题，问题出在前端；反之则是服务端的问题。

4. 给 AJAX 请求参数赋值：序列化、FormData 与 JSON

4.1 参数到底该放在哪

给 AJAX 请求参数赋值，首先要确定“参数放哪个位置”。按 HTTP 语义划分：

• GET：参数拼在 URL 查询字符串里，适合查询、搜索。
• POST：参数放请求体里，适合提交表单、新增数据、上传文件。
• 请求头：某些认证信息、token、语言标识，建议放自定义请求头。

放的位置不同，赋值的方式也不同。URL 查询串最简单粗暴，但要处理编码；请求体则需要把对象序列化成字符串，或直接用 FormData 构造。

4.2 用 URLSearchParams 优雅地构造查询串

很多老教程教你这样拼字符串：

var params = 'id=' + id + '&name=' + encodeURIComponent(name) + '&page=' + page;

这样写能用，但一复杂就想哭。现代浏览器提供了URLSearchParams，专门帮我们做这件事：

var params = new URLSearchParams(); params.append('id', 123); params.append('name', '张三'); params.append('page', 1); // 得到：id=123&name=%E5%BC%A0%E4%B8%89&page=1 var queryString = params.toString(); xhr.open('GET', '/api/list?' + queryString, true); xhr.send();

URLSearchParams.toString()会自动对中文、特殊字符做百分号编码，省去手动encodeURIComponent。如果你手里已经是一个普通对象，可以配合Object.entries()一行转掉：

var obj = { id: 123, name: '张三', page: 1 }; var params = new URLSearchParams(); Object.keys(obj).forEach(function (key) { params.append(key, obj[key]); }); // 请求地址拼接 params.toString()

在给 AJAX 请求参数赋值的所有技巧里，这是我日常最高频使用的方案，没有之一。

4.3 FormData：文件上传绕不开它

如果要上传文件，绝对不能手动拼字符串，而是用FormData对象。它有一个巨大的好处：浏览器会自动设置Content-Type为multipart/form-data; boundary=...，并且自动生成随机分隔符。如果你自己手动设置这个头，很容易漏掉 boundary，导致服务端解析失败。

var formData = new FormData(); formData.append('username', '张三'); formData.append('avatar', document.getElementById('fileInput').files[0]); var xhr = new XMLHttpRequest(); xhr.open('POST', '/api/upload', true); // 注意：这里不要手动设置 Content-Type！ xhr.send(formData);

初学阶段很多人忍不住写上xhr.setRequestHeader('Content-Type', 'multipart/form-data')，然后死活上传失败，原因就是缺少 boundary，或者在设置完send(formData)之后又偷偷改了头。记住：FormData 的场景，让浏览器自己做主。

文件上传有个特别实用的附加功能：监听上传进度。

xhr.upload.onprogress = function (e) { if (e.lengthComputable) { var percent = Math.round((e.loaded / e.total) * 100); console.log('上传进度：' + percent + '%'); } };

这个xhr.upload对象是专门用来监听上传进度事件的，下载进度则用xhr.onprogress。两者别记混。

4.4 JSON 数据怎么赋值最标准

后端接口现在十有八九是接收 JSON。给 AJAX 请求参数赋值的正确姿势是：

var data = { username: '张三', hobbies: ['coding', 'reading'], address: { city: '北京', street: '中关村' } }; var xhr = new XMLHttpRequest(); xhr.open('POST', '/api/profile', true); xhr.setRequestHeader('Content-Type', 'application/json; charset=UTF-8'); xhr.send(JSON.stringify(data));

你要明白：请求体最终只能是字符串或二进制流，不能直接塞一个对象。JSON.stringify负责把对象序列化成 JSON 字符串；服务端收到后，用对应的 JSON 解析器还原成对象。我遇到过不少前端，Content-Type写的是 JSON，请求体却是一大串手写的key=value&key=value，这等于“把盐当糖撒”，后端想正确反序列化都难。

反过来，JSON.parse负责把返回的字符串还原成对象。如果返回的字符串格式不合法，JSON.parse直接抛异常。稳妥一点可以包一层try...catch，也可以在拿到responseText时先判断是否以{或[开头：

var text = xhr.responseText; try { var result = JSON.parse(text); console.log(result); } catch (e) { console.warn('响应不是合法 JSON：', text); }

5. 自己动手封装一个迷你 AJAX 方法

5.1 为什么要封装

原生 XHR 写起来其实挺啰嗦：每次要创建对象、写onreadystatechange、判断状态、解析 JSON。如果项目里到处复制粘贴这些模板代码，后面想统一加一个 token 头、统一处理超时，你就得改几十处。所以在理解基础实例之后，我强烈建议自己封装一层轻量方法，哪怕只有几十行，也能让你真正体会到框架的作者为什么要那么设计。

5.2 一个支持 GET/POST、Promise 化的 mini 版本

下面这个封装是我早期常写的骨架，不依赖任何库，适合学习和小项目：

function request(options) { return new Promise(function (resolve, reject) { var xhr = new XMLHttpRequest(); var method = options.method || 'GET'; var url = options.url; var data = options.data || null; // 处理 GET 参数 if (method.toUpperCase() === 'GET' && data) { var params = new URLSearchParams(); Object.keys(data).forEach(function (key) { params.append(key, data[key]); }); var separator = url.indexOf('?') > -1 ? '&' : '?'; url += separator + params.toString(); data = null; } xhr.open(method, url, true); // 设置默认头 xhr.setRequestHeader('Content-Type', options.contentType || 'application/json; charset=UTF-8'); // 超时处理 xhr.timeout = options.timeout || 10000; xhr.ontimeout = function () { reject(new Error('请求超时')); }; xhr.onload = function () { if (xhr.status >= 200 && xhr.status < 300) { var result = xhr.responseText; if (options.dataType !== 'text') { try { result = JSON.parse(result); } catch (e) { // 保持字符串 } } resolve(result); } else { reject(new Error('HTTP ' + xhr.status + ': ' + xhr.statusText)); } }; xhr.onerror = function () { reject(new Error('网络错误')); }; // 发送 if (method.toUpperCase() === 'POST' && data) { if (typeof data === 'string') { xhr.send(data); } else { xhr.send(JSON.stringify(data)); } } else { xhr.send(); } }); } // 使用示例 request({ method: 'GET', url: '/api/users', data: { page: 1 } }) .then(function (data) { console.log(data); }) .catch(function (err) { console.error(err); });

这段封装代码你可以直接用，也可以按需扩充。里面有几个我特意保留的细节：timeout和ontimeout用于处理超时；GET 请求自动序列化参数；POST 请求自动 JSON 序列化。这些恰恰是初学者最容易忽略的工程化细节。

5.3 工程化的几个残忍真相

封装好了只是第一步。真实项目里还要考虑：请求携带凭证（比如withCredentials属性处理 cookie）、取消请求（xhr.abort()）、统一处理 401 跳转登录、防止重复提交。这些都不是 AJAX 的“基础”，但我在实际工作中真切体会过它们的价值。

举个例子，一个客户端的表格查询按钮，用户手抖点了十次，结果发出去十个重复请求，后端扛不住，页面卡成幻灯片。解决办法很简单：请求发出后，在应答回来前禁用按钮；或者记录当前请求的标识，重复请求直接abort。知道 XHR 有abort()方法，很多问题都能在源头化解。

6. jQuery Ajax 和 Axios：历史与现状里的 AJAX

6.1 老项目里的 $.ajax 是怎么回事

现在的新项目大多用 fetch 或 axios，但你在维护老系统时，早晚会遇到 jQuery 的$.ajax。它的设计思路和原生 XHR 一致，只是把细节包装得更友好：

$.ajax({ url: '/api/user', method: 'POST', contentType: 'application/json; charset=UTF-8', data: JSON.stringify({ name: '张三' }), success: function (res) { // 成功回调 }, error: function (xhr, status, error) { // 失败回调 } });

jQuery 对data参数的处理有个细节：如果data传对象，并且contentType默认是application/x-www-form-urlencoded; charset=UTF-8，jQuery 会自动把它序列化成key=value&key=value；如果contentType设置成了application/json，则 jQuery 不会帮你JSON.stringify，你得像上面那样手动处理。很多人在这里栽跟头，记住这句能帮你省很多时间。

jQuery Ajax 还有一个叫traditional的选项。当traditional为true时，数组参数的序列化方式是name=1&name=2；为false时则是name%5B%5D=1&name%5B%5D=2，也就是name[]=1&name[]=2。后端如果按经典表单方式解析数组，两者得到的形态不一样，接口联调前一定要确认对方的解析方式。

6.2 Axios 与 fetch 在编码上的差异

axios 在浏览器里本质也是 XHR 的封装，但它对参数赋值做了更聪明的处理。GET 请求推荐用params字段，axios 会自动把对象转成 URL 查询串：

axios.get('/api/list', { params: { page: 1, keyword: '张三' } });

POST 请求可以直接传对象，axios 默认会把对象 JSON 序列化，并设定Content-Type为application/json; charset=utf-8：

axios.post('/api/save', { name: '张三', age: 25 });

fetch 则是一套更现代的 API，它默认的编码相关行为不太一样。比如 Make sure you explicitly set Content-Type if you send JSON string。fetch 的请求体如果是字符串，默认不带Content-Type，服务端可能按text/plain或其他方式解析。所以用 fetch 的时候，大概率要自己补上：

fetch('/api/save', { method: 'POST', headers: { 'Content-Type': 'application/json; charset=UTF-8' }, body: JSON.stringify({ name: '张三' }) });

另外，fetch 还有一个“坑”：响应即使 404 或 500，它默认也不会 reject，只有网络错误才 reject。所以用 fetch 时，必须手动检查response.ok或response.status。这跟原生 XHR 的onload判断很像，学过了原生之后，你在使用 fetch 时会特别有感觉。

6.3 学了基础之后，怎么选库

我的建议很明确：学习期一定要先写原生 XHR 和 fetch；正式项目里直接上 axios，或者根据团队技术栈使用统一的请求封装。基础不是为了让你手写需求，而是为了让你在调试任何现成库时知道它在干什么。

7. AJAX Control Toolkit 与 VS2022 的兼容性实测

7.1 先认识这个有点“考古”的工具箱

如果你是从 WebForms 时代走过来的 .NET 开发者，一定对 AJAX Control Toolkit 不陌生。它是微软 ASP.NET AJAX 生态里的一套服务端控件库，提供了自动补全、日历选择、水印输入、Popup 弹窗等一堆“浏览器增强”控件。当年它的使用方式很魔法：拖一个CalendarExtender到页面上，关联一下 TextBox 的 TargetControlID，神奇的下拉日历就出来了。

它的运行机制依赖几个配套组件：ScriptManager、UpdatePanel、ScriptResourceMapping。简单说，ScriptManager负责管理页面上的 AJAX 脚本和控件脚本，UpdatePanel可以局部刷新局部区域，整体体验就像给 WebForms 页面插上了异步的翅膀。这套东西在 2010 年前后风光无限，但现在回头看，它和现代前后端分离的架构完全是两个物种。

7.2 在 VS2022 中使用 AJAX Control Toolkit 的真实体验

先说结论：AJAX Control Toolkit 20 这个版本本身是基于 .NET Framework 的，并不是专门为 VS2022 生的新版本。VS2022 可以创建传统 ASP.NET Web Forms 项目，也依然支持 .NET Framework 4.8，所以“能不能用”取决于你把项目框架定在哪里。如果你在 VS2022 里新建一个 .NET Framework 4.8 的 Web Forms 项目，通过 NuGet 搜索AjaxControlToolkit，可以安装到最新的稳定包（目前常见的是 20.1.0）。

安装完成后，工具箱不会自动出现一排新控件，这是新手最容易懵的地方。你需要在“工具箱”上右键，选择“选择项”，再点击“.NET Framework 组件”，浏览到项目的 bin 目录，选中AjaxControlToolkit.dll，确认添加。添加成功后工具箱里会出现一组以AjaxControlToolkit开头命名的扩展器控件。

在页面中使用时，手动注册程序集：

<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="ajaxToolkit" %>

然后确保页面上有ScriptManager：

<asp:ScriptManager runat="server" ID="sm1" />

给 TextBox 加日历扩展器的基础示例：

<asp:TextBox runat="server" ID="txtDate" /> <ajaxToolkit:CalendarExtender runat="server" ID="ce1" TargetControlID="txtDate" />

这套组合在 VS2022 编译层面基本可行，但设计器体验确实不如老版本 VS 那么顺滑。有些控件在可视化设计视图里会显示异常甚至报错，切换到“源”视图操作通常更稳定。如果你用到了AjaxFileUpload、HtmlEditorExtender这类依赖较多脚本的控件，运行时还可能要排查脚本资源路径是否正确。最典型的问题包括：没有正确注册脚本导致控件不渲染、页面报“类型 AjaxControlToolkit.xxx 未定义”、或者局部刷新后扩展器失效。

7.3 新项目请绕道，老项目这样平稳过渡

我的态度很明确：如果你现在才开始学 AJAX，或者打算新开一个 ASP.NET 项目，完全没必要碰 AJAX Control Toolkit。它绑定了 WebForms 生命周期，维护成本高，前后端逻辑耦合严重。哪怕非要在 VS2022 里做 WebForms 维护，也建议优先评估是否有必要升级到工具的 20.1.0，还是继续沿用旧版本锁定不升级。升级前一定要看 release notes，因为旧版本从 4.1.0 升到 20.1.0 时，内部依赖的 JSON 序列化库和程序集名称都变了不少，直接替换 DLL 有可能引发一大批编译错误。

老项目怎么过渡，我有几招：第一，把所有 AJAX Control Toolkit 相关的调用尽量抽到一个独立页面，逐步替换成 Web API + 原生 fetch；第二，如果只是需要日历、弹窗这类小功能，直接引入一个现代的纯前端组件库去实现，脱离服务端控件模型；第三，保持 WebForms 项目框架不升级，作为“稳定运行的黑盒”，对它的改动尽可能收敛。

从学习价值上看，AJAX Control Toolkit 的历史意义大于实用意义。真正学到 AJAX 核心，还是应该回到 XHR、fetch、跨域这些基础上来。

8. 常见问题与排查技巧实录

8.1 高频问题速查表

8.2 一套可以复用的排查套路

我不止一次在产品群被拉去排查“接口挂了”的问题。真正的高效做法是分四层判断：第一层，打开 Network 面板，看请求有没有发出去；如果请求灰了，是浏览器层面被 CORS 拦截或网络断了。第二层，看请求头里的 Content-Type、Accept、Cookie 是否跟预期一致；第三层，看服务端有没有收到数据和日志；第四层，看数据库里到底存没存进去。

最忌讳的是第一件事就去看后端代码。绝大多数所谓的“接口问题”，用 Network 面板就能把范围缩小一半。我每次复查 AJAX 问题，都会特别留意请求头Content-Type和请求体原始内容。尤其是 POST 请求，把 Payload 里那一串东西复制出来，扔到 POSTMAN 里重放一遍，马上就能知道是前端拼数据的问题还是后端解析的问题。

调试时还有一些小习惯值得培养：不要把console.log写得到处都是，而是用console.table打印数组对象；分析请求耗时可以借助performance.getEntriesByType('resource')；写定时轮询时，一定要考虑上一次请求还没结束的情况，累加一个请求计数器防止并发覆盖。

最后再分享一点我的体会

我个人这几年写 AJAX，最大的感受是：不管前端框架怎么换、请求库怎么升级，把“请求生命周期”想清楚、把“数据格式”定明白，就能省掉九成的联调扯皮。编码格式随手在 header 里写清楚，参数序列化提前约定好，状态码统一处理，这些问题说白了都是基本功。

如果你刚接触 AJAX，我真心建议不要急着上 axios，先用原生 XMLHttpRequest 把上面这几个基础实例亲手敲一遍，尤其是编码格式和参数赋值那两节。敲完你会发现，再看 fetch、再看 axios，它们不过是帮你把那些样板代码藏起来了而已。这层窗户纸捅破了，后面一切都顺了。