打开浏览器控制台，请求点一下按钮，步骤页面局部刷新了。请求这背后十有八九是步骤XMLHttpRequest对象在干活。很多人背过“五步走”的请求口诀，但真到写代码时还是步骤卡在状态码和回调顺序上。我见过一个同事调了两小时，请求最后发现是步骤`open`方法的第三个参数写成了`false`——同步请求把主线程堵死了，页面直接假死。请求

第一步其实不是步骤写代码，是请求创建对象。`const xhr = new XMLHttpRequest()`这行看着简单，步骤但IE6时代得用ActiveXObject，请求现在倒是步骤不用管了。有个细节：每次请求都得new一个，请求不能复用同一个实例发多个请求，否则后一个请求会覆盖前一个的回调。我试过偷懒复用，结果两个接口的数据串在一起，排查了半天。

接着是`xhr.open(method, url, async)`。method写GET还是POST，url带不带查询参数，async传true还是false，这三个参数决定了请求的基本形态。GET请求的参数得手动拼在url后面，用`encodeURIComponent`转义一下，不然中文或特殊字符会出问题。POST的话参数放在`send`里，还得设置`Content-Type`请求头。这里有个坑：`open`只是配置请求，还没真正发出去，所以别在这步之后就去读`xhr.responseText`，那会儿啥都没有。

第三步设置回调。`xhr.onreadystatechange`或者`xhr.onload`，前者兼容性好但会触发多次，后者只在完成时触发一次。我习惯用`onload`，代码干净。但要注意，`onload`不判断HTTP状态码，404也会进来。所以里面得加一层`if (xhr.status >= 200 && xhr.status < 300)`。曾经有个接口返回401，前端没判断status，直接把错误信息渲染到页面上了，用户看到“未授权”三个字一脸懵。

第四步才是`xhr.send()`。如果是POST，参数在这里传。`send`调用后请求才真正飞出去。这时候可以配合`xhr.timeout`设个超时，或者用`xhr.abort()`取消请求。我做过一个搜索建议的功能，用户每敲一个字就发一次请求，老请求没回来新请求又出去了，结果返回顺序乱了。后来在`send`之前先`abort`掉上一个请求，才算解决。

最后一步是处理响应。`xhr.responseText`拿文本，`xhr.responseXML`拿XML，现在基本都是JSON，用`JSON.parse`转一下。但别忘了`try...catch`，万一后端返回的不是合法JSON，直接抛异常页面就白了。我一般会封装一个函数，把状态判断、解析、错误处理都包进去，调用的时候只传url和成功回调。这样写业务代码时不用每次都重复那五步，也少踩点坑。

这五步走下来，一个完整的ajax请求才算跑通。现在fetch和axios用得多，但底层原理没变。理解这五步，至少调试的时候知道断点打在哪，控制台报错也能看懂是哪个环节出的问题。