解构 XMLHttpRequest ：从 ActiveX 雏形到今日 Web 的异步驱动器

在现代浏览器里，XMLHttpRequest（简称 XHR）仍然活跃 —— 尽管它诞生于上世纪末，并已被 fetch 等更优雅的 API 所取代。XHR 让 JavaScript 能在后台发起 HTTP 请求、无刷新地更新页面，从而孕育出 Ajax 革命；理解它的工作机制与局限，依旧是前端性能优化、兼容性调试与安全设计的重要环节。下文将沿时间脉络与执行流程，拆解 XHR 的历史渊源、接口语义、浏览器内部实现、典型用例及未来走向，并辅以真实案例与代码片段帮助建立直观认知。

1 诞生脉络：从 ActiveX 控件到 Ajax 思维

1999 年，微软 Exchange 团队为 Outlook Web Access 编写了名为 XMLHTTP 的 ActiveX 控件，赋予脚本跨网络送受 XML 数据的能力，这正是 XHR 的原型。(Hacker News)

IE 5 将该控件内置后，前端开发者第一次获得浏览器内的异步通信手段。(Microsoft Support)

2002 — 2004 年间，Mozilla、Safari 与 Opera 相继实现了同名原生对象；这让技术顾问 Jesse James Garrett 在 2005 年发表著名文章，把这种异步组合技术命名为 Ajax（Asynchronous JavaScript And XML），自此 XHR 成为“富交互”网页的代名词。(Wikipedia, WIRED, WIRED)

为了统一行为，WHATWG 与 W3C 于 2006 年启动 XHR 规范化工作，如今的“Living Standard”已托管在 WHATWG。(W3C GitHub)

2 接口总览：属性、方法与状态机

2.1 核心属性

• readyState — 请求生命周期的五个整数阶段（0 未初始化，1 已调用 open，2 已发送，3 接收中，4 已完成）。(MDN Web Docs)

• responseType / response / responseText / responseXML — 决定返回体解析形式，可是纯文本、JSON、Blob 乃至文档节点。(MDN Web Docs)

• status / statusText — 承载 HTTP 状态码与短语，为错误处理与重试逻辑提供依据。(MDN Web Docs)

  2.2 常用方法

  步骤	调用签名	作用概述
  初始化	xhr.open(method, url, async = true, user, password)	绑定目标资源并重置内部状态
  配置	xhr.setRequestHeader(name, value)	在已调用 open 之后、send 之前设置自定义请求头
  触发传输	xhr.send(body)	真正把字节流写入网络层；若省略参数则发送 GET
  中断	xhr.abort()	用户或脚本可随时取消，抛出 onabort 事件

  所有方法均派生自事件目标接口，因此可以通过 addEventListener 订阅 load、error、progress 等事件，构建精细化数据流。(MDN Web Docs)

  2.3 事件驱动状态机

  浏览器网络线程在数据包到达时更新 readyState 并排队相应事件；渲染主线程在下一个任务切片将事件分发给 JS 回调。该设计利用浏览器事件循环避免了阻塞渲染。(MDN Web Docs)

  3 浏览器内部执行路径

  1. 主线程创建实例 → 绑定事件处理器。

  2. 调用 open 时，JS 引擎通过 DOM Bindings 把命令转交网络栈；同时把 URL 与请求参数持久化到对象槽位。

  3. 调用 send 触发异步任务：网络服务线程根据同源策略检查可达性，再写入 socket。

  4. TCP 层陆续收包，数据交由 HTML 解析器或 MIME 分发器生成合适的 responseType。

  5. 网络服务线程通过任务队列向主线程投递 readystatechange 与终结事件；主线程回调 JS，开发者即可读取 response。

     
     （图片来源网络，侵删）

  这种跨线程协作的模型为 Ajax 带来“局部刷新”能力，也暗藏竞争条件与内存泄漏风险，调试时可借助浏览器 DevTools 的 Network 面板及 Event Listener Breakpoint 定位。(MDN Web Docs)

  4 安全模型与局限

  4.1 同源策略与 CORS

  XHR 默认受同源策略限制：协议、域名、端口三元组须完全一致。不然将抛出 NetworkError 并拒绝响应。为合法跨域，服务器需返回 Access-Control-Allow-Origin 头部，让浏览器通过 CORS 校验。(MDN Web Docs)

  
  （图片来源网络，侵删）

  withCredentials 属性还能控制是否发送 cookie / Authorization 头，但 CORS 预检必须在响应中显式允许。(MDN Web Docs)

  4.2 同步请求被废弃

  规范已将主线程同步 XHR 标记为禁用场景；Chrome 与 Firefox 在用户地交互上下文外拒绝执行，以防 UI 阻塞。(Stack Overflow)

  5 实际案例：XHR 拉取 GitHub 用户数据

  const xhr = new XMLHttpRequest();
  xhr.open('GET', 'https://api.github.com/users/octocat');
  xhr.responseType = 'json';
  xhr.addEventListener('load', () => {
    if (xhr.status === 200) {
      const { login, public_repos } = xhr.response;
      document.body.innerHTML =
        `
  用户名：${login}
  公开仓库：${public_repos}
  `;
    }
  });
  xhr.send();
  
  

  在上述示例里，浏览器后台发起 GET 请求，不刷新页面即可把 octocat 的仓库统计渲染到 DOM，恰是 Ajax 精神的缩影。该模式仍常见于老旧代码库、脚本注入扩展或需要精细事件流控制的上传监控。(MDN Web Docs)

  6 性能观察：XHR 与 fetch 的对比

  在底层网络流程里，两者都调用相同的浏览器传输栈，因此 TTFB 与下载耗时并无本质差异；然而 fetch 的 Promise 封装允许微任务调度，JSON 解析能在 JS 引擎内部并行优化，代码也更易阅读，对高并发更友好。(Medium, Go Make Things)

  迁移到 fetch 时，要格外注意超时与进度事件的 API 差异，以及 IE11 等旧内核缺乏原生支持的兼容策略。

  7 何时仍需 XHR？

  • 流式上传：upload.onprogress 提供细粒度回调，直至 fetch 的 ReadableStream 在所有主流浏览器稳定之前仍具优势。(MDN Web Docs)

  • 老旧框架：如 jQuery 1.x 的 $.ajax() 默认内部用 XHR；企业级遗留系统往往大量依赖。

  • 同步 Worker 场景：Web Worker 内允许同步 XHR，用于简化脚本化 build 流；但应谨慎使用以免阻塞 Worker 线程。

    8 展望：Web 规范的下一站

    随着 fetch、Streams API、WebSocket 与 WebTransport 日渐成熟，XHR 的新增特性已基本冻结。WHATWG 版本仅维护安全补丁与兼容性细节；未来主流浏览器或许会把 XHR 纳入“兼容层”，鼓励开发者采用更现代的网络接口。但在某些长尾场景，它仍会像 DOM 2 API 那样长期存活。(Stack Overflow, W3C GitHub)

    ---

    结语

    XHR 把 Web 从“超文本浏览”推进到“富交互应用”，为今日的实时协作与单页架构奠定基础。理解它的事件模型、同源约束与性能特征，不仅能维护遗留系统，也能帮助我们在 fetch、WebSocket 等新技术中做出更优的工程决策。