原生与现代的对话：异步请求的技术抉择
当我们谈论优化异步请求时，一个常见的误区是混淆了概念。首先要澄清一点：所谓“HTML Ajax”其实是个伪命题。异步 Ja vaScript 和 XML，也就是我们常说的 Ajax，它从来不是 HTML 的特有技术，而是前端 Ja vaScript 发起非阻塞 HTTP 请求的一套方法统称。底层实现，始终围绕着两大核心：老牌的XMLHttpRequest和现代的fetch() API。这个概念上的一字之差，常常在实践中导致不必要的调试困局和兼容性误判。
为什么 fetch() 比 XMLHttpRequest 更对现代开发者的胃口
先说核心结论：对于新项目而言，fetch() 通常是更优选。这背后有几个硬核理由：它原生拥抱 Promise，让代码告别了层层嵌套的回调地狱，逻辑一下子清爽多了。安全方面也更胜一筹，默认不携带 Cookie 的设计，从源头上减少了跨站请求伪造的风险。它的错误处理逻辑也更为分明——这里有个关键细节，fetch() 只有在网络层面彻底失败时才会 reject，像 404 或 500 这类“服务器成功响应了错误”的情况，它仍会 resolve。这意味着你得主动检查 response.ok 或 response.status。
当然，fetch() 也并非开箱即用，它的默认行为有些“纯粹”，需要开发者手动补全：
- JSON 解析？得手动来：拿到
Response后，必须显式调用response.json()才能得到对象。 - 超时控制？没有自带：想要给请求设限，得请出
AbortController这位搭档来帮忙。 - 携带凭证？要主动声明：发送 Cookie 或 HTTP 认证信息，得手动加上
{ credentials: 'include' }。 - 上传进度？无法监听：对于大文件上传，想跟踪进度条？那还得回退到
XMLHttpRequest的老办法。
XMLHttpRequest 就此过时了吗？看场景说话
答案是否定的。在某些需要“精雕细琢”的场景下，XMLHttpRequest 仍然无可替代，值得每一位前端开发者掌握。比如前面提到的，大文件上传时通过 upload.onprogress 实现丝滑的进度反馈。再比如，那些还需要为 Internet Explorer 11 留有余地的项目，fetch() 并不在 IE 的支持清单上。
不过，用它就得格外小心，有几个“坑”需要绕行：
readyState === 4只是通信结束，不代表成功。别忘了检查xhr.status >= 200 && xhr.status < 300。- 解析 JSON 数据得自己动手：
JSON.parse(xhr.responseText)，一旦数据格式有误，错误很可能被吞掉。 - 设置请求头的时机很关键：必须在
xhr.open()之后，又在xhr.send()之前，顺序错了就无效。 - 在 IE 中，别指望
xhr.responseType = 'json'能自动解析：老老实实用JSON.parse()吧。
比选型更重要的东西：你的异步请求策略
说到底，影响用户体验的，往往不是你选用了fetch()还是XMLHttpRequest，而是你的请求策略本身。仅仅换一个 API 或封装一个库，并不会带来性能的飞跃。关键在于，你如何组织和管控这些请求。
立即学习“前端免费学习笔记（深入）”；
- 避免无谓的重复: 对参数相同的 GET 请求，可以在内存中做一个简单的缓存（比如用
Map存储“URL → Promise”的映射），同一个请求短时间内只发一次。 - 学会打包合并: 当页面需要用户的“基本信息”和“权限列表”时，与其在前端并行发送两个请求，不如优先推动后端提供一个聚合接口，一次请求搞定所有数据。
- 设计降级方案: 当
fetch()失败时，是回退到本地配置的 Mock 数据，还是展示上一次成功的响应？这需要根据业务允许范围来设计。 - 及时取消冗余请求: 在单页面应用的路由跳转，或者在搜索框的防抖逻辑里，利用
AbortController去中止那些已经“过时”的请求，能有效减轻网络和处理压力。
话说回来，一个最容易被忽略的常识是：后端接口的响应时间（比如几百毫秒到几秒），往往远远超过前端从XMLHttpRequest切换到fetch()所带来的毫秒级提升。所以，优化前第一步，永远是打开浏览器的开发者工具，看看 Network 面板：到底是 DNS 解析慢、TLS 握手久，还是首字节时间（TTFB）过长，又或者是后端处理本身就慢。找准真正的瓶颈，比盲目重写请求逻辑要高效得多。
