AJAX 与 Fetch：异步 Web 请求实战对比

在 Web 开发里，异步数据获取是构建动态应用的核心。从早期的 AJAX 到现在的 Fetch API，选择多了，但也带来了困惑。这两种主流技术究竟有何不同？在实际项目中该如何选择？我们直接从解决问题的角度出发，看看它们的差异与适用场景。

AJAX：技术本质与核心原理

AJAX（Asynchronous JavaScript and XML）这个术语由 Jesse James Garrett 于 2005 年提出，它并非单一技术，而是一套技术集合的统称——包括 XMLHttpRequest 对象、DOM 操作、JavaScript 以及 XML 或 JSON 数据格式。这种组合拳使得网页能够在不刷新的情况下与服务器交换数据，从而带来了 Web 2.0 时代的革命。

// 传统 AJAX 请求示例
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/data', true);
xhr.onreadystatechange = function() {
  if (xhr.readyState === 4 && xhr.status === 200) {
    const response = JSON.parse(xhr.responseText);
    console.log(response);
  }
};
xhr.send();

实际开发中的优势场景

尽管常被视为'传统'技术，AJAX 在某些场景下仍具有不可替代的优势：

浏览器兼容性是其最强大的武器。从 IE7 到现代浏览器，AJAX 几乎实现了全覆盖。如果你的项目需要支持老旧浏览器（如某些企业内网应用），AJAX 几乎是唯一的选择。

进度监控能力在文件上传等场景中尤为重要。通过监听 progress 事件，开发者可以轻松实现上传进度条：

xhr.upload.onprogress = function(event) {
  if (event.lengthComputable) {
    const percentComplete = (event.loaded / event.total) * 100;
    updateProgressBar(percentComplete);
  }
};

请求取消功能是 AJAX 的另一个亮点。在某些交互复杂的应用中，用户可能需要在请求中途取消操作，AJAX 通过 abort() 方法提供了这一能力。

痛点与局限性

不过，回头看 AJAX 的设计，确实显露出时代的局限。其回调地狱问题尤为突出：多个异步请求嵌套时，代码迅速变得难以维护。错误处理也不够优雅——开发者需要同时检查 readyState 和 status 才能确定请求状态。

此外，AJAX 默认不支持 Promise，这在现代 JavaScript 开发中显得格格不入。虽然可以通过封装解决，但毕竟是额外的工作量。

Fetch API：设计理念的革新

Fetch API 是 Web 标准的重大进步，它从设计之初就拥抱了 Promise 这一现代异步编程模型。这种设计哲学上的差异，使得 Fetch 天生具有更好的可读性和可维护性。

// Fetch 基础用法
fetch('/api/data')
  .then(response => {
    if (!response.ok) {
      throw new Error('网络响应异常');
    }
    return response.json();
  })
  .then(data => console.log(data))
  .catch(error => console.error('请求失败:', error));

现代开发中的显著优势

简洁的语法是 Fetch 最直观的优点。相比 AJAX 繁琐的配置，Fetch 通过链式调用让代码逻辑更加清晰。与 async/await 结合使用时，这种优势更加明显：

async function loadData() {
  try {
    const response = await fetch('/api/data');
    const data = await response.json();
    return processData(data);
  } catch (error) {
    handleError(error);
  }
}

更灵活的请求控制是 Fetch 的另一大亮点。通过 Request 和 Response 对象，开发者可以精细控制请求的各个方面：

// 复杂请求配置
const controller = new AbortController();
const signal = controller.signal;
setTimeout(() => controller.abort(), 5000); // 5 秒后取消请求

