fetch发起GET请求最小写法需手动检查res.ok并调用res.json()；XMLHttpRequest仍不可替代于上传进度、超时控制和中断请求；CORS下fetch重定向静默失败且凭据要求更严格。
fetch API 发起 GET 请求的最小可行写法
直接用 fetch 发 GET 请求不需要额外配置，但必须手动处理响应体和错误边界。很多人以为调用完就完了，其实 fetch 只在网络失败时 reject，HTTP 状态码 404、500 不会触发 catch。
-
fetch返回 Promise，但只在断网、DNS 失败等底层异常时 reject；response.ok才对应 2xx 状态 - 必须显式调用
response.json()或response.text()才能读取响应体，否则只是个流对象 - 默认不带 cookie，跨域请求需加
{ credentials: 'include' }
示例：
fetch('/api/user')
.then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
})
.then(data => console.log(data))
.catch(err => console.error('请求失败:', err));
XMLHttpRequest（传统 AJAX）处理上传进度的真实需求
当你要显示文件上传进度条、中断请求或精细控制超时，XMLHttpRequest 仍是不可替代的。fetch 没有原生上传进度事件，也缺乏 abort() 的简洁接口（虽有 AbortController，但对上传场景支持弱）。
-
XMLHttpRequest.upload.onprogress是唯一标准方式获取上传进度 -
xhr.timeout = 10000设置超时比 fetch 配置更直观 - 调用
xhr.abort()可立即终止正在进行的请求（包括上传中）
示例（带进度）：
立即学习“Java免费学习笔记（深入）”；
const xhr = new XMLHttpRequest();
xhr.open('POST', '/upload');
xhr.upload.onprogress = e => {
if (e.lengthComputable) {
console.log(`上传中：${(e.loaded / e.total * 100).toFixed(0)}%`);
}
};
xhr.send(formData);
fetch 和 XMLHttpRequest 在 CORS 场景下的关键差异
CORS 预检（preflight）行为一致，但凭据（credentials）和重定向处理逻辑不同，容易导致 401 或 302 后拿不到响应。
- fetch 默认
redirect: 'follow'，但遇到 302 重定向且响应头不含Access-Control-Allow-Origin时，会静默失败（浏览器拦截），而 XMLHttpRequest 会暴露 302 响应供你手动处理 - fetch 设
credentials: 'include'时，服务端必须返回Access-Control-Allow-Credentials: true，否则整个请求被屏蔽；XMLHttpRequest 同样要求，但报错信息更明确（控制台提示“CORS 凭据不匹配”） - fetch 无法禁用预检，即使只发简单请求（如 GET + JSON），若手动设了
Content-Type: application/json，也会触发 OPTIONS
何时该坚持用 XMLHttpRequest 而非强行封装 fetch
不是所有场景都适合迁移到 fetch。尤其在遗留系统维护、需要细粒度控制或兼容老版本安卓 WebView 时，硬切 fetch 反而增加风险。
- 安卓 4.4–4.4.4 的 WebView 不支持 fetch（需 polyfill，但 polyfill 无法修复无上传进度的问题）
- 需要复用同一连接发送多个请求（如长轮询心跳包），XMLHttpRequest 的连接复用更可控
- 已有大量基于
xhr.readyState状态机的业务逻辑（如 2: headers received, 3: loading），改写成本高且易出错
真正该警惕的是“为新而新”——比如用 fetch 封装一个连 timeout 都要靠 AbortController + setTimeout 拼凑的请求函数，反而比几行 xhr 更难 debug。
