fetch更现代但默认不带cookie，需显式设置credentials；XMLHttpRequest更底层兼容性好但写法冗长；fetch无progress事件、错误处理不按HTTP状态码，IE完全不支持；选型取决于是否需支持IE及精细控制请求生命周期。
用 fetch 更简单、更现代，但默认不带 cookie；XMLHttpRequest 更底层、兼容性更好，但写法冗长、错误处理麻烦。选哪个，得看你要不要支持 IE，以及是否需要精细控制请求生命周期。
fetch 默认不发 cookie，XMLHttpRequest 默认发
这是最常踩的坑：调用 fetch('/api/user') 时，即使用户已登录，后端可能收不到 session cookie，导致 401。因为 fetch 默认的 credentials 是 'omit'；而 XMLHttpRequest 在同域下会自动带上 cookie。
修复方式：
-
fetch必须显式加{ credentials: 'include' }（或'same-origin'） -
XMLHttpRequest不用额外设置，但若跨域，后端需返回Access-Control-Allow-Credentials: true，且不能设Access-Control-Allow-Origin: *
fetch('/api/data', {
credentials: 'include'
});fetch 没有 progress 事件，XMLHttpRequest 可监听上传/下载进度
做文件上传、大图加载时，需要显示进度条——fetch 原生不支持；XMLHttpRequest 的 upload.onprogress 和 onprogress 能直接拿到 event.loaded 和 event.total。
立即学习“Java免费学习笔记（深入）”；
替代方案（fetch）：
- 用
ReadableStream手动读取响应体（仅支持现代浏览器） - 把大文件分块上传，用每次 fetch 的完成来模拟进度
- 干脆换回
XMLHttpRequest，几行就能搞定
const xhr = new XMLHttpRequest();
xhr.upload.onprogress = (e) => {
if (e.lengthComputable) {
console.log(`${e.loaded / e.total * 100}%`);
}
};fetch 错误处理不按 HTTP 状态码走，XMLHttpRequest 需手动判断 status
fetch 只在网络断开、DNS 失败、跨域拒绝等真正“请求没发出去”时才 reject；404、500 这类响应照样进 .then()。而 XMLHttpRequest 的 onload 总是触发，你得自己检查 xhr.status。
所以实际使用中：
-
fetch后必须加response.ok或response.status >= 200 && response.status 判断业务失败 -
XMLHttpRequest要在onload里写if (xhr.status >= 400)才算错误处理 - 两者都建议统一包装一层，避免每个请求都重复判状态
fetch('/api/post').then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
});IE 完全不支持 fetch，XMLHttpRequest 兼容到 IE5
如果你的项目还要跑在 IE11 或更老环境里，fetch 必须配 polyfill（如 whatwg-fetch），但 polyfill 无法补全 AbortController 等特性；XMLHttpRequest 则开箱即用，连 IE6 都能跑。
不过要注意：
- IE8–9 不支持
addEventListener，得用xhr.onreadystatechange - IE 对 CORS 的实现有差异，比如预检请求（OPTIONS）有时会被忽略或缓存异常
- 现代项目若已放弃 IE，
fetch+async/await组合明显更简洁
真正难的不是语法，而是什么时候该用 credentials: 'include'，什么时候该手动检查 response.status，还有——别忘了在服务端配好 CORS 头，否则两个 API 都会静默失败。
