Fetch API 是 Promise-based 且支持 async/await，但成功 resolve 不代表 HTTP 成功（需检查 response.ok），默认不带 Cookie、无超时和上传进度监听，错误处理仅覆盖网络层而非 HTTP 状态码。
Fetch API 是 Promise-based，而传统 Ajax（XMLHttpRequest）是事件驱动
这意味着 fetch() 天然支持 async/await 和链式 .then()，不用手动监听 onreadystatechange 或判断 readyState === 4。但也要注意：fetch() 成功返回的 Promise 并不等价于 HTTP 成功（比如 404、500 仍会 resolve），必须显式检查 response.ok 或 response.status。
-
XMLHttpRequest需要手动设置open()、send()、监听load或error事件 -
fetch()默认只 reject 网络失败（如断网、DNS 错误），HTTP 状态码异常不会触发catch - 没有内置超时机制 ——
XMLHttpRequest可设timeout属性，fetch()得靠AbortController模拟
默认不带 Cookie，传统 Ajax 默认携带
这是最常踩的坑：fetch() 默认 credentials 为 'omit'，跨域请求完全不发 Cookie；而 XMLHttpRequest 在同域或设置了 withCredentials = true 后会自动带上。
- 需要鉴权时，必须显式传
{ credentials: 'include' }（或'same-origin'） - 若后端用
Access-Control-Allow-Origin: *，则不能设credentials: 'include'，否则浏览器直接拒绝请求 - 服务端需配
Access-Control-Allow-Credentials: true且Access-Control-Allow-Origin不能为通配符
不支持上传进度监听，XMLHttpRequest 支持 upload.onprogress
如果要做文件上传进度条，fetch() 无法原生满足 —— 它没有类似 XMLHttpRequest.upload.onprogress 的钩子。目前只能靠 ReadableStream + TransformStream 手动分块读取并计算进度（兼容性差），或退回到 XMLHttpRequest。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
fetch()的body是一次性写入的，无法中途拦截或观测发送过程 -
XMLHttpRequest的upload对象暴露了onprogress、onloadstart、onloadend等完整生命周期 - 某些 polyfill（如
whatwg-fetch）也不补全上传进度能力
错误处理逻辑完全不同：网络失败 vs HTTP 错误
很多人以为 catch 能捕获 404，结果发现根本进不去 —— 因为 fetch() 对 404、500 这类响应仍视为“成功”，只是返回一个 Response 对象。真正的错误只有网络层中断、CORS 拒绝、URL 解析失败等。
立即学习“Java免费学习笔记（深入）”；
fetch('/api/user')
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
return response.json();
})
.catch(err => {
// 这里只捕获网络错误、AbortError、CORS 错误等
// 404/500 不会进到这里，除非上面手动 throw
});
-
response.status是数字，response.statusText是字符串（如'Not Found'） -
response.type可区分'basic'、'cors'、'opaque'，影响能否读取headers或body - 流式读取（
response.body.getReader()）不可重复消费，调过json()就不能再调text()
fetch() 不只看“新旧”，得看有没有上传进度、是否依赖 Cookie、后端 CORS 配置是否配合 —— 很多看似简单的迁移，卡在 credentials 和 response.ok 上。 
