正确使用 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')
.then(res => {
if (!res.ok) throw new Error(res.statusText);
return res.headers.get('content-length') === '0' ? null : res.json();
})
.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、当用户切到后台再回来时请求已失效——这些边界情况,才是封装和错误分类真正该发力的地方。











