Fetch API 默认不带 Cookie、不自动抛错、不将 4xx/5xx 视为异常；Promise 仅在网络失败或 request 构造失败时 reject；需用 response.ok 或 status 判断业务状态；发送 Cookie 需设 credentials 选项；response.json() 等方法不可重入；上传文件勿手动设 Content-Type；必须用 AbortController 控制超时和取消。
Fetch API 不是 Promise 封装的“更高级 axios”，它默认不带 cookie、不自动抛错、不识别 4xx/5xx 状态码为异常——这些不是 bug，是设计选择。
fetch() 返回的 Promise 什么时候会 reject？
只在网络失败（如断网、DNS 错误、请求被 CORS 阻止）、或 request 对象构造失败时 reject。HTTP 状态码如 404、500 不会触发 reject，response.ok 才是判断业务成功的可靠依据。
- 错误写法：
fetch('/api/user').then(data => {...}).catch(err => {...})—— 这里catch永远捕获不到401 - 正确做法：始终检查
response.ok或response.status - 常见坑：用
async/await却忘了加if (!res.ok) throw new Error(...)
如何发送带 Cookie 的请求？
默认情况下 fetch 不发送 Cookie，也不接收 Set-Cookie 响应头，必须显式配置 credentials 选项。
- 要发 Cookie（且后端允许）：传
{ credentials: 'include' } - 仅当 origin 匹配才发（推荐多数场景）：用
'same-origin' - 完全禁用 Cookie（等价于 XMLHttpRequest 的
withCredentials=false）：用'omit'（默认值） - 注意：若设为
'include'，后端响应必须带Access-Control-Allow-Origin: *不生效，得指定具体域名，且需加Access-Control-Allow-Credentials: true
如何处理 JSON 响应并避免重复解析？
response.json() 是一个异步方法，只能调用一次；多次调用会报 TypeError: Already read。
立即学习“Java免费学习笔记（深入）”；
- 不要这样：
res.json(); res.json()—— 第二次直接失败 - 安全做法：解析一次，存入变量，后续复用：
const data = await res.json() - 如果需要同时取 status 和 data，别用
.then(res => res.json())链式写法，先解构再处理：if (!res.ok) throw res; const data = await res.json() - 注意：
res.text()、res.blob()同样不可重入
为什么用 fetch 上传文件却收不到后端解析的字段？
手动构造 FormData 时，fetch 不会自动设置 Content-Type 请求头（浏览器会设为 multipart/form-data; boundary=...），但某些后端框架（如 Express 默认的 body-parser）不解析该类型，导致 req.body 为空。
- 不要手动设置
headers: { 'Content-Type': 'multipart/form-data' }—— 这会覆盖浏览器自动生成的带 boundary 的 header，导致后端无法解析 - 正确做法：不设
Content-Type，让浏览器自动处理；后端改用支持 multipart 的中间件（如 Express 的multer） - 如果后端只认
application/json，那就别用FormData，改用JSON.stringify()+headers: { 'Content-Type': 'application/json' }
最常被忽略的一点：fetch 没有超时控制，也没有原生的 abort-on-unmount 机制，实际项目中必须配合 AbortController 使用，否则组件卸载后仍在处理响应，容易引发 Cannot update a component while rendering a different component 类错误。
