JavaScript网络请求实战：Fetch API与Ajax数据交互

在前端应用开发中，从服务端动态加载列表、提交表单数据或是实时轮询状态，都离不开网络数据交互。现代 JavaScript 主要依托两套原生机制完成请求：一套是历史悠久的 XMLHttpRequest（即 Ajax 技术的基石），另一套是基于 Promise 规范、语法高度集成的 Fetch API。本文将直接从请求构造、状态处理、异常捕获到高级并发控制，梳理实际编码中两者的运用逻辑与工程落地方案。

一、经典 Ajax 与 XMLHttpRequest 的底层机制与局限

Ajax（Asynchronous JavaScript and XML）不是单一技术，而是利用浏览器脚本与服务器交换数据并局部更新页面的技术模式。在 Fetch 诞生前，浏览器实现 Ajax 交互完全依赖于 XMLHttpRequest（XHR）对象。XHR 采用事件驱动模型，通过监听就绪状态变化（readyState）和网络事件来驱动回调。

这种机制虽然稳定且对文件上传进度等底层事件支持完善，但其代码组织依赖事件侦听器与嵌套函数，在连续调用多个有先后依赖的接口时，极易陷入多层嵌套的回调地狱；同时，配置请求参数、序列化载荷以及处理错误分散在各个阶段，使得逻辑分散难以维护。

图 1：XMLHttpRequest 事件监听模型与 Fetch API 异步流机制对比

以下是使用传统 XHR 发起 POST 请求并提交 JSON 数据的典型写法：

function sendPostByXHR(url, payload) {
  const xhr = new XMLHttpRequest();
  xhr.open('POST', url, true);
  
  // 必须手动显式设置请求头
  xhr.setRequestHeader('Content-Type', 'application/json;charset=UTF-8');
  
  xhr.onreadystatechange = function () {
    // readyState 为 4 表示数据传输完毕
    if (xhr.readyState === 4) {
      if (xhr.status >= 200 && xhr.status < 300) {
        try {
          const responseData = JSON.parse(xhr.responseText);
          console.log('XHR 请求成功:', responseData);
        } catch (parseError) {
          console.error('响应反序列化失败:', parseError);
        }
      } else {
        console.error('HTTP 状态异常:', xhr.status, xhr.statusText);
      }
    }
  };

  xhr.onerror = function () {
    console.error('发生网络级别故障，无法连接服务器');
  };

  xhr.send(JSON.stringify(payload));
}

这段代码体现了 XHR 的若干繁琐之处：状态检查需要同时结合 readyState 与 status；JSON 数据解析需要手动包裹 try...catch；更重要的是，其异步逻辑与主流程天然割裂，无法直接通过 async/await 享受线性的代码编排能力。

二、Fetch API 核心语法与双阶段 Promise 流程

Fetch API 是浏览器环境原生的现代标准，全面拥抱 Promise。它将网络交互解耦为“连接建立与响应头接收”和“响应体内容读取与反序列化”两个阶段。这种双阶段设计不仅带来了流式处理（Streaming）能力，也彻底统一了请求的链式调用形态。

图 2：Fetch API 生命周期与双阶段 Promise 执行链路

结合 async/await 的标准 Fetch 封装范式如下：

/**
 * 发送标准 JSON POST 请求
 * @param {string} url - 目标接口地址
 * @param {object} data - 提交的对象数据
 * @returns {Promise<any>} 服务端响应结果
 */
async function postData(url = '', data = {}) {
  try {
    const response = await fetch(url, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json'
      },
      // 携带跨域 Cookie 等认证信息（按需开启）
      credentials: 'same-origin',
      body: JSON.stringify(data)
    });

    // 重点：检查响应状态是否在 200~299 区间
    if (!response.ok) {
      throw new Error(`HTTP 异常错误: ${response.status} ${response.statusText}`);
    }

    // 第二阶段：异步流解析为 JavaScript 对象
    const result = await response.json();
    return result;
  } catch (error) {
    // 捕获网络断开、DNS失败或主动抛出的状态异常
    console.error('网络请求执行失败:', error.message);
    throw error;
  }
}

三、实战高频进阶：超时重试、请求取消与凭证传递

在实际生产项目中，单纯发送请求是远远不够的。移动端弱网环境下的请求超时、用户快速切换页面时的无用请求丢弃、以及输入框搜索联想中的竞态问题，都需要前端具备精确控制请求生命周期的能力。

在过去的 XHR 中，我们可以直接调用 xhr.abort() 或设置 xhr.timeout。而在 Fetch API 中，这一能力通过标准的 AbortController 接口实现：

图 3：基于 AbortController 的请求取消与超时熔断控制

通过为 Fetch 注入 signal，我们可以封装一个具备超时熔断机制的健壮通用请求函数：

/**
 * 带有超时控制的 Fetch 包装器
 * @param {string} url - 请求 URL
 * @param {object} options - fetch 选项
 * @param {number} timeout - 超时时间，默认 8000ms
 */
async function fetchWithTimeout(url, options = {}, timeout = 8000) {
  const controller = new AbortController();
  const { signal } = controller;

  // 定时器触发后调用 abort() 终止请求
  const timer = setTimeout(() => {
    controller.abort();
  }, timeout);

  try {
    const response = await fetch(url, {
      ...options,
      signal
    });

    if (!response.ok) {
      throw new Error(`请求响应非成功状态: ${response.status}`);
    }

    return await response.json();
  } catch (err) {
    if (err.name === 'AbortError') {
      console.warn(`请求由于超过 ${timeout}ms 被主动熔断取消`);
      throw new Error(`网络请求超时，请检查网络后重试`);
    }
    throw err;
  } finally {
    // 无论是成功返回还是发生异常，均需清理定时器以防内存泄漏
    clearTimeout(timer);
  }
}

四、技术选型对比与综合总结

在面对复杂的前端工程时，开发者往往在原生 XHR、现代 Fetch API 以及第三方封装库（如 Axios）之间进行权衡。了解它们的优劣与适用边界，有助于构建更轻巧、可维护的网络抽象层。

图 4：前端异步数据交互技术选型决策全景图

为更直观比对细节差异，以下汇总了在实际开发决策中最常考量的特性对照表：

五、实战排错与总结建议

在日常排查网络交互问题时，建议遵循以下清单排查：

1. 确认是否发生跨域（CORS）阻断：若控制台报错“Access-Control-Allow-Origin”，应排查服务端响应头设置；Fetch 遇到 CORS 报错会直接拒绝 Promise，catch 捕获到的错误信息通常为通用的 TypeError: Failed to fetch。
2. 区分网络异常与业务错误：严格编写 if (!response.ok) 判断，勿将服务端的 401 鉴权失效或 500 服务器崩溃直接跳过流入 response.json()，否则可能因服务端返回 HTML 错误页面而诱发“Unexpected token < in JSON at position 0”的二次崩溃。
3. 正文不可重复读取：一个 Response 对象的 Body 流在执行过一次 res.json() 或 res.text() 后即被锁定，如果业务层需要多次使用，请先使用 response.clone() 复制响应。

综合来看，现代前端网络数据交互已经全面过渡至以 Fetch API 为基础的现代标准。掌握其双阶段异步生命周期、熟悉 AbortController 控制逻辑并做好异常拦截，便能以最精简的原生代码支撑起高稳定性、高响应性的 Web 数据交互层。