fetch('/api/data', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${token}`
  },
  body: JSON.stringify({ key: 'value' }),
  mode: 'cors',
  cache: 'no-cache',
  signal: signal // 支持请求取消
});

服务端渲染 (SSR) 友好性在现代前端框架中尤为重要。Fetch 在 Node.js 环境下也有良好的支持，为同构应用开发提供了便利。

不得不面对的挑战

当然，Fetch 并非完美无缺。错误处理可能是最让开发者困惑的一点——Fetch 只有在网络故障时才会拒绝 Promise，HTTP 错误状态（如 404、500）不会触发 catch。这种设计需要开发者额外的判断逻辑。

缺乏超时控制是另一个痛点。虽然可以通过 AbortController 模拟，但毕竟不是原生支持。此外，不支持进度监控使得大文件上传场景中，Fetch 不如 AJAX 方便。

实战对比：不同场景下的技术选型

企业级应用开发

在大型企业应用中，浏览器兼容性通常是首要考虑因素。如果用户群体中包含 IE11 用户，AJAX 或配合 polyfill 的 Fetch 是必选项。不过，随着微软停止支持 IE，这一限制正逐渐减弱。

对于需要精细控制请求过程的场景，如分片上传、实时进度显示，AJAX 仍是更好的选择。下面的对比表格总结了核心差异：

特性	AJAX	Fetch
语法复杂度	较高	较低
Promise 支持	需封装	原生支持
错误处理	状态码检查	HTTP 错误不拒绝
请求取消	原生支持	通过 AbortController
进度监控	原生支持	不支持
浏览器支持	广泛	现代浏览器
超时控制	原生支持	需手动实现

现代 SPA 与 PWA 项目

对于 React、Vue 等现代框架构建的应用，Fetch 通常是更自然的选择。其 Promise-based 设计与现代 JavaScript 生态完美契合，配合 TypeScript 使用时类型推断也更加友好。

// 基于 Fetch 的 TypeScript 封装
interface ApiResponse<T> {
  data: T;
  status: number;
}

async function fetchAPI<T>(url: string, options?: RequestInit): Promise<ApiResponse<T>> {
  const response = await fetch(url, options);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}: ${response.statusText}`);
  }
  const data = await response.json() as T;
  return { data, status: response.status };
}

渐进增强策略

在实际项目中，渐进增强是明智的选择。可以创建一个统一的请求层，根据环境自动选择最佳方案：

class HttpService {
  constructor() {
    this.supportsAbort = typeof AbortController !== 'undefined';
  }

  async request(url, options = {}) {
    // 根据需求选择底层实现
    if (options.needProgress) {
      return this.ajaxRequest(url, options);
    }
    // 现代浏览器使用 Fetch
    if (window.fetch && !options.forceAjax) {
      return this.fetchRequest(url, options);
    }
    // 降级到 AJAX
    return this.ajaxRequest(url, options);
  }
  // 封装两种实现...
}

性能考量与最佳实践

性能差异分析

在性能层面，AJAX 和 Fetch 的差异并不显著。多数场景下，网络延迟和数据处理才是瓶颈所在。不过，Fetch 在某些方面确有优势：

• 更少的样板代码意味着更小的脚本体积
• 更好的错误边界有助于避免内存泄漏
• 与 Service Worker 的集成为 PWA 提供了更好支持

实用建议与技巧

超时处理的通用方案：

function fetchWithTimeout(url, options = {}, timeout = 10000) {
  const controller = new AbortController();
  const { signal } = controller;
  const timeoutId = setTimeout(() => controller.abort(), timeout);
  
  return fetch(url, { ...options, signal })
    .finally(() => clearTimeout(timeoutId));
}

**进度监控的替代方案：**对于大文件上传，可以考虑分片上传或使用专门的库。

错误处理的完整封装：

async function safeFetch(url, options) {
  try {
    const response = await fetch(url, options);
    if (response.status === 401) {
      // 处理认证过期
      return handleAuthExpiry();
    }
    if (response.status === 429) {
      // 处理限流
      return handleRateLimit();
    }
    if (!response.ok) {
      throw new HttpError(response.status, await response.text());
    }
    return await response.json();
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('请求被取消');
      return null;
    }
    if (!navigator.onLine) {
      // 处理离线状态
      return getCachedData(url);
    }
    throw error;
  }
}

随着 Web 标准的演进，Fetch API 正在不断完善。Fetch 的流式 API、请求优先级等新特性正在逐步落地。与此同时，基于 Fetch 的更高级抽象如 React Query、SWR 等库的出现，进一步简化了数据获取的复杂度。

那么，在实际项目中应该如何选择？我们的建议是：

• **新项目优先考虑 Fetch：**除非有明确的兼容性要求，Fetch 是现代项目的自然选择
• **存量项目渐进迁移：**在维护现有代码时，可以逐步将 AJAX 替换为 Fetch
• **根据具体需求灵活选择：**需要进度监控或广泛兼容性时，AJAX 仍有价值

归根结底，技术选型服务于业务需求。理解每种技术的特性与适用场景，才能在实际开发中做出明智的决策。无论是 AJAX 还是 Fetch，最终目标都是为用户提供流畅、可靠的 Web 体验——这正是我们作为开发者的共同追求。