fetch() 替代 XMLHttpRequest 需转变思维：基于 Promise、默认不带 Cookie、错误处理更清晰，支持 async/await；一行发起请求，需手动检查 res.ok 处理 4xx/5xx，POST 传参更直观，Cookie 和认证需显式配置。
用 fetch() 替代 XMLHttpRequest 不是简单换函数，而是改写思维：它基于 Promise、默认不带 Cookie、错误处理逻辑更清晰，且天然支持 async/await。
基础请求写法更简洁
XMLHttpRequest 需手动设置状态监听、打开连接、发送数据；而 fetch() 一行发起请求，链式调用处理响应：
- 传统写法要写
xhr.onreadystatechange判断readyState === 4和xhr.status >= 200 && xhr.status -
fetch(url)直接返回 Promise，.then(res => res.json())即可解析 JSON - 注意：
fetch只在网络失败时 reject（如断网、DNS 错误），HTTP 状态码 404、500 不会触发 catch，需手动检查res.ok
发送带参数的 POST 请求更直观
传 JSON 数据不再需要手动设置 Content-Type 头和 JSON.stringify() 序列化（虽然仍需自己做）：
- 统一用
body字段传数据，method: 'POST'显式声明 - 推荐写法：
body: JSON.stringify({ name: 'Alice' })，并配headers: { 'Content-Type': 'application/json' } - 表单提交可用
FormData实例直接传，fetch会自动设置正确的Content-Type（含 boundary）
携带 Cookie 和认证信息需显式配置
fetch 默认不发 Cookie，也不携带 HTTP 认证凭据，这点和 XMLHttpRequest 的默认行为不同：
- 需要 Cookie 时加
credentials: 'include'（跨域时后端还需允许Access-Control-Allow-Credentials: true） - 仅同域可省略，但显式写
credentials: 'same-origin'更清晰 - Bearer Token 推荐放在
Authorization头里：headers: { Authorization: 'Bearer xxx' }
错误处理逻辑更分明
区分「网络异常」和「业务异常」是关键：
-
catch捕获的是网络层错误（如离线、域名不可达），不是 4xx/5xx 响应 - 应在
then中检查response.ok或response.status，再决定是否抛出自定义错误 - 例如：
if (!res.ok) throw new Error(`${res.status} ${res.statusText}`)
不复杂但容易忽略：fetch 是现代标准，语法干净，配合 async/await 几乎可写出同步风格的请求逻辑，只要留意默认行为差异，就能平稳迁移。
