正确使用 fetch 需显式检查 res.ok、容错处理空响应、按接口类型配 body 和 content-type、安全携带认证凭据，并封装统一错误处理与鉴权逻辑。
RESTful API 在 JavaScript 中消费，核心就是用 fetch 发起 HTTP 请求，但实际用起来常卡在认证、错误处理、数据格式或跨域上——不是“会不会”，而是“怎么写才不踩坑”。
如何用 fetch 正确发起 GET 请求并处理响应
很多人直接写 fetch(url).then(res => res.json())，结果遇到空响应、非 JSON、重定向或网络失败就报错。关键在于：必须显式检查 res.ok，且不能假设 res.json() 一定成功。
-
fetch只在网络错误时 reject，HTTP 状态码 4xx/5xx 不会触发 catch - 务必加
if (!res.ok) throw new Error(`${res.status} ${res.statusText}`) -
res.json()是异步解析，如果响应体为空（如 204）会抛SyntaxError，需先判断res.headers.get('content-length') !== '0'或用res.text()做兜底 - 示例：
fetch('/api/users/123')<br> .then(res => {<br> if (!res.ok) throw new Error(res.statusText);<br> return res.headers.get('content-length') === '0' ? null : res.json();<br> })<br> .then(data => console.log(data));
POST/PUT 请求中 body 和 Content-Type 怎么配
常见错误是把对象直接塞进 body，或手动设错 Content-Type，导致后端收不到数据。JSON 接口和表单接口处理方式完全不同。
- 发 JSON：用
JSON.stringify(obj)+headers: {'Content-Type': 'application/json'} - 发表单（
application/x-www-form-urlencoded）：用new URLSearchParams(formDataObj)，别手拼字符串 - 传文件（
multipart/form-data）：直接用FormData实例，不要设Content-Type—— 浏览器会自动加 boundary - 注意：Node.js 的
fetch（如 node-fetch）对FormData支持有限，生产环境建议用axios或原生http模块
如何安全地携带认证凭据（Token / Cookie）
前端带认证最常出问题的是凭据没发出去，或被 CORS 拦截。关键是看认证类型和请求上下文。
立即学习“Java免费学习笔记（深入）”；
- Token（如 Bearer）：加在
Authorizationheader，headers: { Authorization: 'Bearer abc123' }，无需额外配置 - Cookie：必须显式加
credentials: 'include'，否则浏览器默认不发 Cookie；同时后端Access-Control-Allow-Origin不能为*，得写具体域名 - 本地开发时，若后端跑在 localhost:8000，前端在 http://localhost:3000，跨域下 Cookie 默认不发送，需前后端配合：前端加
credentials: 'include'，后端返回Access-Control-Allow-Credentials: true和明确的Access-Control-Allow-Origin
为什么封装一个请求函数比到处写 fetch 更可靠
重复写错误处理、超时、鉴权头、loading 状态，不出三天就会漏掉某个分支。封装不是为了“高大上”，是堵住那些静默失败的缺口。
- 基础封装至少包含：统一 base URL、默认 timeout（用
AbortController）、自动加 token、res.ok校验、JSON 解析容错 - 避免在封装里做“自动重试”或“自动刷新 token”——这些逻辑依赖业务状态，放顶层控制更清晰
- 别用
async/await包一层就叫封装，重点是把可变部分（URL、method、body）抽成参数，把不变部分（错误映射、鉴权、日志）固化下来 - 复杂场景（如上传进度、取消请求、缓存策略）建议直接用
axios，它的拦截器和 CancelToken 比手写健壮得多
真正难的不是调通第一个接口，而是当后端返回 422 却没带 errors 字段、当 token 过期后连续三个请求都拿到 401、当用户切到后台再回来时请求已失效——这些边界情况，才是封装和错误分类真正该发力的地方。
