Fetch API与XMLHttpRequest对比解析

本文深入对比了现代前端开发中两大核心网络请求技术——Fetch API与XMLHttpRequest，揭示了它们在异步模型（Promise vs 事件驱动）、Cookie处理、上传进度支持、请求取消机制、超时控制及浏览器兼容性等方面的关键差异与实际踩坑点；既阐明fetch简洁优雅、已成为主流选择的优势，也客观指出XMLHttpRequest在大文件上传进度监控、细粒度状态管理及老旧环境兼容上的不可替代性，帮助开发者根据真实业务场景理性选型，避免“为新而新”的技术误用。

fetch 是 Promise 驱动，XMLHttpRequest 是事件回调驱动

这是最根本的差异：调用 fetch() 立即返回一个 Promise，你用 .then() 或 async/await 处理响应；而 XMLHttpRequest 必须监听 onload、onerror、onprogress 等事件，手动管理状态（readyState）。

这意味着：

• fetch() 默认不带错误状态码拦截（如 404、500 仍进 then），需手动检查 response.ok
• XMLHttpRequest 的 onerror 只在真正网络失败时触发（如断网、DNS 失败），而 fetch() 的 catch 也只捕获这类异常，不是 HTTP 错误
• 取消请求方式不同：fetch() 依赖 AbortController；XMLHttpRequest 直接调用 .abort()

fetch 不支持同步请求，XMLHttpRequest 支持但已被弃用

XMLHttpRequest 构造时传入 false 第三个参数可发起同步请求（阻塞主线程），但现代浏览器已禁用该能力（抛出 DOMException: Synchronous XMLHttpRequest on the main thread is not allowed）。fetch() 从设计上就不支持同步——它只能是异步的。

所以实际开发中：

• 不必再纠结“要不要用同步”，两者都只能异步
• 若需等待多个请求完成，fetch() 配合 Promise.all() 更自然；XMLHttpRequest 得靠计数器或封装 Promise
• 服务端超时控制逻辑位置不同：fetch 通常靠 AbortController.timeout()（需 polyfill 或自行实现）；XMLHttpRequest 直接设 .timeout 属性

fetch 默认不发 cookie，XMLHttpRequest 默认发送（同域下）

fetch() 的 credentials 选项默认是 'omit'，即跨域或同域都不带 Cookie；XMLHttpRequest 在同域下默认携带 Cookie（只要没显式设 withCredentials = false）。

常见踩坑点：

• 登录态接口突然 401？很可能是 fetch() 没加 { credentials: 'include' }
• 跨域请求要带 Cookie，后端必须响应 Access-Control-Allow-Origin 具体域名（不能是 *），且 credentials: 'include' 缺一不可
• XMLHttpRequest 设 withCredentials = true 后，预检请求（OPTIONS）也会带上认证头，需后端配合

fetch('/api/user', {
  credentials: 'include'
})

fetch 对上传进度无原生支持，XMLHttpRequest 有 upload.onprogress

如果你要做大文件上传并显示进度条，XMLHttpRequest 是更直接的选择。它的 xhr.upload.onprogress 能拿到 loaded 和 total 字节数；fetch() 本身不暴露上传过程，得靠 ReadableStream + TransformStream 手动分块读取并上报进度（复杂且兼容性差）。

折中方案：

• 小文件或无需进度 → 用 fetch() 更简洁
• 明确需要上传进度 → 保留 XMLHttpRequest，尤其还要兼容 Safari 15.4 以下或旧 Android
• 想统一用 fetch？可封装 fetch + FormData + 自定义流监控，但代码量和调试成本显著上升

好了，本文到此结束，带大家了解了《Fetch API与XMLHttpRequest对比解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！